

SSH Do’s and Don’ts - gpapilion
http://blog.hypergeometric.com/2012/02/22/ssh-dos-and-donts/

======
cmsj
Since I can't comment on the site itself:

* don't use agent forwarding ever. If you know better, be damn sure you are right

* don't back up your private key. If you lose it, generate a new one and have someone add it

* do use passwordless keys, but only if they are command (and preferably IP) locked to trigger specific jobs

* use RSA keys, not DSA keys (see Debian random number fiasco for why)

I covered some of this in [http://www.tenshu.net/2012/02/sysadmin-talks-
openssh-tips-an...](http://www.tenshu.net/2012/02/sysadmin-talks-openssh-tips-
and-tricks.html)

~~~
abhaga
> don't use agent forwarding ever. If you know better, be damn sure you are
> right

I am curious. Why do you say this? My use case for agent forwarding is during
automated deployment. Without agent forwarding, when pulling from SVN, I
either need to enter password every time or have my private keys uploaded to
the server where I want to deploy.

~~~
ajross
You probably need to rethink the security characteristics of your deployment
architecture. You shouldn't be authenticating from a production host (which is
presumably internet-facing, and thus more likely to be compromised), you
should be pushing to it from a more protected source like a build machine
behind a firewall.

Using agent forwarding in this case is _precisely_ the problem being
discussed. If someone roots your web server (or whatever it is), they can
authenticate as your ssh account to any host that accepts it. So at a minimum
your subversion server will be compromised if _any_ of the production hosts
are. Bad.

~~~
abhaga
> You probably need to rethink the security characteristics of your deployment
> architecture.

I'm wiser now :). Although till I don't move to a push model, I think I will
explore the restricted keys as suggested by ryan-c and use them.

Unfortunately, none of the one shot deployment systems point this out. Most of
them do a git pull on production. When I built mine, I wanted to avoid putting
my private keys up on the production, so I went with Agent Forwarding.

------
mapgrep
This would seem contradictory:

" _Don’t Use a Blank Passphrase on Your Key_ This is basic security, plus
allows you to “safely” move your keys between hosts..."

Then:

" _Don’t Copy Your Private Key Around_ Remember this is your identity... Its
never a good idea to copy it from system to system."

So put a passphrase on your private key so you can move it between systems,
but also don't ever move it between systems.

Side note: I get annoyed by advice about how one should always always put a
passphrase on private keys. It makes unchecked assumptions. The private keys
on my laptop are stored on a fully encrypted drive that locks every time the
computer sleeps. This laptop has far more sensitive data on it than the remote
hosts I access (github and a VPS), which serve virtually all their unique data
to the public via the web. I'm fine with a naked private key on this machine.

~~~
talaketu
Do you recognize the threat of malware (such as a random script you download)
just copying the private key and shipping it off?

A passphrase defeats that threat. And integrating the ssh agent with something
like the gnome keyring means you never even have to remember your passphrase.

~~~
mapgrep
I confess, I hadn't thought of that threat. It's an interesting thing to think
about.

My initial reaction is this: Couldn't malware on my laptop also monitor my
keystrokes when I unlock the key? Or when I log in to my VPS web interface? I
mean, if the goal is to have a malware infested computer that is no threat to
external systems, it seems like there are tons of other files/apps/system
you'd also want to password protect, to the point of making the computer
almost impossible to use.

Still, it's an interesting point. SSH keys are more sensitive. I do keep an
extra password on my password manager.

~~~
blibble
aye, it's pretty easy to ptrace() ssh-agent and extract the key directly from
memory.

once malicious third party code has executed on your machine as you it's game
over.

------
orbitingpluto
Extra Don't:

Don't blindly accept key fingerprints, especially when the public key should
already be in your known hosts file already and then type the password! ssh-
keygen -l -f file is your friend.

Extra Dos:

1) Lie to your PHB that telnet is no longer included and that everyone must
now use SSH and that there is absolutely no option to not have account
passwords anymore. (This is a true story.)

2) Use it! Tunnel through port 53 and redirect to port 22 down the line when
you are at a coffee shop instead of clicking on the "I Agree" button on the
web portal and having everything you do being data mined. (In a TOS I saw one
that granted perpetual rights to access your FB account - until you change
your password of course. You had the option of using a CC to purchase access
or by logging into FB.) Most of these coffee shop/airport portals don't block
traffic on port 53 because of DNS. Most Starbucks block TCP on 53 now.

------
caf
The article contains a mistake - where it says _"Don’t Copy Your Public Key
Around"_ it really means _"Don’t Copy Your Private Key Around"_.

The advice to use ForwardAgent is also dubious, at least without fully
describing the implications - which is that if you log into a compromised
host, that host can use your credentials to access other hosts.

~~~
munin
in the presence of compromised hosts using ForwardAgent is basically analogous
to copying your private key around! (somewhat)

~~~
ninjin
Agreed, I personally counter this by having different private keys for
different networks and levels of security clearance. My work key gets me onto
the work networks, once inside, I have a network specific key to use inside
the network itself. This way I don't need to use ForwardAgent and my personal
boxes will not be compromised if my work or any of my friends are.

------
there
Using SSH agent forwarding should be used with caution, and with prompting
enabled:

[http://jcs.org/notaweblog/2011/04/19/making_openssh_on_mac_o...](http://jcs.org/notaweblog/2011/04/19/making_openssh_on_mac_os_x_more_secure/)

------
mappu
\- Don't use the default port

\- Disallow root login

~~~
alexchamberlain
I'm not using the default port on one machine, but I do on the other. With key
based login, is it really necessary?

~~~
ichilton
If you don't run ssh on port 22, it's been proved that it receives a _lot_
less outside login attempts and stops the logs filling up with login failures
apart from anything else.

~~~
alexchamberlain
Logs filling up with login failures is hardly a decent reason.

~~~
danielsoneg
Two reasons: 1\. Logs filling up with login failures from drive-bys masks
legitimate/focused hack attempts. 2\. If there's a security vulnerability
found for sshd, non-standard port choice reduces the risk of drive-by
scanners.

Non-standard ports don't stop dedicated attacks, but they do reduce noise that
can obfuscate a dedicated attack and can reduce your exposure to uncommitted
attackers.

------
gioele
A nice and tidy way to generate a ssh key for a single service:
[http://retrieve.tumblr.com/post/228790418/create-ssh-key-
for...](http://retrieve.tumblr.com/post/228790418/create-ssh-key-for-a-single-
purpose)

I have one for github, one for gitorious, one for each of my remote servers,
one for for my university lab boxen, etc. You should as well.

~~~
alexchamberlain
That is a fantastic website!

------
emmelaich
I (symmetrically) encrypt my private key and store it in all sorts of places.
(I'd rather not lose it)

Off Topic: I was so distracted by the apostrophe in "Do's" I spent 5 minutes
researching it. Conclusion: I think it's ok.

~~~
dredmorbius
Your private key isn't _that_ valuable. It's not like, say, a GPG key which
you've had widely signed (there's no SSH "web of trust"). Such a key can be
useful as it ages (though there are trade-offs in security -- risk of it being
compromised also rises with time). You also don't lose access to previously
encrypted data by losing an old SSH key, as you would with a GPG key.

So long as you can get new public keys loaded onto the systems you need to
access, you're just fine generating a new keypair.

~~~
StavrosK
The problem is that I have 20-30 servers (I don't even know how many or which)
that I have access to, and many times I'm the only one who can log in to them.
If I lose my SSH key, I have to go around all these boxes changing keys, and
many times there's nobody to let me in.

~~~
jpitz
Thats a problem you have a lot better chance of solving before you lose an SSH
key than after.

------
Nick_C
> Do use ssh-agent

> exec ssh-agent bash

Or, if you are already in bash, "eval `ssh-agent -s`" which exports the
necessary environment variables.

------
jackalope
_Don’t Leave You Agents Running After You Log Out_

You can list and remove keys with ssh-add:

    
    
      ssh-add -l
      ssh-add -D
    

See the ssh-add man page for more options.

~~~
dredmorbius
There are a few additional dimensions to this:

You're running ssh-agent on a desktop (or laptop) system which you leave
either suspended or locked (you hope) via a screensaver (see the recent
xscreensaver hotkey exploit/bug).

You're running ssh-agent directly via a shell on remote hosts (bad idea).

You can set a timeout for ssh-agent keys with the '-t life' option (default:
seconds). Or when adding an identity. However there's no way to specify this
in a config file (for sane defaults), and most mechanisms for launching ssh-
agent don't allow the user to interact with the initiation in any sane way
(e.g.: /etc/X11/Xsession*).

Specifying, say, 43200 - 86400 seconds (for a desktop), or some low multiple
of 3600 seconds (for remote sessions) might be reasonably sane.

I'd pick agent forwarding over remote agents myself.

