Fail2ban security update

Re:Fail2ban security update by WestCoastJustin on Thursday July 17, 2014 @06:42PM (#8050669)

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...

[ Parent | on HN ]

Re:Fail2ban security update by viraptor on Thursday July 17, 2014 @06:51PM (#8050699)

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)

[ Parent | on HN ]

Re:Fail2ban security update by lloeki on Friday July 18, 2014 @07:50AM (#8052517)

> 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.

[ Parent | on HN ]

Re:Fail2ban security update by pjc50 on Friday July 18, 2014 @08:35AM (#8052652)

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.

[ Parent | on HN ]

Re:Fail2ban security update by sneak on Thursday July 17, 2014 @07:18PM (#8050794)

> 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".

[ Parent | on HN ]

Re:Fail2ban security update by pyre on Friday July 18, 2014 @01:28AM (#8051807)

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?"

[ Parent | on HN ]

Re:Fail2ban security update by Spooky23 on Thursday July 17, 2014 @10:30PM (#8051375)

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.

[ Parent | on HN ]

Re:Fail2ban security update by tacticus on Thursday July 17, 2014 @08:45PM (#8051112)

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

[ Parent | on HN ]