Same here, PasswordAuthentication is globally No, but I always hold an special username for emergencies which is the only user allowed to login via password (easy at sshd_config file, Match User xxxx then "PasswordAuthentication yes"). Besides emergencies, also works wonders when some sysadmins insist to login via bare metal terminal and cannot use a key...
Attackers attack for a reason. For targets like my servers, they mostly want to install mining software or a DDoS bot. This is detectable via cpu or network monitoring.
I assume if someone wanted to extort money from me after encrypting the disks on my servers, I would also be somehow informed.
If the argument for a password login is being able to log in from anywhere, just store a spare ssh key (password protected) in your gmail or similar that's reasonably safe and accessible from anywhere.
But I'm having hard time imagining those "anywhere" machine scenarios. Strangers machines that you trust enough to connect to your servers, and are able to install putty or your preferred ssh client of choice on? Better just have SSH on your own phone and laptop.
> I'm having hard time imagining those "anywhere" scenarios
Hold my beer.
You ski in the Alps, its noon, and you get an alert that your DB is down.
You know this may happen because of invasive bots, and you know what to do, so you just find a calm spot at the high-altitude cafe, ssh from the phone, find the infringing bot's IPs, block them with ipset and send yourself an email to deal with the problem properly later.
Then you ski happily until dusk, knowing that users won't be affected.
I think "anywhere" here has to mean "any random device you come across", not merely "any strange location", as the premise is being able to log in with just a password rather than a key... I often use my phone to do tasks, but I do it with an ssh key on my phone.
Back when I worked from my phone while in the ski lift line, the solution really is to keep an SSH key on the phone if I intended to do any work from it.
If I really had to access work resources from any random device, I'd go through the ordeal of logging into the SSO to log in to the web console to open a temporary cloud SSH session with the multiple layers of 2FA and probably even SecOps manual approvals that's likely required.
1. It breaks my heart to see indie dev spirit die even on HN.
2. it's brittle and too automated to my taste. There may be false positives that I'd fait to review if it was too automated.
3. There should be a very limited set of passwords for your main assets. For instance, one for infrastructure, one for a password manager, one for the safe at home. And they should never be rotated. They are meant to be ingrained in muscle memory and stay with you for many years.
> There may be false positives that I'd fait to review if it was too automated.
On my little vps fail2ban has added over 23,000 ipv4's to it's f2b-ssh ipset. There is no way I'm reviewing that manually.
For what it's worth I don't allow passwords, so there is not a lot of additional security to be gained from fail2ban. I don't use it for that reason. I use it because 100's of login attempts brings my very cheap vps with bugger all RAM to it's knees. I don't particularly care that it runs like a dog when it's on its knees, but the OOM killer taking out the services I actually use it for is a step too far.
> it's brittle and too automated to my taste.
That problem largely disappears when you get rid of passwords. Fail2ban triggers on failures, and allowing passwords means you must tolerate some failures. People don't mistype public keys.
That strengthens the previous commenters point. That personal phone is not an "anywhere" device but one that already carries the necessary software and can both interface your yubikey or carry your encrypted keys.
A better example would be the same ski trip but where the data connection is bad on nonexistent so you borrow the hotel's computer to make the emergency fix.
We used to do things like that, complete with post trip password rotations. I carried a laminated card in my wallet with the important key fingerprints. But with devices like the yubikey and cheap international data roaming, that has gotten less common.
A Google or Apple phone carrying encryption keys to my precious servers? Hm... I feel already pwned.
Jokes aside, I can not be bothered installing ssh keys on my phone. Phones change, get broken or stolen. Ssh clients on phones change as well and can not always be relied upon. I want to be 100% sure I can have ssh access to my servers in whatever improbable situation.
As for Yubikey... I used it for a while as a keyboard emulator to generate a string to prepend to my corporate laptop password that had insane strength requirements.
For personal and small business auth... it is too complex and brittle.
And frankly, what's the problem with a strong password? Like... a quote from Netzsche translated in a mix of French and Dutch with a couple special chars thrown in?
We can all dream up improbable scenarios that will neuter reasonable planning and precautions.
I travel full-time and work remotely, for over a decade. I have lost my phone once. Both Apple and Android phones sync passwords and ssh keys (if you set it up) to their encrypted cloud services. If you get a new phone everything comes back.
I put my most crucial keys and backup codes on a biometric-locked USB key that I protect along with my passport. I have never needed to use it, but in case I lose my phone and can’t get into my cloud account I have that.
I use a Yubikey for 2FA where supported, I have two, one handy and one secured with my passport.
>As for Yubikey... I used it for a while as a keyboard emulator to generate a string to prepend to my corporate laptop password that had insane strength requirements.
Wtf? Tell me you don't know how to use a yubikey without telling me you don't know how to use a yubikey.
Another one: you sold an online business and forgot about it until the moment the buyer contacts you asking for a meeting exactly when you decide whether you want to go to the bomb shelter or risk staying in the appartment building so conveniently located next to a damb that protects Kyiv from flooding.
You decide that staying on the 9th floor on the path of cruise missiles to the damb is too risky, pick your good old Toughbook that has enough juice to last until dawn, and go downstairs, asking the buyer over phone to reset the root password and send it over whatsapp.
Once installed in the shelter, you quickly realize the disk is full, clean the logs and give furter instructions to the buyer to pass on to his IT.
You have sold your business but are still responsible for IT support.
You are responsible for IT support but don't already have a defined access path.
The new buyer knows what a root password is and how to gain access to a Linux machine and reset it, but does not know what an SSH key is, or how to check for a full disk.
Despite clearly being a (very specific kind of) novice the new owner is suspicious of the person responsible for his IT giving him instructions he doesn't understand?
It happened once and I hope won't happen again. I make myself available out of courtesy and I made a point that I will not be remunerated outside of the long expired knowledge transfer agreement.
Funnily, I got remunerated this one time with a lavish gift card for Neuhaus, but it only proves the point.
Of course the buyer knew the root password, details of the setup and all passwords reset procedures were part of the deal.
And of course they can reset the password when properly guided, people are not dumb even when they are not software engineers.
OTOH, most people are totaly unaware of Diffie-Hellman key exchange, the roles of public and private keys and have limited patience and even less interest in learning new things in a stressful situation.
And yes, people with money and authority have a particular distrust for people with skills and knowledge.
I should certainly hope not. I definitely won't be making "I'm providing free IT support while being bombed to someone who apparently thinks I'm some kind of conman instead of trying to help" a priority scenario in my infrastructure planning.
I was just playing around with this problem. I ended up firewalling the SSH port for all but my personal IP, then have wireguard set up so I can use it from within my wireguard network. Works perfectly so far as long as I have my clients set up.
I used S/KEY for years when I wanted to log into a remote system from a machine I didn't control. I didn't care so much about keystrokes being intercepted; I did care about my password being intercepted. S/KEY (or OPIE, depending on system) let me log in/sudo without exposing said password. I never carried around a preprinted list of codes, rather using a generator on my PDA.
It's possible to do the same thing with `pam_google_authenticator`; that is, having that OTP being the only required password, for the same reason. Nowadays this is the easier solution to go with,[1] because there are multiple OTP generator clients on all platforms, but almost all tutorials assume OTP being used for 2FA and not the only password so some more familarity with PAM beyond the tutorials is needed.
[1] Barring the requirement for read/write access to the secrets file, which SELinux complicates
> This is something that I probably care about more than most people, because as a system administrator I want to be able to log in to my desktop even in quite unusual situations.
If I understand correctly you can have your SSH key entirely on a Yubikey if you use PIV or OpenPGP.
GPG supports smartcards (yes, the plastic smartcards) since ages. The Yubikey will appear as a smartcard on GPG and will work on pretty much sny setup.
I allow password based auth to my VPS because keys are not always a possibility, and I listen on port 22 (and port 25, 465, 587, 993) because I like the convenience.
However I use some simple restrictions such as AllowUsers and pubkey auth only for root.
I think this is a reasonable defence against typical ssh dictionary attacks.
What's the best way to set up port knocking on a Fedora / Debian server? While not a security measure per se, it adds a layer of obfuscation which blocks random scanners.
I just stick remote access on tailscale interfaces these days. If something goes astronomically wrong I can get in via my cloud providers console access too.
I really don’t understand why people run sshd on the open internet anymore.
The analysis in this article is incomplete, due to missing some information which are relevant to its conclusions. It is an established pattern with his blog. Curious how it keeps showing up on the front page of HN.
> As everyone with an Internet-exposed SSH daemon knows, attackers are constantly attempting password guesses against various accounts. But if you're using a strong password, the odds of an attacker guessing it are extremely low.
The odds are zero if they are trying the wrong account names!
SSH password guessers are not probing the space of possible user names, only passwords. Look at your logs, man.
For instance, they assume that the superuser account is named root. If you don't call it root, your password could be "password" or even blank and they will never get in.
What OpenSSH needs is a your server configuration where you specify a list of allowed user names.
> [not accepting password authentication] stops an attacker that can steal and then crack your encrypted passwords
What? If the attacker steals your shadow file, they must already somehow have root. At that point, they don't have to care what you think about SSH authentication. They can leave ways for themselves to have repeated access.
> In practice, (OpenSSH) password authentication is a complex piece of code that interacts with things like your system's random set of PAM modules.
Does any of that code execute for user IDs not listed in the AllowUsers variable in sshd_config?
If I have this:
AllowUsers = 3CDF4497
will sshd execute all the PAM code and whatnot for a login attempt for user root?
This mechanism also solves the problem of some new software installation adding an administrative account with a known password. And maybe don't go installing random crap on the machine that serves you SSH access.
Okay sure, there can be this vanishingly improbable flow of events. Somehow a malicious actor knows the above root username. They're a fired IT employee, and the organization forgot to change that name, only the password. The employee uses their knowledge of the secret these are ID to attack a vulnerability in in the password auth stack.
I allow password from the internet only alongside a TOTP code.. Still gives me a backup in case of unforeseen situations but a step above plain password auth.
I don't agree with the arguments of the author: you can still use a Yubikey (or multiple Yubikeys as a backup) - which is a far more secure option than letting anyone on the internet guess an authentication factor that can be easily cloned (password).
No matter your solution, but exposing password-based SSH on the internet is a very bad idea IMHO
So this person, as a system administrator, wants to be able to sacrifice security for his personal convenience so he can login from anywhere. Does not sound like a system administrator that actually prioritises the right things. Security, especially if its not your own system, should always come first.
You have to balance those two, because the only server that's 100% secure is the one that's powered off. Everyone does that differently. I don't see sshd with key-only auth as dangerous, but password login makes me uncomfortable. Do you drive down to the data center your server is in every time you want to access it?
"I'm using VPN"
Great now you moved the target from sshd to wireguard.
>Great now you moved the target from sshd to wireguard
I definitely agree with your general sentiment, but in this case wireguard has a much better designed protocol. No response to scans, waaaaay smaller attack surface, no deep integration with a shell that needs to be explicitly disabled depending on use case, no pile of obscure authentication options that you need to make sure to disable...
Sure, but have you heard of reducing the attack surface? If you need to have to be able to log in at all times then youre probably at a scale that you have oncall processes and multiple people that can respond to incidents at a moments notice and having pub key auth enabled only makes sense. If you dont need that then youre probably small enough that that enablig only public key auth or putting it behind a vpn suffices. And having something like wireguard is much better than having something like password login enabled.
Anyone who sacrifices security for convenience is asking for trouble.
The nastiest break in I ever had worked because I installed wget on that server for convenience.
It exploited a known Drupal vulnerability to drop in a PHP script that in turn executed wget to download a payload.
So I agree about the importance of reducing the attack surface.
Now, ssh with password authenticated on a tightly controlled server, without fail2ban, port knocking and other tricky setups is exactly it. A setup with reduced attack surface.
> Anyone who sacrifices security for convenience is asking for trouble.
The you should switch off your mobile devices, destroy the sim cards and never connect again.
Less spam traffic, easier to access.
Rejecting passwords is just as much a convenience nowadays:
I just don't have passwords on my remote machines any more.
In 2024 how is this an employed person.
I mainly disabled all legacy cryptography and types of tunnelling/forwarding that I don't rely on:
https://gist.github.com/sshine/e42ecb7f9d7432e6df331eefdd490...
I also only expose SSH on public interfaces on one machine; all other machines have SSH over VPN.
Over the 20+ years, I witnessed a few security incidents. None was related to ssh, let alone a break in via a weak password.
But I ran into many situations when I needed immediate access to the server and this setup saved my day, my money and my nerves.
> Over the 20+ years, I witnessed a few security incidents.
As you said, the attackers who breached your system had ssh root access and you had no chance to detect them.
I assume if someone wanted to extort money from me after encrypting the disks on my servers, I would also be somehow informed.
But I'm having hard time imagining those "anywhere" machine scenarios. Strangers machines that you trust enough to connect to your servers, and are able to install putty or your preferred ssh client of choice on? Better just have SSH on your own phone and laptop.
Hold my beer.
You ski in the Alps, its noon, and you get an alert that your DB is down.
You know this may happen because of invasive bots, and you know what to do, so you just find a calm spot at the high-altitude cafe, ssh from the phone, find the infringing bot's IPs, block them with ipset and send yourself an email to deal with the problem properly later.
Then you ski happily until dusk, knowing that users won't be affected.
If I really had to access work resources from any random device, I'd go through the ordeal of logging into the SSO to log in to the web console to open a temporary cloud SSH session with the multiple layers of 2FA and probably even SecOps manual approvals that's likely required.
1 - Don't be on-call while going to ski
2 - fail2ban and other automated systems can do this for you
3 - Passwords suck and are typically not regularly rotated unless you're using some centralized IdP
If you're in this situation you have already failed. If you use password auth use 2FA as well, and then I don't cry, it's just toil though.
2. it's brittle and too automated to my taste. There may be false positives that I'd fait to review if it was too automated.
3. There should be a very limited set of passwords for your main assets. For instance, one for infrastructure, one for a password manager, one for the safe at home. And they should never be rotated. They are meant to be ingrained in muscle memory and stay with you for many years.
On my little vps fail2ban has added over 23,000 ipv4's to it's f2b-ssh ipset. There is no way I'm reviewing that manually.
For what it's worth I don't allow passwords, so there is not a lot of additional security to be gained from fail2ban. I don't use it for that reason. I use it because 100's of login attempts brings my very cheap vps with bugger all RAM to it's knees. I don't particularly care that it runs like a dog when it's on its knees, but the OOM killer taking out the services I actually use it for is a step too far.
> it's brittle and too automated to my taste.
That problem largely disappears when you get rid of passwords. Fail2ban triggers on failures, and allowing passwords means you must tolerate some failures. People don't mistype public keys.
That strengthens the previous commenters point. That personal phone is not an "anywhere" device but one that already carries the necessary software and can both interface your yubikey or carry your encrypted keys.
A better example would be the same ski trip but where the data connection is bad on nonexistent so you borrow the hotel's computer to make the emergency fix.
We used to do things like that, complete with post trip password rotations. I carried a laminated card in my wallet with the important key fingerprints. But with devices like the yubikey and cheap international data roaming, that has gotten less common.
Jokes aside, I can not be bothered installing ssh keys on my phone. Phones change, get broken or stolen. Ssh clients on phones change as well and can not always be relied upon. I want to be 100% sure I can have ssh access to my servers in whatever improbable situation.
As for Yubikey... I used it for a while as a keyboard emulator to generate a string to prepend to my corporate laptop password that had insane strength requirements.
For personal and small business auth... it is too complex and brittle.
And frankly, what's the problem with a strong password? Like... a quote from Netzsche translated in a mix of French and Dutch with a couple special chars thrown in?
I travel full-time and work remotely, for over a decade. I have lost my phone once. Both Apple and Android phones sync passwords and ssh keys (if you set it up) to their encrypted cloud services. If you get a new phone everything comes back.
I put my most crucial keys and backup codes on a biometric-locked USB key that I protect along with my passport. I have never needed to use it, but in case I lose my phone and can’t get into my cloud account I have that.
I use a Yubikey for 2FA where supported, I have two, one handy and one secured with my passport.
>As for Yubikey... I used it for a while as a keyboard emulator to generate a string to prepend to my corporate laptop password that had insane strength requirements.
Wtf? Tell me you don't know how to use a yubikey without telling me you don't know how to use a yubikey.
You decide that staying on the 9th floor on the path of cruise missiles to the damb is too risky, pick your good old Toughbook that has enough juice to last until dawn, and go downstairs, asking the buyer over phone to reset the root password and send it over whatsapp.
Once installed in the shelter, you quickly realize the disk is full, clean the logs and give furter instructions to the buyer to pass on to his IT.
I have had to send my ssh pub key over all sorts of messaging platforms.
You have sold your business but are still responsible for IT support.
You are responsible for IT support but don't already have a defined access path.
The new buyer knows what a root password is and how to gain access to a Linux machine and reset it, but does not know what an SSH key is, or how to check for a full disk.
Despite clearly being a (very specific kind of) novice the new owner is suspicious of the person responsible for his IT giving him instructions he doesn't understand?
It happened once and I hope won't happen again. I make myself available out of courtesy and I made a point that I will not be remunerated outside of the long expired knowledge transfer agreement.
Funnily, I got remunerated this one time with a lavish gift card for Neuhaus, but it only proves the point.
Of course the buyer knew the root password, details of the setup and all passwords reset procedures were part of the deal.
And of course they can reset the password when properly guided, people are not dumb even when they are not software engineers.
OTOH, most people are totaly unaware of Diffie-Hellman key exchange, the roles of public and private keys and have limited patience and even less interest in learning new things in a stressful situation.
And yes, people with money and authority have a particular distrust for people with skills and knowledge.
I should certainly hope not. I definitely won't be making "I'm providing free IT support while being bombed to someone who apparently thinks I'm some kind of conman instead of trying to help" a priority scenario in my infrastructure planning.
Key auth is obviously better, but password auth is not as bad as many people like to pretend.
[1] https://en.wikipedia.org/wiki/S/KEY
I used S/KEY for years when I wanted to log into a remote system from a machine I didn't control. I didn't care so much about keystrokes being intercepted; I did care about my password being intercepted. S/KEY (or OPIE, depending on system) let me log in/sudo without exposing said password. I never carried around a preprinted list of codes, rather using a generator on my PDA.
It's possible to do the same thing with `pam_google_authenticator`; that is, having that OTP being the only required password, for the same reason. Nowadays this is the easier solution to go with,[1] because there are multiple OTP generator clients on all platforms, but almost all tutorials assume OTP being used for 2FA and not the only password so some more familarity with PAM beyond the tutorials is needed.
[1] Barring the requirement for read/write access to the secrets file, which SELinux complicates
If I understand correctly you can have your SSH key entirely on a Yubikey if you use PIV or OpenPGP.
GPG supports smartcards (yes, the plastic smartcards) since ages. The Yubikey will appear as a smartcard on GPG and will work on pretty much sny setup.
To get started you’ll need OpenSSH version 8.2 or later, and you’ll also need libfido2 installed. Windows users may need to use Cygwin for this.
https://www.yubico.com/blog/github-now-supports-ssh-security...
However I use some simple restrictions such as AllowUsers and pubkey auth only for root.
I think this is a reasonable defence against typical ssh dictionary attacks.
Then I added a tripwire feature to make it less likely that a random port traversal would be successful. Here's a snippet of my nftables.conf:
I really don’t understand why people run sshd on the open internet anymore.
> As everyone with an Internet-exposed SSH daemon knows, attackers are constantly attempting password guesses against various accounts. But if you're using a strong password, the odds of an attacker guessing it are extremely low.
The odds are zero if they are trying the wrong account names!
SSH password guessers are not probing the space of possible user names, only passwords. Look at your logs, man.
For instance, they assume that the superuser account is named root. If you don't call it root, your password could be "password" or even blank and they will never get in.
What OpenSSH needs is a your server configuration where you specify a list of allowed user names.
> [not accepting password authentication] stops an attacker that can steal and then crack your encrypted passwords
What? If the attacker steals your shadow file, they must already somehow have root. At that point, they don't have to care what you think about SSH authentication. They can leave ways for themselves to have repeated access.
> In practice, (OpenSSH) password authentication is a complex piece of code that interacts with things like your system's random set of PAM modules.
Does any of that code execute for user IDs not listed in the AllowUsers variable in sshd_config?
If I have this:
will sshd execute all the PAM code and whatnot for a login attempt for user root?This mechanism also solves the problem of some new software installation adding an administrative account with a known password. And maybe don't go installing random crap on the machine that serves you SSH access.
Okay sure, there can be this vanishingly improbable flow of events. Somehow a malicious actor knows the above root username. They're a fired IT employee, and the organization forgot to change that name, only the password. The employee uses their knowledge of the secret these are ID to attack a vulnerability in in the password auth stack.
But there's at least some "security in layers" benefit there.
1. ufw limit ssh.
2. Ansible devsec.hardening.ssh_hardening
3. fail2ban
No matter your solution, but exposing password-based SSH on the internet is a very bad idea IMHO
"I'm using VPN"
Great now you moved the target from sshd to wireguard.
I definitely agree with your general sentiment, but in this case wireguard has a much better designed protocol. No response to scans, waaaaay smaller attack surface, no deep integration with a shell that needs to be explicitly disabled depending on use case, no pile of obscure authentication options that you need to make sure to disable...
Anyone who sacrifices security for convenience is asking for trouble.
It exploited a known Drupal vulnerability to drop in a PHP script that in turn executed wget to download a payload.
So I agree about the importance of reducing the attack surface.
Now, ssh with password authenticated on a tightly controlled server, without fail2ban, port knocking and other tricky setups is exactly it. A setup with reduced attack surface.
> Anyone who sacrifices security for convenience is asking for trouble.
The you should switch off your mobile devices, destroy the sim cards and never connect again.