It's also useful for applications where you have to use passwords or where you need to allow anonymous requests but you don't want attackers using up all of your resources. VoIP (public-facing and handset-facing SIP) servers are my example of both of those situations.

If someone's out to get you, then sure, they'll find the port.

If someone's out to just find any unlocked door, they'll just move on.

    ~> cat .ssh/config
    ControlMaster auto
    ControlPath /tmp/%r@%h:%p
    ControlPersist yes

    Host hostname1
     IdentityFile ~/.ssh/id_rsa
     Hostname rem.hostname1.com
     Port 2290
     user user_name

    git clone ssh://username@hostname1/home/user/Code/repot.git

    scp file1.tar hostname1:/home/username && sftp hostname1

In my case, I also use it to prevent other abuse: bans for ssh abuse protect other hosted services, and fail2ban has been modified to act on other forms of abuse too (like spam).

Using regular expressions on logs and triggering such massive actions like IP-based bans isn't a wise thing to do. Logs are not the trivial lines of text they were 10 years before. In reality you'd have to deal with chaotic stuff often even including user-entered data - this is why there are so many classical Big-Data programs and algorithms are joining the party here. It's very hard to write solid regular expressions on those without overseeing a tiny DoS possibility because of injection. There are numerous examples in the CVE database for exactly this when you look at fail2ban and other programs using the same scheme...

If you really need to keep your logs clean and there is no way in detecting "unusual behaviour" by filtering out all those background noise you see on SSH usually, why not use iptables with it's extensions instead? You can easily count the attempts to connect to defined ports and block any IP address reaching a threshold for a limited amount of time. This is a way more solid implementation of the same thing as IP packages are well-defined structures and there is simply no way in injecting something in the IP source field of them.

About the hardware consumption by SSH login attempts: you guys aren't honestly arguing that a cronjob-like grep of log-files and performing regular expressions on hundreds of lines is a way better to do the same, right? This is actually highly inefficient too...

For me, even plain iptables filtering isn't a nice thing. I use port-knocking to get access to my SSH services. Every server has it's unique sequence of packages to tell it to open access to SSH for a IP transmitting the right packages with the right flags and payload in the correct ordering.

I'm not saying "get rid of fail2ban", but people should know what they are doing and what problems come with those programs. The convenience has it's price...

tools like fail2ban are not only for SSH!

I also use log monitoring and banning to ban http connections to my web server (driven by scanning apache logs), as well as SMTP connections (scanning Exim's rejectlog).

The rationale "do not use password authentication" does not apply to unauthenticated HTTP and SMTP requests.

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

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

Possibly you mean, in one's ~/.ssh/config:

    Host *.trusted.hosts another.one.trusted
        ForwardAgent yes

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.

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

You can have batch processes push them out periodically.

You can put public keys in LDAP

You can configure SSH to use Kerberos.

It is amazing how much this needs to be repeated, but security is not an absolute. Fail2ban adds another layer of security, thus it is a good thing.