Hacker News

points by traceroute66 2 days ago | 0 comments

To be fair, I have less than zero sympathy for anyone who runs SSH on any platform without `PasswordAuthentication=no` in 2026.

Its not asking for trouble, it is there will be trouble, not if but when.

As for the people who say "well, I run SSH on port 942329053052". Well guess what, the bots make short work on that. We tried it at $work as an experiment, multiple bots found it in less than a couple of hours. That's why your SSH config must be hardened, preferably running on a hardened OS too.

[–] dwedge 2 days ago

> Its not asking for trouble, it is there will be trouble, not if but when.

Did any of those bots brute force a password? Because a 20 character random password is comparable in brute force complexity to an SSH key. The experiment you ran was just as valid for SSH keys on that port, and had no bearing on password vs key.

[–] traceroute66 2 days ago

> Did any of those bots brute force a password?

The point is they found the security by obscurity so-called "hidden" port in less than a couple of hours.

At that point, what they did is irrelevant. The point is that security by obscurity does not work in 2026.

> Because a 20 character random password is comparable in brute force complexity to an SSH key.

You can't be serious with your comment.

No its not.

And even then, SSH key is asymmetric, you're not sending the private key to the server. But with a password you are, which leaves you vulnerable to many attack vectors that simply do not exist with keys.

[–] minitech 2 days ago

Other points are fine, but why do you say a 20-character random password isn’t comparable in brute force complexity to an SSH key?

[–] TZubiri 2 days ago

> The point is that security by obscurity does not work in 2026.

I feel the opposite, note how most all AI vulns discovered use source code level analysis, empirically keeping source code hidden is more secure.

kerchoff’s principle is misconstrued by a voyeuristic internet that wants to see source code

[–] Ardon 2 days ago

This is a sampling error - we're only hearing about the public disclosures.

(almost) No company actually has secret source code, only source code not publicly viewable. And the LLMs crawling those don't belong to people who make public disclosures.

[–] ShinyLeftPad 2 days ago

> LLMs crawling those don't belong to people who make public disclosures

Using LLMs is a great way to empower the governments behind them (US and PRC) to cultivate a garden of undisclosed bugs in your closed commercial codebases.

[–] Aachen 2 days ago

> > Because a 20 character random password is comparable in brute force complexity to an SSH key.

> You can't be serious with your comment. \n\n No its not.

If you differ in opinion, maybe provide evidence? Especially for a claim like long randomly generated value 1 being absurdly ("can't be serious"-level) weak as compared to long randomly generated value 2

If you mean it's log(62^20,2)≈119 bits of entropy instead of 128+ and so it's theoretically weaker when we build a Dyson sphere around the sun to brute force that key (after somehow obtaining the shadow file, since an online attack would be way too slow), then sure

[–] Ecco 2 days ago

How is password auth weaker than key auth? Bugs in auth code can happen in both pathways. And apart from stupidly short passwords both should be equally impossible to brute-force.

In other words, conceptually, at the end if the day, isn’t a key just another name for a password, really?

[–] minitech 2 days ago

Password gets sent to the server. Private key does not get sent to the server, and authentication protocol can be forwarded safely, enabling things like ssh-agent, FIDO SSH keys. This is solvable with passwords (see: augmented PAKE), but `PasswordAuthentication` isn’t that. But there are also settings where none of this really matters, yes, to be fair if that’s what you’re referring to.

SSH certificates are cool too.

[–] TZubiri 2 days ago

password doesn’t get sent to the server, hash does.

but I guess that the hash is always the same unlike with pub priv key mechanism.

[–] mkj 2 days ago

No. The password gets sent to the server. That said, I still enable passwords on servers, but don't ever share passwords between trust domains.

[–] traceroute66 2 days ago

> password doesn’t get sent to the server, hash does.

Kind of irrelevant what gets sent to the server and what happens on the server.

Password is already easily defeatable long before it even leaves your computer, thanks to keyloggers and/or password manager breaches and/or old-school shoulder surfing (assisted in the 2026 era by covert filming and AI).

All of which are not vulnerabilities with hardware-backed keys which you don't even need a Yubikey for these days since most modern computers and smartphones have secure enclaves and/or TPMs. (Yubikeys are still great though).

[–] Borealid 2 days ago

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.

[–] Elucalidavah 2 days ago

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

[–] dagss 2 days ago

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

[–] traceroute66 2 days ago

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

[–] Borealid 21 hours ago

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.

[–] scotty79 2 days ago

2^100 is a lot of things to try though

[–] jandrese 2 days ago

Especially if you have Fail2Ban set up.

[–] traceroute66 2 days ago

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

[–] Borealid 1 day ago

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?

[–] traceroute66 1 day ago

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

[–] belorn 2 days ago

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

[–] jandrese 2 days ago

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.

[–] Aachen 2 days ago

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)

[–] belorn 2 days ago

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.

[–] teddyh 2 days ago

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.

[–] 8organicbits 2 days ago

Password reuse is the problem. The password hash is stolen from some other site and brute forced offline.

[–] dwedge 2 days ago

Same issue with key reuse. Unless you have a policy to rotate them and verify which host they login from, someone's unencrypted hard drive from 5 years ago is more likely to have a key than password.

[–] traceroute66 2 days ago

> someone's unencrypted hard drive from 5 years ago is more likely to have a key than password.

Even 5+ years ago, hardware-backed SSH keys were a thing (Yubikey). The only difference today is that its 100% easier to do keys properly because of the widespread commoditisation of secure enclaves in desktops and smartphones to support FIDO, its basically free of charge now because you're not obliged to buy a Yubikey.

[–] epihelix 2 days ago

> How is password auth weaker than key auth?

Well, it's a heck of a lot weaker in this instance (at least when `PasswordAuthentication no`)

[–] ahepp 1 day ago

In this specific instance yes, but it seems like it could have about as easily been a perfect cascade of failures in janky libc routines for checking keys as opposed to janky libc routines checking passwords.

[–] ant0ni 2 days ago

you claimed my favorite game's character name!

[–] ghm2180 2 days ago

100% and with local tool calls many AI systems will do ssh "for you" and end run around any security theatre that you may have going on with LLMs.

[–] kccqzy 2 days ago

I run SSH with password authentication on but the port binds to a ULA address. It’s fine. No need to be so absolutist.

[–] traceroute66 2 days ago

> No need to be so absolutist.

Why not ?

Even if you don't want to go all the way to SSH certificates, SSH public-key authentication is laughably easy to do.

I also don't buy the argument "but its on a ULA address". Attacker's old favourite these days is finding a way in (North–South) and then using that as a stepping stone (East–West). Also the general concept of "lower security is OK because its on the LAN" is so 1997.

[–] kccqzy 2 days ago

Yeah because if attackers are already finding a way in, they can easily read my ~/.ssh/id_ed25519. A password is strictly better, although not by much because lateral movement is very easy anyways. The only exception is if the private key is actually on a HSM, which is the case for all my SSH private keys on iOS.

[–] cozzyd 2 days ago

or password protect your key, at least.

[–] traceroute66 2 days ago

> read my ~/.ssh/id_ed25519.

No excuse for doing that these days.

You can use a Yubikey or you can use your computer's secure enclave or TPM with FIDO at no extra cost.

A password is never, ever "strictly better". Seriously, you're just making shit up now.

[–] kccqzy 2 days ago

Your comment is self-contradictory. In one sentence you say “these days” and in another you say “never, ever.” These are contradictory. What if your computer is so old that it doesn’t have a TPM?

I was already pointing out that if you have secure enclave for your private key you should use key-based authentication. That’s what I do on iOS. Otherwise a password is better than your private key in plain text on disk. So much malware steal your private SSH keys (along with your other saved passwords and browser cookies); no malware that I know of performs social engineering and tricks you into giving up your SSH passwords.

[–] cozzyd 2 days ago

Running on that port would be perfectly safe as it's outside the range of valid port numbers.

[–] znnajdla 2 days ago

This particular bug works even with password authentication turned off.

[–] sjamaan 2 days ago

Where did you get that idea? The entire bug is about password hashing. With password auth off, that's not even attempted.

[–] kijin 2 days ago

The exploit works for a user account that has no password. This is often confused with turning off password auth, especially in containers that have only one usable account.

It's not just the parent commenter. I'm sure somebody out there is going to remove their account password instead of editing their sshd_config in an attempt to "patch" this vulnerability, actually exacerbating the problem.

[–] tialaramex 2 days ago

Bug > are password logins still on? they are by default

You > This particular bug works even with password authentication turned off.

No. The bug is related to password authentication. If you do not have password authentication then you are not affected.

What freaks some people out is they chose parameters where they do have password authentication but they expect to always fail. That's a bad choice, like OK you did fit a cheap manual keyhole, but you threw the keys away thinking now nobody can open that - you realise somebody with a cheap jiggler can open it right ?

[–] znnajdla 2 days ago

read the article again

[–] traceroute66 2 days ago

> This particular bug works even with password authentication turned off.

Does it ?

Somebody here has already said "You can set PasswordAuthentication=no or update to remediate"

We don't use musl at $work anyway, so I've no means to test.

[–] unglaublich 2 days ago

I mean there are 65k possible ports so it's the equivalent of guessing an 16 bit password, i.e. two (extended) ascii characters. It's not very surprising that 'multiple bots' found it: a single `nmap` command will give you the open ports in a few seconds.

[–] tarxvf 1 day ago

N=2 but non-22 ssh ports get almost zero traffic for me at home and at work. Not zero - but very nearly zero. shrug.