Getting the Most Out of SSH

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?

Comments

InfoWorld at it again

[MasterMan]

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

[buchner.johannes]

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

[Dwedit]

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

[tangent3]

That's what nohup is for

Re:InfoWorld at it again

[jellomizer]

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

[GameboyRMH]

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

[syzler]

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

[MasterMan]

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

[Albanach]

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

[icebraining]

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

Re:InfoWorld at it again

[nschubach]

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

[hcs_$reboot]

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".

Re:InfoWorld at it again

[miknix]

What about unlimited encrypted storage?

you need TCP forwarding enabled in your sshd_config, then

ssh -L localhost:2222:localhost:2222 localhost
$ echo "data you wanna save" | nc localhost 2222

# or if you want to backup your hdd, try:
$ cat /dev/sda1 | nc localhost 2222

# the data will be forwarded forever in the loopback link at no cost until you read it back:
$ nc localhost 2222 > hdd-backup.bin

# profit!

Re:InfoWorld at it again

[dylan_-]

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.

Re:InfoWorld at it again

[Elrond, Duke of URL]

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.

Re:InfoWorld at it again

[semi-extrinsic]

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.

Hopefully?

[Enry]

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

Re:Hopefully?

[hcs_$reboot]

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

Re:Hopefully?

[buchner.johannes]

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

Re:Hopefully?

[CubicleZombie]

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?

[hcs_$reboot]

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?

[Junta]

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?

[Galactic Dominator]

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

Re:Hopefully?

[kwark]

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?

[bzipitidoo]

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?

[sydneyfong]

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....

How's that again?

[93 Escort Wagon]

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

Wow

[frodo from middle ea]

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

[mlts]

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.

Really lame

[Anrego]

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

[Anonymous Coward]

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

[Anonymous Coward]

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.

My fav

[Anonymous Coward]

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"

Comment removed

[account_deleted]

Comment removed based on user account deletion

Re:SSH Tunnel

[Ruzty]

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.

SSH Feature Wish: Server policy on SSH keys

[linuxtelephony]

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:I hope the list of tricks

[Wee]

Thank heavens for Ghostery.

You misspelled "NoScript".

This Article's True Purpose

[preaction]

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

Re:Should have been titled "ssh basics".

[tscheez]

I'd never used tmux. i've officially learned more from /. comments than the actual articles. Thanks!

Personally I like

[Rich]

tar cf - somedir | ssh remote@remotehost 'tar xf -'

A nice way to get things moved around. a similar trick is:

tar cf - somedir | (cd /a/local/path; tar xf - )

Which lets you copy things around a local file system.