5 ms·

How do you manage ssh keys once deployed? From personal experience using both systems, my thinking is that once you start deploying ssh keys, in a larger user/s

How do you manage ssh keys once deployed? From personal experience using both systems, my thinking is that once you start deploying ssh keys, in a larger user/server environment, you have a massive rats nest. There is little to no life cycle management. Fail2ban works and should be deployed regardless of whether you are using usernames/passwords or keys. I just checked one of our bastion hosts, and there are 384 banned IPs (on a rolling 30 day basis). This info is useful, and can be fed into other systems, like edge network devices. There is actually a good article about this @ http://www.networkworld.com/article/2164048/tech-primers/ssh-key-mismanagement-and-how-to-solve-it.html http://www.networkworld.com/article/2164048/tech-primers/ssh...

viraptor 12y ago
That's one weird article (or maybe people really do that... I would hope they don't): > mesh of key-based access is so dense that it is highly likely that an attack can spread to nearly all servers in an organization Why would you ever do that? Keep the keys where the users are. There is no mesh unless you distribute the private keys and you should never do that in the first place. ssh-agent can be used if you really need to have multiple hops. > odds are the virus will infect nearly all servers [...] including disaster recovery and backup systems that are typically also managed using such keys Why would you store private keys to your DR/backup servers all over the place? Backup is safer if it works via pull. There are problems with SSH key management, but the situation they describe looks like there are issues with the design in general. (as for the keys management - there are many solutions allowing reading public keys from ldap - that solves some of the problems)
- lloeki 12y ago
  > ssh-agent can be used if you really need to have multiple hops. Possibly you mean, in one's ~/.ssh/config: Host *.trusted.hosts another.one.trusted ForwardAgent yes The restriction with Host is that otherwise an untrusted host (or someone having compromised your remote account) could use your agent forwarding socket to identify as you.
- pjc50 12y ago
  Keep the keys where the users are That's in the user's home directory. Which is stored on the network ... The other antipattern is defining a passphraseless key for root@serverA and putting that in authorized_keys on serverB. This is trememdously useful but insecure.
sneak 12y ago
> How do you manage ssh keys once deployed? From personal experience using both systems, my thinking is that once you start deploying ssh keys, in a larger user/server environment, you have a massive rats nest. There is little to no life cycle management. Same way you manage any other keys - configuration management software. "Keys are hard to manage" is not a valid argument against "you should not be using passwords or fail2ban".
- deleted 12y ago
  [deleted]
- pyre 12y ago
  Maybe I'm missing something, but where does fail2ban come in on the "keys vs. passwords" debate? Do I become more vulnerable if I run fail2ban on a keys-only ssh setup? If not, then why is the argument "don't use passwords or fail2ban" rather than just "fail2ban doesn't provide adequate protection for allowing passwords on ssh?"
tacticus 12y ago
You can put your pub keys into ldap and get sshd to query that when you try and connect.
Spooky23 12y ago
There are many methods. You can have batch processes push them out periodically. You can put public keys in LDAP You can configure SSH to use Kerberos.

viraptor 12y ago

That's one weird article (or maybe people really do that... I would hope they don't): > mesh of key-based access is so dense that it is highly likely that an attack can spread to nearly all servers in an organization Why would you ever do that? Keep the keys where the users are. There is no mesh unless you distribute the private keys and you should never do that in the first place. ssh-agent can be used if you really need to have multiple hops. > odds are the virus will infect nearly all servers [...] including disaster recovery and backup systems that are typically also managed using such keys Why would you store private keys to your DR/backup servers all over the place? Backup is safer if it works via pull. There are problems with SSH key management, but the situation they describe looks like there are issues with the design in general. (as for the keys management - there are many solutions allowing reading public keys from ldap - that solves some of the problems)

lloeki 12y ago
> ssh-agent can be used if you really need to have multiple hops. Possibly you mean, in one's ~/.ssh/config: Host *.trusted.hosts another.one.trusted ForwardAgent yes The restriction with Host is that otherwise an untrusted host (or someone having compromised your remote account) could use your agent forwarding socket to identify as you.
pjc50 12y ago
Keep the keys where the users are That's in the user's home directory. Which is stored on the network ... The other antipattern is defining a passphraseless key for root@serverA and putting that in authorized_keys on serverB. This is trememdously useful but insecure.

sneak 12y ago

> How do you manage ssh keys once deployed? From personal experience using both systems, my thinking is that once you start deploying ssh keys, in a larger user/server environment, you have a massive rats nest. There is little to no life cycle management. Same way you manage any other keys - configuration management software. "Keys are hard to manage" is not a valid argument against "you should not be using passwords or fail2ban".

deleted 12y ago
[deleted]
pyre 12y ago
Maybe I'm missing something, but where does fail2ban come in on the "keys vs. passwords" debate? Do I become more vulnerable if I run fail2ban on a keys-only ssh setup? If not, then why is the argument "don't use passwords or fail2ban" rather than just "fail2ban doesn't provide adequate protection for allowing passwords on ssh?"

tacticus 12y ago

You can put your pub keys into ldap and get sshd to query that when you try and connect.

Spooky23 12y ago

There are many methods. You can have batch processes push them out periodically. You can put public keys in LDAP You can configure SSH to use Kerberos.