
SSH: Use Password or Public-Private Keys? - dopkew
http://lwn.net/Articles/369703/
======
lutorm
I use one key everywhere, but the private key lives on two places only: a usb
drive on my keychain and on a backup floppy. When I sit down at a system, I
load the key into the agent and then unmount the usb drive. It seems that the
only way the private key could be compromised is if someone breaks into the
agent when I'm on the machine or if someone spoofs the connection to the agent
(which, if I understand correctly, won't give them the key, only the ability
to use the key while the agent is running).

If the usb drive is lost/stolen, there should be no information that reveals
which systems it works on. The key also has a very long passphrase, since I
only type it once per day, so that should at least make brute force attacks
against the key difficult.

This seems like a pretty secure solution to me. What other weaknesses can you
think of?

~~~
meastham
_(which, if I understand correctly, won't give them the key, only the ability
to use the key while the agent is running)_

By design, talking to to the ssh-agent should not give you the decrypted key.
However, in reality, anybody that could write to the ssh-agent socket could
also ptrace() the agent and find the key in its memory. That would of course
require becoming the user you are running ssh-agent as, but that's typically
not very difficult.

 _What other weaknesses can you think of?_

A key logger.

Basically, if you don't trust the system you decrypt your key on, all bets are
off.

~~~
lutorm
Yeah, talking to the agent _on the same system_ , I agree. But I think the
risk of compromising the agent are a lot higher through the forwarded
connection (which I use to log into highly populated systems). And I meant
that through the _connection_ you shouldn't be able to get the key.

The key logger is a good point, but I basically only log in from my laptop,
office computer or home computer. Only if one of those three are compromised,
as opposed to one of the innumerable machines I log in to, should that be a
risk.

------
dedward
Speaking from experience, while keys are more useful, and more secure if
universally used properly - I've seen keys bite firms where it hurts much more
often than passwords - because people at some level leave an unprotected key
laying around, and that key ends up with root level access to a huge array of
servers. The argument is made, in the article, that if people won't password
protect their keys they are equally likely to email their password - but this
doesn't ring true - it's more logical and straightforward for people to
understand a password that needs to be kept secure than a keyfile, which is
more abstract and they may not understand.

So - does that mean I wouldn't recommend using keys? No - but if you are going
to use them, you have to couple that with strict policies regarding usage and
rotation.

I use keys for systems where I'm the sole administrator - because I know MY
key management practices - but in group situations, we generally stick to
passwords as the primary entry point (and then perhaps keys when it comes to
accessing clusters of servers - but we tend to treat those clusters as a
single functional machine, so keys make sense here)

~~~
eru
Wouldn't key + passphrase be at least as secure as a password?

~~~
Spark23
certainly, but you'll have to guarantee that no user has a keyfile without a
password, which is harder than checking for weak passwords on your server...

------
chrisbroadfoot
Even better: two factor authentication.

<http://en.wikipedia.org/wiki/Two-factor_authentication>

Are there any examples of people using these to access a sshd? I know it's
becoming common practice for access to VPN, etc. but it'd be nice to have this
without the hassle of a VPN.

~~~
andreaja
It used to be possible to require both password and pubkey authentication
(which is a form of two-factor authentication). Unfortunately this was
discontinued in newer versions of OpennSSH (I have no idea why).

~~~
lukeschlather
Strange. You could still probably rig something with a jailshell that requires
you to su.

------
Yaggo
I use key-based authentication with password-protected key. I don't (mostly)
have to type the password, because OS X is smart enough to store it to
keychain (if enabled). I also have FileVault enabled and my login password
prompted when resuming from a sleep, so I think my private key is pretty well
protected.

~~~
pistoriusp
Are you saying that OS X remembers your SSH passwords?

~~~
gommm
No it remembers the password of the private key... On linux, you can get
something similar with ssh-agent

~~~
bobds
I also use ssh-agent on Windows, through msysgit. I think putty also includes
some utility that does the same thing.

~~~
mooism2
Putty has Pageant.

------
Jabbles
What's the problem with brute-force attacks? Why can't a simple incorrect-
password timeout prevent them?

~~~
JoachimSchipper
There doesn't appear to be a way to prevent these attacks without locking out
legitimate users, making DoS (denial-of-service attacks) trivial (thereby
locking out legitimate users), or both. The fundamental problem is that the
bad guys can open lots of connections.

Suppose you pause for 10s (after an incorrect password/before checking the
password/...). This make it very easy to spawn so many sshd processes that you
end up with a DoS (either the system stops spawning sshd processes, locking
out everyone, or it is overwhelmed). If you solve this somehow, the bad guys
can just open a ton of connections and just wait 10s - they'll need more
connections, but they can still saturate the link with login attempts.
Blocking IPs after too many connections doesn't help much against botnets;
limiting the number of total connections locks out legitimate users; blocking
all but specific address blocks locks out legitimate users (at home, or your
sysadmin-on-a-holiday trying to fix your system in an internet cafe halfway
across the globe.)

In short, anything you do seems to make it easy (easier) to lock out
legitimate users. On the other hand, switching to private-key-only or private-
key-and-one-time-password-only (or instituting a check on password quality)
makes this attack infeasible.

~~~
Jabbles
Why doesn't opening a large number of connections to a server secured by
private-key work as a DoS attack? Isn't the number of connections required to
overload the system the same regardless of security method?

~~~
JoachimSchipper
The number of connections is equal, but it is - at least in theory - possible
to set a lower timeout when using private keys.

------
steveb
There are a lot of open issues with ssh keys, especially in an internal
environment with a lot of end users. Is is difficult to control the
distribution of keys or force a key password policy.

1) Users will copy their .ssh directories to every server they have access to
so that they don't have to type in passwords. To deal with this:

    
    
      a. You can limit where public keys are stored with the AuthorizedKeysFile directive in sshd_conf. Force all keys to be controlled by root and in a central location. 
    
      b. Implement kerberos so that users don't need to use keys for single sign-on.
    
      c. only allow keys for functional ids (i.e. mysql), use IP filtering (from=xxx.xxx.xxx.xxx) on the public key to limit key access to a few administrative servers. 
    
      d. If NFS homedirs are exported to the world, any attacker can mount them and read off the keys from .ssh directories.
    
    

Other folks have mentioned brute-force attacks against your ssh daemons on the
public internet. If possible, you should think about using a VPN/two-factor
authentication to get access to your network or internal gateway servers.

------
steveklabnik
My friends and I recently changed our server over from password to key-based,
and a small unintended consequence came up: I could no longer SSH from my
phone! I'm told that I can get my key on my phone somehow, but I've been too
lazy to actually do it. Luckily I figured this out before it was important.

Then again, I'm not sure how important that actually is...

~~~
LiveTheDream
TouchTerm on iPhone supports SSH keys.

~~~
Legion
iSSH does as well.

What I did was put my key in Dropbox, load it from the Dropbox app, and copy-
paste as needed. Then took the key out of my DRopbox when done.

------
iuguy
Use password-protected key pairs when you can, passwords where you can't.

And always check the key fingerprints.

