7 ms·

Getting Comfortable With SSH

100 points by jcsalterego 16y ago

jefe78 16y ago
A lot of guides online make the 'mistake'(a minor one) of still using DSA instead of RSA. The patent has expired. I assume a lot of those guides are out of date. So, thanks for using RSA in the article! EDIT: I just did some digging. Apparently DSA cannot be used to encrypt. One more reason to keep using RSA, I suppose.
- kgo 16y ago
  Technically your keys are only used in the handshake. After that you'll get the same strength encryption regardless of the algo used for the original handshake. So using DSA doesn't mean that your connections are now unencrypted. The problem with DSA is that you can only have a key size of 1024 bits per the original standard. That's starting to get a little weak these days. (Keep that in mind if youi're using PuttyGen to make your keys!) This has since been changed, some systems use "dsa2" and higher bit counts, but it seems OpenSSH doesn't directly support that, at least according to the man page. Anyway, the new version of OpenSSH just got ECC, which seems to be the future of public/private key encryption. So soon people will be talking trash on RSA. (I kid...)
mcmatterson 16y ago
Good article overall, but there is one major problem with the section on public-key auth; it's rarely a good idea to use blank pass phrases on your private keys, for two good reasons: 1. The security implications. Without a passphrase, anyone who manages to snare a copy of your private key can use it to access any servers where you've authorized it with no further credentials needed. Not good. Using a passphrase turns SSH auth into a poor man's two factor system: what you have (the key file), and what you know (the passphrase). 2. It breaks agent-forwarding, which is the system that gives you the ability to SSH onwards from the remote machine to other machines without (again) being asked for your password. This has practical implications when using SSH to drive things like application deployment over git, when you have to ssh onward from the server to your git repository. Doing things this way sidesteps the awkward use of deploy keys, and is actually easier to set up and use as well as being more secure. With agent forwarding, there's no need to keep your private key anywhere except your 'home' machine, and yet you get the same benefits your would if you had it everywhere. The annoyance of having to type in your passphrase every time is greatly lessened by the use of a key agent on your 'home' machine. OS X has provided a key agent since 10.5 I believe, and stores the passphrase in your Keychain (you know you're doing things right if an OS X dialog box prompts you for your passphrase when running SSH in the terminal). Gnome has one built in as well, and ssh-agent is always around for people who want to roll their own. If there's interest, I'll write up a blog post about how to get this stuff set up. It's not really easily discoverable stuff, but it _is_ really simple and useful once you get it up and running.
- liuhenry 16y ago
  Ironically, GitHub warns against using unprotected private keys in their setup guide: http://help.github.com/working-with-key-passphrases/ http://help.github.com/working-with-key-passphrases/
- jefe78 16y ago
  Your mention of Gnome's built in key-ring is rather interesting. I just setup keys on my desktop for my work servers and was met with a foreign prompt for this key. I was startled and unclear about what to do, until I did some digging around. I'm sure an article would be appreciated!
- jcsalterego 16y ago
  Cheers for pointing that out. I haven't taken the time to figure out key agent -- for shame! -- although I would be interested in a write-up.
- roxstar 16y ago
  If you are going to go the terminal way with ssh-agent I highly recommend using keychain (http://www.funtoo.org/en/security/keychain/intro/ http://www.funtoo.org/en/security/keychain/intro/ ) which is quite easy to setup and use, and much easier than having to do ssh-add and so on every time you want to use a specific key.
  - leif 16y ago
    Keychain is the best. It also works with gpg-agent, if you're old and cranky enough to still think gpg is worth using.
    - kgo 16y ago
      I didn't realize I was old and cranky... I've been using gpg-agent with a smartcard for ssh authentication for the past six months or so. It's the way, the truth, and the light. Real two-factor authentication. The key can't be compromised without trying to physically take apart the chip on the card and somehow access the internals. Three wrong password attempts and the thing locks. Three wrong attempts with the admin unlock code and the card self-destructs. So even if I lose the card or someone jacks it, it can't be brute forced. (Yes I don't need that level of security, and I'm not even being paranoid; it's just neat. Makes me feel like James Bond or Batman or some shit like that every time I ssh somewhere. Yes I'm that lame... ) And since it's still using a standard RSA key for ssh authentication, I don't need to install anything special like experimental pam modules, on the host machines. Just copy the public key into authorized_keys. That's nice since I don't have full admin rights on a lot of my host machines.
harichinnan 16y ago
You could use plink for setting up reverse ssh tunneling. The documentation on putty and plink has more details.
stenius 16y ago
found a couple of cool tricks in the article, mainly using the -t flag to set up a chain of servers to pass through when machines are NATed or firewalled. Seems kind of weird in the tunnel section that the -D flag was not mentioned which creates a dynamic tunnel that can go to multiple hosts when set up as a socks proxy in a web browser.
- mcmatterson 16y ago
  Shame on me for not reading that section in closer detail. The -t method of forwarding SSH through has a number of limitations, and isn't really the golden path for getting past gateway servers. What you instead want to do is add the following as a config option for the host you're trying to reach: "ProxyCommand ssh <gateway_machine> nc %h %p" You can do this by adding the above line in the relevant place in ~/.ssh/config, or on the command line like so: ssh -o "ProxyCommand ssh <gateway_machine> nc %h %p" user@destination_machine
  - ernesth 16y ago
    In fact what you really want is not to use nc but ssh's -W option: ProxyCommand ssh -W %h:%p <gateway_machine
    - mcmatterson 16y ago
      Interesting -- I did not know about this one. Looks like it was implemented in OpenSSH 5.4, which isn't yet in Ubuntu LTS or OS X (the two environments where I spend most of my days), so it may be a little bleeding edge for general use just yet. Good to know, however.
nhebb 16y ago
I used this video guide to setting up PuTTY w/ Pageant on Windows: http://vimeo.com/4856534 http://vimeo.com/4856534 It's from a series on setting a a Linus VPS for noobs, and I found it indispensable. My only problem is that my Linode runs so trouble free, that I rarely need to go in and mess with it, so even though I've been running a VPS for a year, I still have a limited knowledge of Linux administration.
leif 16y ago
One of the most impressive SSH tricks I've seen is the ControlMaster option. It saves your authentication information on a per-(user, host) basis, which lets you share one connection among multiple ssh/scp/rsync commands and TRAMP sessions. This is less useful if you use passwordless keys or ssh-agent (please use ssh-agent), but becomes much more useful if the host you connect to doesn't support key-based auth. # multiplex connections to one host ControlMaster auto # where is that file ControlPath ~/.ssh/master-%r@%h:%p Other useful things in my .ssh/config, check the manpages before you use them: # use compression Compression yes # really really compress it CompressionLevel 9 # forward X stuff ForwardX11 yes # yes, really forward X stuff ForwardX11Trusted yes
- jcsalterego 16y ago
  The only issue I had with ControlMaster, IIRC, was that when I killed the original connection, it would take everything else down with it. There's a good chance I was just doing it wrong™ though.
  - leif 16y ago
    The behavior I've seen is that when you log out, the process doesn't end until all other clients to the connection have exited. I've observed what you describe if I then ^C it. The way I usually do it is by opening something over TRAMP before opening any other ssh windows. That way, Emacs will handle the connection maintenance and I don't really need to see that it's up. If it dies, I just try saving something and it'll re-establish the connection. If you don't use Emacs, you can always just start a dummy connection first and minimize/disown it.
    - jcsalterego 16y ago
      That sounds about right. Good tip about TRAMP, although I tend to exit out of my emacs sessions frequently. For my long running ssh tunnels, I just screen them.
      - 16y ago
xtacy 16y ago
Another tip: An ssh session's escape sequence is "<Enter><tilde>", which if you refer as "<X>", you can do the following: 1. Kill an unresponsive ssh session: <X><period>. 2. Enter an ssh command line, to open new forwarding ports among others: <X><C> Then enter <question-mark> for help.
- jcsalterego 16y ago
  I use this all the time. It's amazing.
__david__ 16y ago
I liked the article but I thought he spent too much time on getting the hostname short. Just install bash_completion and then all ssh/network stuff starts completing based on your known_hosts. His "annoying.hostname.example.com" becomes "ssh ann<tab>" which is still shorter than anything he had there. I'm glad he did mention my favorite config file option for setting the username: Host example.com User = someweirduser That way I don't have to remember to "ssh someweirduser@example.com" because some client set up a weird user for me--I just "ssh example.com" instead.
- jcsalterego 16y ago
  Yeah, the example is more for hyperbolic illustration than anything else. My actual use case is that I've got a lot of IP addresses, different usernames and non-standard ports across various servers, so it's incredibly convenient to have my .ssh/config all set up. With aliases (and zsh completion support for aliases), I can do "ann<tab>" which saves me even more time. It won't be long before all I have to type is tab :)
- mcmatterson 16y ago
  Small point: the syntax of .ssh/config doesn't use equal signs; the actual format of that stanza would be Host example.com User someweirduser Another subtle point about SSH config -- only the first matching entry (in top-to-bottom order) for a given parameter is taken from .ssh/config. If you have multiple Host entries that match for a given hostname, the first matching User, Port, etc, entry will be the one that ssh uses.
- thristian 16y ago
  Modern versions of ssh support the "HashKnownHosts" file which prevents people from discovering what hosts you have ssh'd to in the past - and, as a side effect, prevents tab-completion from discovering what hosts you have ssh'd to as well. ssh_config(5) says the option is disabled by default, but Ubuntu at least enables it in /etc/ssh/ssh_config.
yetanotherjosh 16y ago
Any halfway decent tech team manager or sysadmin should make a very clear company-wide policy against passphraseless SSH keys for developers. Github compares it to leaving your password in a file on your computer for attackers to find, but it's MUCH worse than that. Such a password file could be anywhere on your computer and an attacker would have to search for it and may never actually find it unless it was clearly labelled. SSH keys are defined in your SSH config file and attackers know exactly where that lives. Using a passphraseless ssh key is more like leaving your password on a sticky note attached to your monitor. This article is spreading bad advice here to users who don't understand why, and the author should update his post and retract it.
- hollerith 16y ago
  Help me out here: if an attacker can get into my account on my OS X or Linux box, he can run sudo, which means he can replace my ssh client with one that will capture my passphrase the next time I use it. Can you give a concrete example of a scenario in which an attacker will be able to read my SSH config file but not be able to get into my account? Suppose the SSH config file is not backed up. I am not saying you are wrong about the need for a passphrase, BTW.
  - rmc 16y ago
    On Linux you need to enter your password to run sudo. If someone can read all the files in your home directory but not make you enter sudo, then they can see your ssh keys but be unable to replace /usr/bin/ssh
    - hollerith 16y ago
      Thanks. I have been using OS X where sudo does not ask admin accounts for a password.
sciurus 16y ago
If you learned something from this, be sure to read http://www.jedi.be/blog/2010/08/27/ssh-tricks-the-usual-and-beyond/ http://www.jedi.be/blog/2010/08/27/ssh-tricks-the-usual-and-...
n00b4evr 16y ago
+5 AGILITY.. nice touch XD

100 points by jcsalterego 16y ago

A lot of guides online make the 'mistake'(a minor one) of still using DSA instead of RSA. The patent has expired. I assume a lot of those guides are out of date. So, thanks for using RSA in the article! EDIT: I just did some digging. Apparently DSA cannot be used to encrypt. One more reason to keep using RSA, I suppose.

kgo 16y ago
Technically your keys are only used in the handshake. After that you'll get the same strength encryption regardless of the algo used for the original handshake. So using DSA doesn't mean that your connections are now unencrypted. The problem with DSA is that you can only have a key size of 1024 bits per the original standard. That's starting to get a little weak these days. (Keep that in mind if youi're using PuttyGen to make your keys!) This has since been changed, some systems use "dsa2" and higher bit counts, but it seems OpenSSH doesn't directly support that, at least according to the man page. Anyway, the new version of OpenSSH just got ECC, which seems to be the future of public/private key encryption. So soon people will be talking trash on RSA. (I kid...)

mcmatterson 16y ago

Good article overall, but there is one major problem with the section on public-key auth; it's rarely a good idea to use blank pass phrases on your private keys, for two good reasons: 1. The security implications. Without a passphrase, anyone who manages to snare a copy of your private key can use it to access any servers where you've authorized it with no further credentials needed. Not good. Using a passphrase turns SSH auth into a poor man's two factor system: what you have (the key file), and what you know (the passphrase). 2. It breaks agent-forwarding, which is the system that gives you the ability to SSH onwards from the remote machine to other machines without (again) being asked for your password. This has practical implications when using SSH to drive things like application deployment over git, when you have to ssh onward from the server to your git repository. Doing things this way sidesteps the awkward use of deploy keys, and is actually easier to set up and use as well as being more secure. With agent forwarding, there's no need to keep your private key anywhere except your 'home' machine, and yet you get the same benefits your would if you had it everywhere. The annoyance of having to type in your passphrase every time is greatly lessened by the use of a key agent on your 'home' machine. OS X has provided a key agent since 10.5 I believe, and stores the passphrase in your Keychain (you know you're doing things right if an OS X dialog box prompts you for your passphrase when running SSH in the terminal). Gnome has one built in as well, and ssh-agent is always around for people who want to roll their own. If there's interest, I'll write up a blog post about how to get this stuff set up. It's not really easily discoverable stuff, but it _is_ really simple and useful once you get it up and running.

liuhenry 16y ago
Ironically, GitHub warns against using unprotected private keys in their setup guide: http://help.github.com/working-with-key-passphrases/ http://help.github.com/working-with-key-passphrases/
jefe78 16y ago
Your mention of Gnome's built in key-ring is rather interesting. I just setup keys on my desktop for my work servers and was met with a foreign prompt for this key. I was startled and unclear about what to do, until I did some digging around. I'm sure an article would be appreciated!
jcsalterego 16y ago
Cheers for pointing that out. I haven't taken the time to figure out key agent -- for shame! -- although I would be interested in a write-up.
roxstar 16y ago
If you are going to go the terminal way with ssh-agent I highly recommend using keychain (http://www.funtoo.org/en/security/keychain/intro/ http://www.funtoo.org/en/security/keychain/intro/ ) which is quite easy to setup and use, and much easier than having to do ssh-add and so on every time you want to use a specific key.
- leif 16y ago
  Keychain is the best. It also works with gpg-agent, if you're old and cranky enough to still think gpg is worth using.
  - kgo 16y ago
    I didn't realize I was old and cranky... I've been using gpg-agent with a smartcard for ssh authentication for the past six months or so. It's the way, the truth, and the light. Real two-factor authentication. The key can't be compromised without trying to physically take apart the chip on the card and somehow access the internals. Three wrong password attempts and the thing locks. Three wrong attempts with the admin unlock code and the card self-destructs. So even if I lose the card or someone jacks it, it can't be brute forced. (Yes I don't need that level of security, and I'm not even being paranoid; it's just neat. Makes me feel like James Bond or Batman or some shit like that every time I ssh somewhere. Yes I'm that lame... ) And since it's still using a standard RSA key for ssh authentication, I don't need to install anything special like experimental pam modules, on the host machines. Just copy the public key into authorized_keys. That's nice since I don't have full admin rights on a lot of my host machines.

harichinnan 16y ago

You could use plink for setting up reverse ssh tunneling. The documentation on putty and plink has more details.

stenius 16y ago

found a couple of cool tricks in the article, mainly using the -t flag to set up a chain of servers to pass through when machines are NATed or firewalled. Seems kind of weird in the tunnel section that the -D flag was not mentioned which creates a dynamic tunnel that can go to multiple hosts when set up as a socks proxy in a web browser.

mcmatterson 16y ago
Shame on me for not reading that section in closer detail. The -t method of forwarding SSH through has a number of limitations, and isn't really the golden path for getting past gateway servers. What you instead want to do is add the following as a config option for the host you're trying to reach: "ProxyCommand ssh <gateway_machine> nc %h %p" You can do this by adding the above line in the relevant place in ~/.ssh/config, or on the command line like so: ssh -o "ProxyCommand ssh <gateway_machine> nc %h %p" user@destination_machine
- ernesth 16y ago
  In fact what you really want is not to use nc but ssh's -W option: ProxyCommand ssh -W %h:%p <gateway_machine
  - mcmatterson 16y ago
    Interesting -- I did not know about this one. Looks like it was implemented in OpenSSH 5.4, which isn't yet in Ubuntu LTS or OS X (the two environments where I spend most of my days), so it may be a little bleeding edge for general use just yet. Good to know, however.

nhebb 16y ago

I used this video guide to setting up PuTTY w/ Pageant on Windows: http://vimeo.com/4856534 http://vimeo.com/4856534 It's from a series on setting a a Linus VPS for noobs, and I found it indispensable. My only problem is that my Linode runs so trouble free, that I rarely need to go in and mess with it, so even though I've been running a VPS for a year, I still have a limited knowledge of Linux administration.

leif 16y ago

One of the most impressive SSH tricks I've seen is the ControlMaster option. It saves your authentication information on a per-(user, host) basis, which lets you share one connection among multiple ssh/scp/rsync commands and TRAMP sessions. This is less useful if you use passwordless keys or ssh-agent (please use ssh-agent), but becomes much more useful if the host you connect to doesn't support key-based auth. # multiplex connections to one host ControlMaster auto # where is that file ControlPath ~/.ssh/master-%r@%h:%p Other useful things in my .ssh/config, check the manpages before you use them: # use compression Compression yes # really really compress it CompressionLevel 9 # forward X stuff ForwardX11 yes # yes, really forward X stuff ForwardX11Trusted yes

jcsalterego 16y ago
The only issue I had with ControlMaster, IIRC, was that when I killed the original connection, it would take everything else down with it. There's a good chance I was just doing it wrong™ though.
- leif 16y ago
  The behavior I've seen is that when you log out, the process doesn't end until all other clients to the connection have exited. I've observed what you describe if I then ^C it. The way I usually do it is by opening something over TRAMP before opening any other ssh windows. That way, Emacs will handle the connection maintenance and I don't really need to see that it's up. If it dies, I just try saving something and it'll re-establish the connection. If you don't use Emacs, you can always just start a dummy connection first and minimize/disown it.
  - jcsalterego 16y ago
    That sounds about right. Good tip about TRAMP, although I tend to exit out of my emacs sessions frequently. For my long running ssh tunnels, I just screen them.
    - 16y ago

xtacy 16y ago

Another tip: An ssh session's escape sequence is "<Enter><tilde>", which if you refer as "<X>", you can do the following: 1. Kill an unresponsive ssh session: <X><period>. 2. Enter an ssh command line, to open new forwarding ports among others: <X><C> Then enter <question-mark> for help.

jcsalterego 16y ago
I use this all the time. It's amazing.

__david__ 16y ago

I liked the article but I thought he spent too much time on getting the hostname short. Just install bash_completion and then all ssh/network stuff starts completing based on your known_hosts. His "annoying.hostname.example.com" becomes "ssh ann<tab>" which is still shorter than anything he had there. I'm glad he did mention my favorite config file option for setting the username: Host example.com User = someweirduser That way I don't have to remember to "ssh someweirduser@example.com" because some client set up a weird user for me--I just "ssh example.com" instead.

jcsalterego 16y ago
Yeah, the example is more for hyperbolic illustration than anything else. My actual use case is that I've got a lot of IP addresses, different usernames and non-standard ports across various servers, so it's incredibly convenient to have my .ssh/config all set up. With aliases (and zsh completion support for aliases), I can do "ann<tab>" which saves me even more time. It won't be long before all I have to type is tab :)
mcmatterson 16y ago
Small point: the syntax of .ssh/config doesn't use equal signs; the actual format of that stanza would be Host example.com User someweirduser Another subtle point about SSH config -- only the first matching entry (in top-to-bottom order) for a given parameter is taken from .ssh/config. If you have multiple Host entries that match for a given hostname, the first matching User, Port, etc, entry will be the one that ssh uses.
thristian 16y ago
Modern versions of ssh support the "HashKnownHosts" file which prevents people from discovering what hosts you have ssh'd to in the past - and, as a side effect, prevents tab-completion from discovering what hosts you have ssh'd to as well. ssh_config(5) says the option is disabled by default, but Ubuntu at least enables it in /etc/ssh/ssh_config.

yetanotherjosh 16y ago

Any halfway decent tech team manager or sysadmin should make a very clear company-wide policy against passphraseless SSH keys for developers. Github compares it to leaving your password in a file on your computer for attackers to find, but it's MUCH worse than that. Such a password file could be anywhere on your computer and an attacker would have to search for it and may never actually find it unless it was clearly labelled. SSH keys are defined in your SSH config file and attackers know exactly where that lives. Using a passphraseless ssh key is more like leaving your password on a sticky note attached to your monitor. This article is spreading bad advice here to users who don't understand why, and the author should update his post and retract it.

hollerith 16y ago
Help me out here: if an attacker can get into my account on my OS X or Linux box, he can run sudo, which means he can replace my ssh client with one that will capture my passphrase the next time I use it. Can you give a concrete example of a scenario in which an attacker will be able to read my SSH config file but not be able to get into my account? Suppose the SSH config file is not backed up. I am not saying you are wrong about the need for a passphrase, BTW.
- rmc 16y ago
  On Linux you need to enter your password to run sudo. If someone can read all the files in your home directory but not make you enter sudo, then they can see your ssh keys but be unable to replace /usr/bin/ssh
  - hollerith 16y ago
    Thanks. I have been using OS X where sudo does not ask admin accounts for a password.

sciurus 16y ago

If you learned something from this, be sure to read http://www.jedi.be/blog/2010/08/27/ssh-tricks-the-usual-and-beyond/ http://www.jedi.be/blog/2010/08/27/ssh-tricks-the-usual-and-...

n00b4evr 16y ago

+5 AGILITY.. nice touch XD