Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Getting the Most Out of SSH

Soulskill posted more than 2 years ago | from the for-remote-controlling-your-nuclear-submarine dept.

Encryption 284

jfruh writes "If you have to administer a *nix computer remotely, you hopefully ditched Telnet for SSH years ago. But you might not know that this tool does a lot more than offer you a secured command line. Here are some tips and tricks that'll help you do everything from detect man-in-the-middle attacks (how are you supposed to know if you should accept a new hosts public key, anyway?) to evading restrictions on Web surfing." What are your own favorite tricks for using SSH?

Sorry! There are no comments related to the filter you selected.

InfoWorld at it again (3, Informative)

MasterMan (2603851) | more than 2 years ago | (#39476511)

Seriously, anyone who uses SSH knows about things like proxying your connection via the connection and X11 forwarding. This is nothing new. This is just InfoWorld getting backlinks and traffic from Slashdot once again. Hell, I knew about these things when I was 16 and so did every other guy I knew who ever had used SSH.

Re:InfoWorld at it again (1)

MasterMan (2603851) | more than 2 years ago | (#39476593)

The best thing is that there isn't really even "16 tricks". Most of them are about the same things, like the first randomart images. And then, we are taught how to use screen, like it somehow matters that it is over remote connection!

Re:InfoWorld at it again (3, Informative)

Dwedit (232252) | more than 2 years ago | (#39476703)

It does matter though. Didn't use screen? Lost a connection? Your processes are terminated. Linux sucks in that regard, you need to know about the hangup "feature" that immediately kills your processes when the terminal dies.

Re:InfoWorld at it again (4, Informative)

tangent3 (449222) | more than 2 years ago | (#39476773)

That's what nohup is for

Re:InfoWorld at it again (5, Informative)

MasterMan (2603851) | more than 2 years ago | (#39476867)

It does matter though. Didn't use screen? Lost a connection? Your processes are terminated. Linux sucks in that regard, you need to know about the hangup "feature" that immediately kills your processes when the terminal dies.

Yes, but this isn't even explained in the article!

Re:InfoWorld at it again (5, Interesting)

nschubach (922175) | more than 2 years ago | (#39476977)

In my opinion, I think it might be a better idea to kill the errant job if the controller/user gets disconnected than to continue with a job that may need a followup command that may never come, possibly leaving the server in an unusable state. So you have a choice of trusting the user or having the user say explicitly, "trust me, this is what I want to happen (screen/nohup)... even if I get disconnected."

Re:InfoWorld at it again (2, Informative)

marcosdumay (620877) | more than 2 years ago | (#39477089)

The GP is certainly asking for a default screen session evey time he does SSH, emulating what he gets on Windows.

Oh, well, most people prefer the option of choosing what session to use when they connect, thus things don't get linked the way he wants, but it is easy enough to set ssh to execute "screen -r" when one connects... The GP needs only to RTFM (the first line of it).

Re:InfoWorld at it again (1)

allo (1728082) | more than 2 years ago | (#39477185)

[exec] screen -r on the remote shell or ssh screen -r ... mostly the same stuff, and already covered later by "directly running commands via ssh".

And to easily edit known_hosts there is an easy vim trick: vim .ssh/known_hosts +line_no (opens vim, jumps to line #line_no)

Re:InfoWorld at it again (5, Interesting)

buchner.johannes (1139593) | more than 2 years ago | (#39476683)

My favorite trick is
1) have a server on the internet, let someone ssh -R their port 22 there
2) connect to that server too with ssh -L putting their port 22 on the local port 8022
3) Now you have a peer-to-peer ssh (with -Y), and you can run graphical applications remotely.

Re:InfoWorld at it again (4, Informative)

syzler (748241) | more than 2 years ago | (#39476859)

I generally prefer the apps on my desktop rather than the remote apps. "ssh -D 8080 " will start a SOCKS4/SOCKS5 server running on your local port 8080 and proxy the connections out the remote side. This allows all of your SOCKS enabled applications on your local workstation to make use of the tunnel without having to setup a one to one port mapping.

Re:InfoWorld at it again (4, Informative)

icebraining (1313345) | more than 2 years ago | (#39476919)

Using sshuttle [github.com] , the applications don't even need to support SOCKS; it proxies all traffic over SSH.

Re:InfoWorld at it again (2)

Anrego (830717) | more than 2 years ago | (#39476701)

Indeed. And that was the closest thing to an "ultimate hack". Everything else was basic intro to Linux type stuff.

That and the randomart stuff was very poorly explained. Personally I think that feature is pointless anyway. If you are in a position where you feel you might actually get a MiM attack.. copy the key onto a USB stick.

Re:InfoWorld at it again (1)

hcs_$reboot (1536101) | more than 2 years ago | (#39476715)

The 16 tricks are pretty high level, while some people still don't know that 'PermitRootLogin' in sshd_config is set to 'yes' by default...

Re:InfoWorld at it again (2)

CarsonChittom (2025388) | more than 2 years ago | (#39476763)

Not on OpenBSD.

Re:InfoWorld at it again (0)

Anonymous Coward | more than 2 years ago | (#39476883)

That depends on how the user answered the question during the install so it could still be yes, although you are correct that the default is no.

Re:InfoWorld at it again (1)

dingen (958134) | more than 2 years ago | (#39477071)

Which distro comes with an enabled root user these days?

Re:InfoWorld at it again (4, Informative)

hcs_$reboot (1536101) | more than 2 years ago | (#39477301)

To be honest I don't know, but these man pages [ed.ac.uk] show
PermitRootLogin
Specifies whether root can log in using ssh(1). The argument must be "yes", "without-password", "forced-commands-only" or "no". The default is "yes".

Re:InfoWorld at it again (1)

marcosdumay (620877) | more than 2 years ago | (#39477099)

Not on Debian.

Re:InfoWorld at it again (3, Insightful)

jellomizer (103300) | more than 2 years ago | (#39476811)

Well to be fair not everyone had SSH when they were 16 years old...

I was 16 once, and I would try to figure out how to do all the cool new trick that my new systems has... As we get older we get in a groove (mostly due to the fact that we are paid to do a particular job, and if we spend too much time finding something new and cool would prevent us from getting things done by are estimated time)

And after 8+ hour of work when we get home the last thing we want to do is more work.

Re:InfoWorld at it again (5, Informative)

GameboyRMH (1153867) | more than 2 years ago | (#39476813)

Yep I shoulda looked before I clicked...nothing non-obvious here folks, move along.

Here's an actual handy tip: You can make your RSA keyfiles also act as shellscripts for the connection, so you only need to carry 1 file to open the connection from any *nix machine.

To do it, just prefix your keyfile (say it's called ssh_my_server) like this:

#! /bin/sh
ssh user@hostname -i ssh_my_server
exit

----------BEGIN RSA PRIVATE KEY--------
(key goes here, use 4096-bit key for extra l33tness)

Make the file executable and now you can open the connection just by cd'ing to it and running it.

Re:InfoWorld at it again (1)

Anrego (830717) | more than 2 years ago | (#39477321)

Wow. Thanks!

And yeah.. that was more useful and more worthy of being called an "ultimate hack" then everything in this lame article combined.

Re:InfoWorld at it again (4, Insightful)

Albanach (527650) | more than 2 years ago | (#39476897)

Hell, I knew about these things when I was 16 and so did every other guy I knew who ever had used SSH.

To be fair, I'm sure there are sixteen year olds reading /.

I don't expect every article to be useful to me. Not sure why you would expect that.

I haven't read the article - I think I'm familar enough myself with ssh - but as long as the info is accurate, I'd image it's a useful tutorial for folk getting into Linux.

Re:InfoWorld at it again (2)

Anrego (830717) | more than 2 years ago | (#39477373)

Problem is the article is all over the place. It lists basic "intro to linux 101" stuff right next to "security paranoid enterprise server admin" stuff (which is does a very bad job of explaining anyway).

There are plenty of good "intro to SSH" articles and plenty of good "advanced SSH tricks" articles out there. This is just trash.

Re:_slashdot_ at it again (1)

Anonymous Coward | more than 2 years ago | (#39477011)

there, fixed that for ya.

i want the old slashdot back. i could put up with the general
technical ability around here dropping, but when slashdot assumes
we're all managers, that pisses me off.

here's who infoworld is aimed at
http://search.dilbert.com/search?w=trade+magazine&view=list&filter=type%3Acomic

Re:InfoWorld at it again (1)

Skuld-Chan (302449) | more than 2 years ago | (#39477129)

I know about a lot of stuff like this too, but when I was 16 the internet didn't really exist the way it is today. I remember using telnet and rsh for everything for example.

Hopefully? (5, Insightful)

Enry (630) | more than 2 years ago | (#39476545)

If you're still using telnet to administer anything that offers SSH, you should probably choose another field to work in.

Re:Hopefully? (-1, Troll)

ModernGeek (601932) | more than 2 years ago | (#39476577)

Slashdot has turned into fucking amateur hour.

Re:Hopefully? (-1)

Anonymous Coward | more than 2 years ago | (#39476861)

Cancer! Newfag cancer everywhere! Wait. This isn't /b/....

Re:Hopefully? (4, Interesting)

hcs_$reboot (1536101) | more than 2 years ago | (#39476605)

well I occasionally use 'telnet host 25' to test the smtp port

Re:Hopefully? (4, Insightful)

buchner.johannes (1139593) | more than 2 years ago | (#39476645)

Telnet has a protocol. Look at socat and netcat. Socat supports ssl, you can check your smtps server port.

Re:Hopefully? (4, Informative)

kwark (512736) | more than 2 years ago | (#39477297)

smtps was deprecated years ago (not that I agree). You should use:
openssl s_client -starttls smtp -connect host:(25|587)
Something socat doesn't appear to support (that's a first).

Re:Hopefully? (1)

vlm (69642) | more than 2 years ago | (#39476667)

Port 110 is trivially tested by hand... port 80 also.

Re:Hopefully? (0)

MasterMan (2603851) | more than 2 years ago | (#39476685)

You do know that you can use real programming language like C++ for that, right? This way you can automate the process and don't need to read and write every command by hand, and you have the added benefit of having access to variables and higher level programming.

I used to use telnet for irc, but it got really tiresome to answer to pings.

Re:Hopefully? (4, Insightful)

hcs_$reboot (1536101) | more than 2 years ago | (#39476757)

So, when I want to check if the port 25 is not blocked (firewall at ISP...) and is opened, instead of a simple 'telnet host 25' followed by ^D or ^C, I should write a C++ (may I use C for that, please?) program that does the same thing? You do know that some people already wrote some commands for that, right?

Re:Hopefully? (0)

slimjim8094 (941042) | more than 2 years ago | (#39476989)

You should use netcat or socat, since those are designed to allow you to fire text at a remote port and display the result. Telnet isn't, it only works "by accident" because the protocol is similar enough to plain text to work sometimes.

Re:Hopefully? (5, Informative)

Galactic Dominator (944134) | more than 2 years ago | (#39477197)

Telnet isn't, it only works "by accident" because the protocol is similar enough to plain text to work sometimes.

Bullshit. It was designed that way. And I can prove it, unlike your assertion.

http://tools.ietf.org/html/rfc15 [ietf.org]

Re:Hopefully? (3, Insightful)

Junta (36770) | more than 2 years ago | (#39476767)

When I see someone testing port 25 or 80, it's usually nothing more than a liveness test. Not worth the overhead of writing a program to open a socket and read and write data. perl/python is a tad more accessible, but still for a once in a blue moon use is generally more trouble than it's worth.

Re:Hopefully? (0)

Anonymous Coward | more than 2 years ago | (#39476835)

I could spend 3 seconds using telnet from an already open shell window, or I can spend the afternoon automating a process I'm going to do exactly once.

I've worked with many of idiots who are just like you, you're so efficient you cost yourself and others massive amounts of time. You're like the guy who invents a space pen instead of just using a bloody pencil.

Re:Hopefully? (2, Funny)

Anonymous Coward | more than 2 years ago | (#39476987)

MasterMan (2603851) - You do know that you can use real programming language like C++ for that, right?

C++ programmers are truly masters of the universe. I salute you sir for taking hours and object oriented wizardry to do what most programmers would do in 5 mins with a short script.

Re:Hopefully? (5, Interesting)

CubicleZombie (2590497) | more than 2 years ago | (#39476749)

I've worked in organizations where, because you can tunnel over SSH, it was banned and blocked over the network. Everything had to be done with Telnet instead. I'm not joking. That is probably what started my loathing of net admins.

Re:Hopefully? (3, Funny)

bzipitidoo (647217) | more than 2 years ago | (#39477339)

And in 2002, when I was contracting for the government, I needed some data that was stored on a government server. They set up a user account for me and rather than email the password to me, called to tell it to me over the phone, because they felt that was more secure than email.

The joke was that I was to connect via telnet. They didn't have ssh on that server. They didn't even have some kind of secure telnet that would at least try to encrypt the password. Just plain old telnet, with the password transmitted in the clear.

Re:Hopefully? (0)

Anonymous Coward | more than 2 years ago | (#39476783)

We have some old boxes here that use rsh / rlogin.

Ancient system with a tonne of scripts that rsh into this and that to do whatever the hell it is they do. It's on a lan though!

We're working on it ;p

Re:Hopefully? (1)

unixisc (2429386) | more than 2 years ago | (#39477175)

In college, I used to use that - rsh or rlogin. That was for accessing other hosts on campus, though.

Re:Hopefully? (2)

lcam (848192) | more than 2 years ago | (#39476799)

There may be reasons to use telnet over SSH. Challenge the assumption that it's always better to encrypt communications rather then let someone listen in.

That being said, your presumption is normally right; ISP administrators who block SSH and only allow file transfer by FTP fall into the same category. They should be fired.

Re:Hopefully? (1)

Darinbob (1142669) | more than 2 years ago | (#39477077)

Ha, I'm still using rlogin!

SSH Tunnel (2)

slashgrim (1247284) | more than 2 years ago | (#39476551)

Re:SSH Tunnel (1)

lcam (848192) | more than 2 years ago | (#39476743)

The holy grail of SSH, IMO, is tunneling. No firewall can stop you! (Well they can but they have to move to something more sophisticated then packet inspection and port blocking.)

Re:SSH Tunnel (4, Insightful)

Ruzty (46204) | more than 2 years ago | (#39476863)

Traffic pattern matching over SSL. A web session over an SSL connection looks very different than an ssh tunnel session over SSL, not to mention the length of life of the socket. It's trivial to have the firewall identify the ssh connection over port 443 and disconnect it in the first few seconds of the session based purely on the pattern of the traffic regardless of content.

Re:SSH Tunnel (1)

lcam (848192) | more than 2 years ago | (#39477163)

Neat. Thanks for your input.

Re:SSH Tunnel (1)

allo (1728082) | more than 2 years ago | (#39477263)

no, it could be a http keep alive connection inside the ssl-tunnel. and you do not know the traffic patterns of certain web-apps.
On the other hand with ssh and screen you can reconnect fast and without noticing, if you need to.

But you should propably not risk a fight with the admins. either accept or discuss the rule.

I hope the list of tricks (0)

Anonymous Coward | more than 2 years ago | (#39476559)

I hope the list of tricks includes skipping the banner ad while trying to look at the page containing the tricks...

Re:I hope the list of tricks (0)

Anonymous Coward | more than 2 years ago | (#39476853)

Or the twenty web-bugs, trackers, beacons, etc. Also per page. Thank heavens for Ghostery.

Re:I hope the list of tricks (3, Funny)

Wee (17189) | more than 2 years ago | (#39476943)

Thank heavens for Ghostery.

You misspelled "NoScript".

How's that again? (4, Informative)

93 Escort Wagon (326346) | more than 2 years ago | (#39476571)

(how are you supposed to know if you should accept a new hosts public key, anyway?)

Seriously? If you don't know enough about what's going on with the machine at the other end to make that decision... that's the whole bloody point of the warning!

Re:How's that again? (1)

Speare (84249) | more than 2 years ago | (#39477009)

(how are you supposed to know if you should accept a new hosts public key, anyway?)

Seriously? If you don't know enough about what's going on with the machine at the other end to make that decision... that's the whole bloody point of the warning!

Just because you use SSH doesn't mean you administer the machine.

I get a cheap ISP, it offers shell access to help me set up my scripts or website. I usually access it through the hostname I've attached with my DNS record: ssh shell.mydomain.com One day, they do some load balancing or something, and they shift my account to a different box. To me, it doesn't matter if they do that, but they don't exactly send out emails on each occasion. It has happened roughly three times a year for me. Every time I get the fingerprint-changed warning, it would be nice to have some confidence in it without resorting to the telephone. I can check whether the traceroute still goes to my ISP. I don't enter my password, I have already set up the account to trust my desktop's public key. Does the fact that they have my old SSH authorized_key file really mean there's no man-in-the-middle? (No.) At what point do I shrug and trust the new machine, vs calling up the ISP to get some info on the latest fingerprint change?

Re:How's that again? (1)

marcosdumay (620877) | more than 2 years ago | (#39477179)

At what point do I shrug and trust the new machine, vs calling up the ISP to get some info on the latest fingerprint change?

At no point. That is because there is no way for them to tell you the new key (or even that the key changed) whitout the possiblity it was forged. You shouldn't trust an email either.

The wrong thing here is that they are changing the keys. They shouldn't. If they have several servers pretending to be one, they should configure them to share the key and IP address.

Re:How's that again? (1)

Meeuw (552270) | more than 2 years ago | (#39477149)

I once enabled strict hostkey checking and created a global known hosts file, because all users had a (different, out dated) ~/.ssh/known_hosts. We had about 500 different SSH servers. I tried to explain why it is important not to send your credentials without checking the hostkey but no one understood it. Some (managers) even requested me to disable the host key checking altogether or let anyone update the known hosts automatically.

Most wanted feature which SSH lacks? (2)

garo5 (895321) | more than 2 years ago | (#39476639)

I'd always have liked that I could transfer a file or an stdout/stdin stream directly in the middle of an open ssh session. Also the file transfer / stream should be carried over nested ssh connections.
Imagine that you could just pipe the output from a command into some magical ssh command in a remote machine and your ssh client would ask where you would like to pipe the stream in your local machine.

Re:Most wanted feature which SSH lacks? (2)

allo (1728082) | more than 2 years ago | (#39477317)

this is possible.

first thing to look into:
[enter]~?
the ssh escape-key is ~, but only after a newline. and look out for deadkeys. ~? is a short help on this. There you can manage sub-connections and other stuff.
~. is very useful for terminating a ssh-process, which is still waiting for a network timeout.

And multiplexing a single ssh-connection: read the manpage of ssh for "ControlMaster". then a unix-socket which contains username and hostname in the filename is used to use a single ssh-connection for multiple streams (shells, transfers, etc.)

Wow (5, Interesting)

frodo from middle ea (602941) | more than 2 years ago | (#39476653)

Wow, ssh tunneling, and a few command line options , and screen, that's your ultimate SSH guide ?
I am impressed, not!

How about
- ssh master connection, for svn+ssh ?
- ssh agent forwarding
- opening ssh ports using knocking
- auto blacklisting with something like sshblack

I think the above are more advanced options than the ones mentioned in the article, no ?

Re:Wow (0)

Anonymous Coward | more than 2 years ago | (#39477031)

> - ssh master connection, for svn+ssh ?

Henceforth, I shall worship you as a god.

Re:Wow (3, Insightful)

mlts (1038732) | more than 2 years ago | (#39477043)

I'd love to see stuff like that as well as:

OpenSSH signed certificates (Not X.509) and TrustedUserCAKeys options and their usage. This way, I can hand a new cow-orker signed ssh host keys and assuming he or she knows enough not to just blindly replace a key if it isn't right, will minimize the chance of a MITM attack.

Revoking SSH keys.

Using SSHGuard to lock out brute force attempts.

Proper configuration of the sshd_config file. Stuff like only allowing root in via RSA keys (or blocking root access entirely.)

Auditing logs to know that key "A" ssh-ing to root is from user Alice, and key "B" is from Bob, so that one can tell who just wiped out the wrong filesystem come an inquiry.

Running sshd as a user, not as root.

Getting a backup program like NetBackup to form a ssh tunnel, do the backup, then close down the connection cleanly.

Re:Wow (1)

Qzukk (229616) | more than 2 years ago | (#39477049)

Or the key agent, or ~, or...

Re:Wow (1)

ModernGeek (601932) | more than 2 years ago | (#39477057)

This is intermediate at best. I need to spend more time on IRC if I can expect to stay in the game.

2600 article (1, Informative)

buanzo (542591) | more than 2 years ago | (#39476657)

there's a 2600 article on how to use ssh to run commands in a very INTERESTING way.... check out the past 6 issues, cant remember which one.

Re:2600 article (1, Informative)

CubicleZombie (2590497) | more than 2 years ago | (#39476779)

If you get an "Informative" mod for that, I'm giving up on Slashdot.

Re:2600 article (1)

nschubach (922175) | more than 2 years ago | (#39477069)

No, not Informative... even the GP said Interesting. ;)

Re:2600 article (2)

CubicleZombie (2590497) | more than 2 years ago | (#39477199)

Okay.

There might be a story about how to do something INSIGHTFUL in a magazine I borrowed from someone a few months back in some place somewhere.

Karma bonus, here I come...

Re:2600 article (1)

mattack2 (1165421) | more than 2 years ago | (#39477351)

Buh-bye.

(No, I wasn't one who modded it, especially after posting this.)

Really lame (4, Informative)

Anrego (830717) | more than 2 years ago | (#39476671)

Tip 16 and friends (the keyart stuff) is very poorly explained. You don’t know that the key is secure, but you magically know that the randomart is? That’s the bit they forgot to mention. It’s a visual representation of the key that _you have to have seen before to be able to verify_. Personally if you are going to go to the trouble.. I say throw the key on a USB stick and be done with it.

The screen stuff maybe worth mentioning the more modern alternative tmux.

SSHFS is better than NFS

For quick one-off stuff .. maybe. Cryptographic overhead is still startlingly effective at slowing things down, even on fast hardware (random: can anyone explain why.. you’d think it shouldn’t make any difference at this point.. I’m guessing it has something to do with network framing?).

Tip 4 (logging in with server-specific keys ) seems like the kind of thing that very few people will ever need to do.. and if they do.. they’ll google it. Kinda silly putting it in an article like this.

Tip 2 (ssh tunnel) is probably the only thing in here that _might_ be considered an “ultimate” hack (everything else is pretty much Linux 101).

Tip 1 (Evading silly web restrictions) is great. Alternate title: “my job is important, but damnit I need my facebook/twitter fix”.

Re:Really lame (0)

Anonymous Coward | more than 2 years ago | (#39476825)

You can run ssh without encryption (at least after hacking the source). I'm quite sure the issue is more likely with sshfs than encryption.
The problem I have seen is that the Linux kernel just sucks to various degrees when doing proper readahead.
With NFS I suspect it mostly works or it uses larger blocks in the first place.
But for example if you read 4 kB at a time via SMB it will indeed only request 4 kB each time, even if you always read completely linearly. This means you get 16x the round-trip latency over when you are reading 64 kB at a time.
sshfs probably has the same issue, and it totally kills performance over anything that does not have very low latency.

Re:Really lame (3, Interesting)

Anonymous Coward | more than 2 years ago | (#39476951)

Any clued network admin will eventually get wind of a ssh connection going to the same box from someone's workstation, especially if there is a lot of traffic going to and from it. Then, depending on how much they like/dislike the person with the tunnel, they will either ignore it, mention to be careful about PPP over SSH in passing, randomly kill the connection, block the destination IP at the router, block ssh from going outside from that workstation, or just sit there, watch statistics, then present HR with a case that a user is doing something they shouldn't by constantly sending encrypted traffic to a box that isn't owned by the company or anyone relevant. That right there is good enough to get someone sacked in most companies, especially ones with more paranoid and clueless PHBs.

Of course, one can ssh to a different port, but most IDS/IPS systems can detect a bunch of encrypted traffic over a TCP port and send a note to the admins, or just automatically lock the workstation out from the rest of the network.

So, the guide of using ssh as a tunnel is just plain stupid, and a good way to get fired for gross misconduct (which means no unemployment).

Re:Really lame (5, Informative)

Anonymous Coward | more than 2 years ago | (#39476971)

I am the developper of libssh (www.libssh.org).
SSHFS is slow because it's a packet based TCP-encapsulated file transfer protocol. All requests are initiated by the client and somewhat replied to by the server in an asynchronous design, but in practice no sftp server really has an asynchronous implementation. Opening a file, querying its length and downloading 8KiB require at least 3 or 4 RTT.
Compare with NFS, UDP based and mostly kernel-land and fully asynchronous.
Crypto is the main overhead in libssh and I suspect in openssh too, mainly because the crypto libs used do not probe for AES extensions or accelerators by default. And last but not least, OpenSSH's Channel window handling (similar to TCP windows) is not optimal for bulk transfers at high speed.
There are also some remote filesystem features missing in SFTP, like server-send feedback, locks and friends.

Re:Really lame (1)

Anonymous Coward | more than 2 years ago | (#39476973)

I use server specific keys daily. Any competent sysadmin really should. And I'm just...well.. probably really 'devops'

Here's the blunt:
      There's a firewall. It's controlled by people above us. We have permission to install and configure a VPN, but not to edit the firewall rules. People are encouraged to use gotomypc ... etc.

My desktop runs autossh with a ssh-agent and password protected key. SSH reverse tunnels out to a tiny server I have running at home, using a server specific fixed key to a local user account on a passwordless shell. The user account is firewalled to do *NOTHING* but the reverse forward.

From home, I login to that box as another user, grab the port forward--and am now ssh tunneled into the office.

I have full X11 forwarding, RDP, VNC, and am past the firewall and NAT layer.

Without permission to VPN, this might be a big "no-no"...but this is frankly better than any client VPN out there. With standard linux tools, I can pull my desktop to anywhere I am. If the double networking is any sort of issue--I simply need to ssh in and start another autossh job to the public IP of my laptop (if it exists).

I've got password authentication, key and SSHD authentication. And even if somebody compromises my remote server entirely --the most they can do is gain access to my work desktop's SSHD port. Which is going to require a good key to do anything.

Beyond that, it's a *great* temporary hack when you have slow developers. Sure, it's no real substitute for RPC -- but have a command on the system you want to expose to "bob", but don't trust him with a shell? Give him a copy of putty, a key you generated, and a fixed command on the server that *only* runs that. You can also change his shell if you're really paranoid.

Need a makeshift RPC service because you've got machines separated across the LAN, no permission to bridge a VPN? Or punch the port through the firewall? Oh... IT has ssh installed and they already use it. There you go -- blast through procedure and process to install a non-user account, provide a script that runs the single needed command, and associate it to a key. You now have a secure, authenticated remote service that lasts as long as it needs on a terminal.

Just don't do something idiotic like attach it to a psql shell or the less command.

I mean, I'll admit -- in an enterprise, all of these SHOULD be better developed. But when you need something solved in twenty minutes -- SSH to the damned rescue. It's secure, uses any type of authentication you might require, is usually already permitted, and can be locked down to any purpose you can imagine trivially.

Re:Really lame (1)

Qzukk (229616) | more than 2 years ago | (#39477203)

(random: can anyone explain why.. you’d think it shouldn’t make any difference at this point.. I’m guessing it has something to do with network framing?)

What happened is that advances in communication at the kernel has made everything else MUCH faster. System calls like sendfile() basically tell the kernel to dump everything in the file to that port and don't bother me until you're done, which eliminates all of the syscall context switching overhead for read()ing data from the file to a buffer then write()ing the buffer to the socket and maybe a select() or epoll() thrown in there, etc.

The only way to get this benefit with openssl is if you had the file pre-encrypted on the drive somewhere, somehow (each session is a new key, so not likely to happen). You could write the file on the fly, but then you might as well just write to the network instead of writing to a file and telling the kernel to send it later.

SSh tunnel (1, Funny)

Krneki (1192201) | more than 2 years ago | (#39476693)

SSh tunneling is teh sex.

Re:SSh tunnel (2)

manoweb (1993306) | more than 2 years ago | (#39477157)

But a PPP over SSH gives you a complete VPN, not only a bunch or redirected ports.

Re:SSh tunnel (1)

Anonymous Coward | more than 2 years ago | (#39477227)

Oh baby, I want your packet in my tunnel so bad ...

Beyond the shell (1)

pak9rabid (1011935) | more than 2 years ago | (#39476709)

Anybody that knows what they're doing already knows this, but since /. is quickly becoming a refuge for retards, other uses for SSH also include:

1.) File transfers between 2 hosts (via scp or sftp)
2.) Tunnelling (aka the "poor man's VPN"...great for accessing hosts behind a Unix-based firewall securely without having to setup additional DNAT rules)

Re:Beyond the shell (0)

Anonymous Coward | more than 2 years ago | (#39476901)

Hey be nice. Ya, a lot of us already know this stuff but there are kids just getting into the scene that don't yet.

Remote TCP port forwarding (1)

aglider (2435074) | more than 2 years ago | (#39476717)

My favorite is to use SSH remote port forwarding (-R) to allow my machines to connect back home from an unknown (and possibly changing) IP and then allow me to ssh back to them. And key authentication all the way along!
And, by the way, SSH tunneling is not TCP port forwarding!

Re:Remote TCP port forwarding (1)

tramp (68773) | more than 2 years ago | (#39476801)

Indeed SSH tunneling is not TCP port forwarding and if you want something like that, you should use shuttle (https://github.com/apenwarr/sshuttle).

Should have been titled "ssh basics". (2, Interesting)

Anonymous Coward | more than 2 years ago | (#39476719)

Also... screen? When there's tmux???

The MITM 'help' is worthless. (2)

Junta (36770) | more than 2 years ago | (#39476735)

Basically they go into some detail about the ascii art representation, and at the end acknowledge that you need to securely get the keys to know what to expect. If you have a secure means of getting the ascii art, you have a secure means of getting the key. The only exception I can think of is if you have someone cell-phone picturing the local console, which could be helpful.

The real useful thing would be for people to do DNSSEC and SSHFP records.

My fav (4, Interesting)

Anonymous Coward | more than 2 years ago | (#39476753)

Rather than more complaining, I thought I'd say my favorite option. I like using the ~/.ssh/config file and the use of a master connection. In mine, I have:

host *
  controlmaster auth
  controlpath ~/.ssh/ssh-%r@%h:%p
  controlpersist yes

This creates a master socket on my client. When I first connect, I need to use my passphrase. But when I exit, the SSH tunnel stays up. Futher connections via SSH and sftp and scp use this connection, multiplexed. So no more asking from my passphrase. When I'm finished for the day, I close down the connection with

ssh -O exit host

replacing "host"

Need more performance? (0)

Anonymous Coward | more than 2 years ago | (#39476755)

Multi-threaded SSH [slashdot.org] is a pretty nifty patch for getting more out of your ssh connections.

On the other hand, you could buy the book (5, Informative)

CarsonChittom (2025388) | more than 2 years ago | (#39476815)

Michael Lucas, author of (amongst other things), Absolute OpenBSD, has a new book out called SSH Mastery: OpenSSH, PuTTY, Tunnels, and Keys [michaelwlucas.com] . It seems to be very informative and well-regarded in the OpenBSD community [undeadly.org] .

Re:On the other hand, you could buy the book (0, Informative)

Anonymous Coward | more than 2 years ago | (#39477025)

...well-regarded in the OpenBSD community.

That is to say, both of them agree.

Wikibook on OpenSSH (1)

SgtChaireBourne (457691) | more than 2 years ago | (#39477299)

The has also been a WIkibook on OpenSSH [wikibooks.org] out for a year or so. The prose may not be the best but the tips are there.

HTTP Proxy (1)

bambewn (2588841) | more than 2 years ago | (#39476831)

I had forgot about this for a while due to VPN shenanigans, but tunneling your web traffic through an SSH is a great way to secure your web sessions if you don't have a VPN setup. I have also found that using Cygwin/SSH to secure your RDP can also be pretty boss if you have to work on M$ machines from remote very often.

SSH Feature Wish: Server policy on SSH keys (3, Interesting)

linuxtelephony (141049) | more than 2 years ago | (#39476879)

I wish it was possible to require SSH keys for some (or even all) users to have a passphrase, and enforce this requirement on the server.

As it stands right now, even if you generate a key for someone with a pass phrase, they can remove it easily on the client side and the server has no way of knowing. This means you could have passwordless logins to remote systems. Not good.

At least with modern systems and key agents you can get passwordless ease of use once you log into your local account, and if someone happens to get your private key they don't immediately have instant access to the machines you can log into. You should have a little time to secure the machines. [Think lost/stolen laptop or backup drive.]

Re:SSH Feature Wish: Server policy on SSH keys (1)

Erpo (237853) | more than 2 years ago | (#39477331)

I wish it was possible to require SSH keys for some (or even all) users to have a passphrase, and enforce this requirement on the server.

As it stands right now, even if you generate a key for someone with a pass phrase, they can remove it easily on the client side and the server has no way of knowing. This means you could have passwordless logins to remote systems. Not good.

Such a policy would require the server to take the client's word for it that the private key was encrypted with a passphrase.

At least with modern systems and key agents you can get passwordless ease of use once you log into your local account, and if someone happens to get your private key they don't immediately have instant access to the machines you can log into. You should have a little time to secure the machines. [Think lost/stolen laptop or backup drive.]

Agreed. If someone is removing the passphrase from their private key, there is some other problem that needs to be solved. Personally, I like ecryptfs for my home directory and LUKS for my backup drive with the LUKS passphrase inside my login keyring.

Re:SSH Feature Wish: Server policy on SSH keys (1)

allo (1728082) | more than 2 years ago | (#39477377)

how is the server supposed to check, if the key is really using a password?

This Article's True Purpose (5, Insightful)

preaction (1526109) | more than 2 years ago | (#39476983)

Get real SSH tips from people complaining (rightly or not) that it doesn't contain any actual advice.

Never talk about speed (1)

droidsURlooking4 (1543007) | more than 2 years ago | (#39477033)

How about an article discussing the pros and cons of various types of encryption including speed. Actually, what is the fastest encrypted file transfer protocol (don't say ftp in a vpn)? SCP seems to really fall down here.

I live in the post-SSH world (1)

DrSkwid (118965) | more than 2 years ago | (#39477037)

the 1970s was cool and all

Speedwise (1)

marcovje (205102) | more than 2 years ago | (#39477123)

Speedwise, ssh -2 still holds up my Mac 840AV up for several minutes to login :-)

The article sucks, but here's some extra stuff (0)

Anonymous Coward | more than 2 years ago | (#39477141)

First off there is this beauty called ssh-agent, which allows for SSO functionality; ssh-agent requests can be forwarded and tunelled through multiple ssh hops (although agent forwarding places some extra trust in the other machine's admin). You can use ssh-agent as a PAM authentication module, so that you don't have to use your password for sudoing etc.

A poor man's VPN can be done by placing pppd at both ends of the ssh connection. In newer version, ssh can do this automatically via tun device redirection.

Little is known about the 'ssh command line' activated via ~C where you can add/remove/edit port forwards for current session.

SSH keys support certification authority scheme similar to SSL keys.

And finally a lot of magical and wonderful things can be created by mastering the ssh daemon configuration (especially wrt authorized_keys).

My SSH Utility (1)

merc (115854) | more than 2 years ago | (#39477349)

Feel free to check out a little perl utility I wrote for creating aliases or shortcuts for remote ssh logins. If you have a lot of hosts to manage it can make your life easier:

http://www.cpan.org/authors/id/L/LD/LDAVIS/remote-ssh-access-1.7 [cpan.org]

Download the file, name it "remote-ssh-access". To read the perl documentation just use "perldoc remote-ssh-access"

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?