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.
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.
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.
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.
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.
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.
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 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.
> 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 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.
I only accept keys on non-standard SSH ports.
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.
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.
1 reply →
> ssh from the phone
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.
1 reply →
If I’m skiing in the alps there’s no fucking way I am on call, and you shouldn’t accept it either…
1 reply →
As someone who works with SREs every day, this breaks my heart.
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.
1 reply →
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.
4 replies →
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 configure password login for root on on standard port for all servers I personally control. Moreover, they all have the same root password.
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.
sry to be that guy (with a snarky comment):
> 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.
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.
I use a Yubikey with ssh keys, and suddenly I have my ssh keys available anywhere, while I also avoid them being stored in any single host.
The first time I actually read this as "... and suddenly I can lose my ssh keys anywhere"
why not both? :D
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.
SSH is standard and it’s open. Tailscale is commercial and closed.
Well yes but headscale?
Why not use port knocking as well?
Port knocking is so 2014. Single Packet auth for publicly exposed hidden services is great: https://github.com/mrash/fwknop
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.
Not sure if this is the best, but I use nftables and this article helped me setup port knocking on a debian server: https://home.regit.org/2017/07/nftables-port-knocking/
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:
It's convenient and fail2ban/crowdsec is generally a sufficient safeguard. Bruteforcing isn't realistic so you just have to keep an eye on vulns.
Key auth is obviously better, but password auth is not as bad as many people like to pretend.
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.
> 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.
Now you can drop the PIV or PGP dependencies. OpenSSH can use webauthn to derive SSH keys.
Yes, this.
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.
Does every random system automatically picks up Yubikey? Does SSH on all platforms find that key?
Up to date systems should support it since about 2021
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...
Three layer of defense on default Port here.
1. ufw limit ssh.
2. Ansible devsec.hardening.ssh_hardening
3. fail2ban
It can thwart a local keylogger from getting your password. But of course if you have a local keylogger, you're probably quite fucked already.
But there's at least some "security in layers" benefit there.
If it is a software keylogger then getting the key is even easier...
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.
1 reply →