[kwlug-disc] Curious about SSH Key security

[John Van Ostrand]

----- Original Message -----
> After following the threads on SSH security and how using Keys is more
> secure and simple in the long run, I got curious about something.
> 
> Please illuminate me:
> 
> Security traditionally should depend on something you are (identity),
> something you have (key, card, etc) and something you know (password).

Not traditionally, but optimumly it should. Traditionally we've only relied on one thing. A password is what you know, a house key is what you have. Passports are one that I can think of that encompasses two: who you are and what you have.
 
> If you use keys without password you are depending on something you
> have.
> 
> Knowing also that you are just as secure as the weakest link.
> 
> Would using keys only dilute security as now you need to depend on
> securing the keys on every computer?
>
> If someone breaks into one of the computers that has the key, wouldn't
> you be exposing the server?

This isn't a shared key. The key that is put on remote servers is the public key. Feel free to actually publish that key widely, like you do with GPG keys.

The private key doesn't need to be distributed at all. It can be kept solely on your workstation and backed up on a print-out. For slightly more security put it on a USB key so it isn't accessible all the time.

Maybe there is a way to encrypt yourj private key using data from a finger print scanner. Keep the password and you've got a three part authentication.

To some degree this is all smoke and mirrors. If someone can hack the system you put your USB key in and intercept the finger print data and log the keystrokes your security is gone.

If you need to hop from one remote PC to another you can use ssh-agent functionality.

If you use keys to automate admin tasks (like cron jobs) then the key won't be secured by password and you'll have to rely on file system security to obscure it. I recommend using a non-privileged account in this case and using sudo to prevent abuse:

e.g. 

ssh -i /etc/secure/id_backup_server_rsa backup at backup.server.com "sudo root /usr/local/bin/backup.sh"

Keep /etc/secure permissions locked down and set up sudo on the remote server to only allow running the backup.sh script. You could even investigate the use of restricted shell for the backup user to further prevent abuse.

-- 
John Van Ostrand 
CTO, co-CEO 
Net Direct Inc. 
564 Weber St. N. Unit 12, Waterloo, ON N2L 5C6 
Ph: 866-883-1172 x5102 
Fx: 519-883-8533 

Linux Solutions / IBM Hardware