Getting the Most Out of SSH

← Back to Stories (view on slashdot.org)

Posted by Soulskill on Monday March 26, 2012 @05:49AM from the for-remote-controlling-your-nuclear-submarine dept.

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?

22 of 284 comments (clear)

Min score:

Reason:

Sort:

InfoWorld at it again by MasterMan · 2012-03-26 05:49 · Score: 3, Informative

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.
1. Re:InfoWorld at it again by Dwedit · 2012-03-26 06:05 · Score: 3, Informative
  
  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.
2. Re:InfoWorld at it again by tangent3 · 2012-03-26 06:12 · Score: 4, Informative
  
  That's what nohup is for
3. Re:InfoWorld at it again by GameboyRMH · 2012-03-26 06:15 · Score: 5, Informative
  
  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.
  
  --
  "When information is power, privacy is freedom" - Jah-Wren Ryel
4. Re:InfoWorld at it again by syzler · 2012-03-26 06:21 · Score: 4, Informative
  
  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.
5. Re:InfoWorld at it again by MasterMan · 2012-03-26 06:21 · Score: 5, Informative
  
  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!
6. Re:InfoWorld at it again by icebraining · 2012-03-26 06:27 · Score: 4, Informative
  
  Using sshuttle, the applications don't even need to support SOCKS; it proxies all traffic over SSH.
  
  --
  Dilbert RSS feed
7. Re:InfoWorld at it again by marcosdumay · 2012-03-26 06:44 · Score: 2, Informative
  
  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).
  
  --
  Rethinking email
8. Re:InfoWorld at it again by hcs_$reboot · 2012-03-26 07:01 · Score: 4, Informative
  
  To be honest I don't know, but these man pages 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".
  
  --
  Slashdot, fix the reply notifications... You won't get away with it...
9. Re:InfoWorld at it again by dylan_- · 2012-03-26 08:23 · Score: 4, Informative
  
  My mistake, then. I'd heard they'd gone the same route as OS X (incorrectly, it appears). Apologies to all.
  Nope, you heard correctly. The bit you're mistaken about is that OS X also has a root user. In both cases, the account is "locked" (no matchable password is set). Set a password for the root user and it works as normal.
  
  --
  Igor Presnyakov stole my hat
10. Re:InfoWorld at it again by Elrond,+Duke+of+URL · 2012-03-26 17:30 · Score: 3, Informative
  
  Even better is the screen/tmux wrapper called byobu (https://launchpad.net/byobu). It puts a nice face on screen (and now also tmux) and greatly simplifies basic usage. It also has a large selection of status notifications that can be displayed on the bottom one or two lines of your terminal which show things like the current screens, load, time, etc.
  The default key mapping uses the function keys for the most common commands. For example, F2 for a new window, F3/F4 for previous/next window, and so on. It provides a wrapper around the session handling as well, so that, in general, you can almost always just run "byobu" and get your session back or start a new one if there is none existing. And if it finds that you have more than one session running, it will ask you which one to connect to.
  In the configuration menu (F9), the last item allows you to toggle auto-launching at login. Select it and it will add a line to the end of your shell's profile file to start byobu when you login.
  Development has been proceeding at a very rapid pace over the past year and the feature set it quite nice. Recently, the default backend was switched from screen to tmux, but because byobu is a wrapper on top of those programs, I didn't need to learn a new set of keys... though it did help to read up on tmux to see what it could/couldn't do as compared to screen. For the most part, the change was transparent, though tmux only does one status line at the bottom of the terminal versus the two that you had with screen. One of the nicest changes is that tmux can determine what command you are executing in a window and it shows this in place of a window's generic title in the status line. Screen could do this too, but you had to jump though some hoops, change your shell prompt, and it didn't always work.
  Anyway, with the additions byobu brings to screen/tmux, I always have it running which has the added benefit that in the (these days, not very likely) event of SSH dropping my connection, nothing is lost. I usually use it in local terminals too, so if X or my terminal ever crashes for some odd reason, I'm saved there, too.
  
  --
  Elrond, Duke of URL
  "This is the most fun I've had without being drenched in the blood of my enemies!"-Sam&Max
11. Re:InfoWorld at it again by semi-extrinsic · 2012-03-26 19:51 · Score: 4, Informative
  
  Personal favourite: If you have machines on a LAN that are only exposed to that LAN, but there is one "gateway" machine that you can ssh to from the internet: use ProxyCommand, and you can ssh "directly" to the machines on the LAN even from the internet! Put the following in your .ssh/config:
  
  Host gate1
  Hostname 128.141.81.163
  User joe
  
  Host local12
  Hostname 192.168.1.12
  User joe
  ProxyCommand ssh -e none gate1 exec netcat -w 5 %h %p
  
  You can now ssh to "local12" just by typing "ssh local12", whether you are on the LAN or not.
  
  --
  for i in `facebook friends "=bday" 2>/dev/null | cut -d " " -f 3-`; do facebook wallpost $i "Happy birthday!"; done
How's that again? by 93+Escort+Wagon · 2012-03-26 05:53 · Score: 4, Informative

(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!

--
#DeleteChrome
2600 article by buanzo · 2012-03-26 06:01 · Score: 1, Informative

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.

--
Buanzo Consulting - 15 Years of GNU/Linux experience, for you.
1. Re:2600 article by CubicleZombie · 2012-03-26 06:13 · Score: 1, Informative
  
  If you get an "Informative" mod for that, I'm giving up on Slashdot.
  
  --
  :wq
Really lame by Anrego · 2012-03-26 06:02 · Score: 4, Informative

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”.
1. Re:Really lame by Anonymous Coward · 2012-03-26 06:32 · Score: 5, Informative
  
  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.
Comment removed by account_deleted · 2012-03-26 06:15 · Score: 5, Informative

Comment removed based on user account deletion
Re:On the other hand, you could buy the book by Anonymous Coward · 2012-03-26 06:39 · Score: 0, Informative

...well-regarded in the OpenBSD community.
That is to say, both of them agree.
Re:Hopefully? by Galactic+Dominator · 2012-03-26 06:53 · Score: 5, Informative

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

--
brandelf -t FreeBSD /brain
Re:Hopefully? by kwark · 2012-03-26 07:01 · Score: 4, Informative

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? by sydneyfong · 2012-03-26 07:29 · Score: 5, Informative

Emails are cached in a lot of intermediate servers and stuff. The logs are routinely backed up. Undelivered emails get forwarded to all sorts of addresses and admins. Even if nobody was maliciously scooping on you, the passwords could land on some random person's hands.
It *is* more secure over the phone in that sense.
And it's not a common practice to log down telnet traffic. Anyone who gets your telnet password is probably sniffing maliciously.
Not to say it's a sane policy to use telnet, but there are these differences in "levels" of safety (both levels are of course very very low). To a security conscious person it may be equivalent, but practically you have less chance a random John Doe will get your password this way. Maybe it matters, don't ask me....

--
Don't quote me on this.