I used to use lots of port knocking setups to hide my ssh port. That was, until I discovered Tailscale's SSH setup. Now my SSH is run over wireguard which is very stealthy.
I'm all for almost all my servers not accepting passwords, but it's a scenario that I think about, so there's one server running ssh on an non-default port that takes a password so I can break back in using only what's in my head (hopefully I don't get hit so hard in this mugging so as to forget what I've memorized).
sshd can be configured simply not to allow root logins. To use root, you log into some other account and then su. That other account can have a name that attackers will never try, and a decent password.
Then, if you happen to be using a log based banning system, since you know that no legitimate user would be trying the name root, you can impose an instant ban on such an IP address, with a long duration. It's really just for reducing traffic more than anything.
Regarding aliasing root, you can create an alias for the UID 0 user simply by editing your password and shadow files to create duplicate entry. If the root entry appears first, then that name is still used whenever a UID is resolved to a user name, like in your ls -l and whatnot.
The shadow entry for root can have a star in the password field so that it cannot be used for logging in by any means; only the alternative name can be used via the other entry that has a password set up in its shadow entry.
!
!!!
?
#$
The valid users they are trying are: avahi backup bin daemon Debian-exim foo games gdm gnats hplip irc libuuid list lp mail man messagebus news nobody ntp postgres proxy root saned sshd sshroot statd sync sys uucp www-data
None of these allow login; they have a * in the shadow file.
The whole thing is kind of moot though. For other reasons, you should just wrap all this stuff up in WireGuard and never think about it again. WireGuard is silent; you can't probe it.
It also reduces noise in the logs, but you could get that by not logging unsuccessful login attempts.
I don't favor port knocking. I tried it many years ago; it wasn't worth it.
> should just wrap all this stuff up in WireGuard
Suppose I just bought a burner phone in a foreign country. How easily can I set this up from scratch?
SSH with passwords: just install Termux, add ssh package, and go.
The point isn't that passwords are evil, it's that SSH passwords are evil.
As a result of this HN discussion, I disabled all SSH logging, and turned off the associated banning system. I disabled the use of PAM by sshd, and set its logging level to FATAL (because the ERROR level stupidly still logs when sshd is not able to find a shadow entry for a user ID).
I'm confident they are not getting in by guessing a password and no longer believe there is a net saving in resources by monitoring and banning.
2. Get the backup forms of 2FA out
For anyone else reading this, generally speaking one shouldn't use passwords for SSH in 2024. Use public key auth instead.
> Why is it so amazing?
OpenSSH isn't invulnerable. It can have zero-day vulnerabilities. But if it isn't even listening on the public internet, that's one less attack vector.
Zero day ssh bug? I’m not NSA, how often does this happen to random servers?? Again, never have been hacked in more than 20 years. Still support some servers with ~6 year uptime.
Unfortunately, you're not convincing anyone. Amongst the security conscious, multi-year uptimes are the opposite of a brag. And it doesn't matter how you spin it, key-based auth is best practice, as is reducing your attack surface.
It seems that some of these measures are too difficult for you, and that's fine. But trying to argue that the measures are pointless is just false.
So, are you NSA? How many servers have you lost to the password attack vector?
Well on the one hand you make it seem like you're here for genuine adult conversation.
On the other hand you call people that disagree with you the "NSA".
And that is the point this conservation has outlived its usefulness :)
But, in fact, hosting a competitive gsmijg website, I did experience common brute force and and other types of attacks, but fail2ban did foil them for years :)
None of the attackers were ever sophisticated enough to come up with a successful attack (that I know of :))
The point is, should everything be do all the best practices as if they were equally likely to be attacked?
It’s like saying that everyone should also have a faraday cage house, and electrified fences, it is the best practice, after all.
PS. So, hi!
At the same time for most users certificate-based login is easy (no need to enter a password every time) and they've already got it set up, because github and AWS work that way.
From my POV, the principal risk is opsec mishaps, which may lead to leaking a public key or a password alike.
With public keys, this is not possible. The worst case of credential theft from MitM would be hijacking a forwarded SSH agent, which would require a deliberate (and highly discouraged) client configuration.
I feel like syncing a password-protected private key for break-glass use would be better than syncing a password database (given the same master password, key-stretching, and syncing strategy...or even just encoding your private key in a "secure note" field instead).
Anyway, I think it is reasonable to assume that if you're using the "escape hatch" as mentioned by /u/nine_k, you may well not have your .ssh/known_hosts file on your client. In which case public user-authentication keys minimizes your blast radius of a MitM host.
Also, a compromised (but legitimate) host could still grab your password and try lateral movement (mitigated if you don't reuse your break-glass password, but you get it for free with public keys).
The attackers are not cracking a password hash with GPUs; they are just connecting and guessing.
People who use passwords with SSH of course use passwords they can remember and type.
If the attackers are trying to brute-force your password by attacking the hash, that means the machine was already compromised. The password then has no value, unless you're re-using it for other machines.
The user who thinks they need a 30 character random password for SSH (if they were to use one) will of course opt for keys instead.
Let's assume I have an uncommon user name (not root or www-data, ...) and not anything from my domain name or e-mail address or whatever, and a nine character password made of lower case characters and digits, reasonably easy to remember.
Regarding _your_ scenario, cool bro, do whatever you want. However, if you reuse that password for any other servers, you're open to lateral movement attacks, which keys mitigate.
Actually I guess that's my main argument: you can mitigate the downsides of passwords, but keys are super simple, well-supported, and require no such fussiness. Just generate it, set a password, authorize it, forget it. Threats mitigated. If you want to futz about with workarounds, be my guest. I have no such desire.
BTW, that remark I made about known_hosts applies to keys. You could put your SSH client keys (I mean private ones) on some HTTPS URL, so that you could fetch them to a brand new machine (e.g. burner phone purchased abroad).
And that's back to passwords: anyone else knowing that URL could fetch those keys, and their security depends on their password phrase. So we are back to relying on the strength of a password phrase as well as faith in attackers not knowing anything about such an URL.
Oh right; the URL could be .htpasswd protected too, let's not forget. :)
Accessing a password-protected page over https is pretty much exactly the same access control + encryption as using a password with SSH.
So, thank you for confirming my understanding: keys are just as / more convenient from the ops standpoint than passwords. The weakness is only in short, guessable passwords.
So you should not rely on fail2ban to keep you safe from anything, and you are introducing DoS risks. Very bad tradeoff imho, making it only good as a last resort.
In general, fail2ban is often setup to indirectly whisper to a firewall API. The firewall is smart enough to enforce white lists, and custom rate-limiting traffic rules.
i.e. to survive a DoS, the server enforces the traffic profile that chokes off users violating normal rules (ratio of TCP packet types, UDP volume %, and TTL count variance per IP.)
In general, for DDoS you just drop the traffic to a fixed cost CDN with a CAPTCHA to issue real users session tokens, or issue a 302 to 127.0.0.1 for everyone else hammering the site.
Have a nice day, =3