Hacker News Reader

Comment by Borealid | Hacker News Reader

What people think of as a very strong password often has <100 "security bits" of entropy.

Keys are usually at least 128 bits of entropy, and it's easy to take them up to 256.

Yes, both are a shared secret, but password auth - even with challenge-response - is weaker than key auth exactly because key auth provides more guess resistance.

View on HN

But the SSH keys are based on asymmetric crypto, not shared secrets.

That makes it impossible to steal the key if you MITM, but there is still the same chance of guessing it. (Assuming password has as many bits of pure randomness, such as machine generated password.)

> What people think of as a very strong password often has <100 "security bits" of entropy.

The best password in the world will still be defeated by a simple keylogger or breach of your password manager.

The best cryptographic key in the world would be defeated by a breach of your filesystem.

The comparison here is between in-memory cryptographic keys and in-memory passwords. Yeah typing a password into a keyboard adds a vulnerability in between the keyboard and the computer, but it's not a huge difference in security posture. If the device using the secret is compromised, so is the secret, whether it came from the user's mind or not, whether it was stored encrypted before the user used it or not.

A physically separate hardware security module does add protection but I think that's a different conversation.

2^100 is a lot of things to try though

Especially if you have Fail2Ban set up.

Fail2Ban is kind of required unless one like running out of sockets and are unburden by high cpu and disk load.

Huh? I run ssh (OpenSSH) on port 22 with root login enabled and no fail2ban on a single-core laptop cpu from fifteen years ago. The load average is 0.00 even with the small mail and web server that runs on it

What cpu and especially what disk load are you talking about? Also not running out of sockets, not sure if that's RAM-dependent (the box has 2GB)

Working as a sysadmin, and with disk encryption the constant log writes generated from ssh was enough to cause heavy load on severs. Long lasting connections from bots also forced us to increase the maximum number of sockets, as some scan waves was enough to hit the maximum and block other connections. Fail2ban has mitigated those issues to the point where neither has been an issue.

I believe this depends on your exposure level. If you have one, or maybe no, domain names pointed at your server, you are probably fine. If you have tens, or hundreds, of domains pointed at your server (i.e. you are a web site hoster), you will probably need something like fail2ban.

On another server with the same setup, there's various services and websites running, so load average is never zero there (due to scrapers) but ssh has yet to catch my eye in htop. Whenever I've looked, even the amount of cpu that a Windows VM uses constantly while idle is many times higher than what ssh uses

There is regular bot traffic attacking SSH, but it's not "saturate your downlink" level of traffic. If you're getting attacked that heavily then you're being specifically targeted.

> if you have Fail2Ban set up.

Worth noting that if you are running a remotely recent version of SSH it has everything you need built-in. No need for Fail2Ban on SSH these days if your config is fully modernised.

Could you maybe explain a bit more about how one sets up OpenSSH to block brute-force login attempts with only its built-in features?

> Could you maybe explain a bit more about how one sets up OpenSSH to block brute-force login attempts with only its built-in features?

There are various ways, but you will probably want to start by investigating a combination of the below tuned for your environment :

      - PerSourceMaxStartups
      - PerSourceNetBlockSize
      - PerSourcePenalties
      - Match Invalid-User + RefuseConnection

`PerSourcePenaltyExemptList` is also worth a mention if its the sort of thing you like, we don't use it at $work as whitelisting IP ranges is not really in-line with modern security best-practice (zero trust etc.).

Reply on news.ycombinator.com