7 ms·

This is great, and helps solve several problems at once. I would like to remind everyone that an internet facing SSH with a password is very unwise. I would ar

This is great, and helps solve several problems at once. I would like to remind everyone that an internet facing SSH with a password is very unwise. I would argue you need to be able to articulate the justification for it, using keys is actually more convenient and significantly more secure. Aside from initial boot, I cannot think of the last time I used a password for SSH instead of a key even on a LAN. Support for keys is universal and has been for most of my lifespan.

timw4mail 2y ago
Any time you access an SSH connection from a different computer, you basically need the password.
- LtWorf 2y ago
  If it's in the cloud, you pass the public key when creating the vm. If it's a real machine, ask the data center person to do it.
- krisoft 2y ago
  This is not true. SSH keys are a viable alternative.
  - sseagull 2y ago
    If I can be charitable, I think they mean a different computer than one you usually use (that doesn’t have the SSH key already in authorized_keys). Spouses computer, etc.
    - traceroute66 2y ago
      > If I can be charitable, I think they mean a different computer than one you usually use If I can be charitable .... What the hell are you doing storing your SSH keys on-disk anyway ? :) Put your keys on a Yubikey, take your keys with you.
      - unethical_ban 2y ago
        Right, much easier than a password! And so easy to backup! I'm not arguing it isn't more secure. The point of this subthread is that SSH keys are not as easy to do ad-hoc as passwords, especially when moving workstations.
        nottorp 2y ago
        > Right, much easier than a password! And so easy to backup! Extremely easy to recover from when the device you rely on to authenticate for everything gets lost or stolen too!
        unethical_ban 2y ago
        Exactly. If I can't use TOTP with backup codes, I'm not using MFA.
      - doublepg23 2y ago
        Does that work with macOS? I’m currently using 1Password as my ssh key agent.
        koito17 2y ago
        It indeed works on Mac OS. I have been using SoloKeys with ed25519-sk keys for about three years now. It should be sufficient to run ssh-keygen -t ed25519-sk while a FIDO2 key is connected. You may need to touch the key to confirm user presence. (At least SoloKeys do). If I recall correctly, the SSH binaries provided by Apple don't have built-in support for signing keys, but if you install OpenSSH from Nix, MacPorts, etc., then you don't have to worry about this. Another thing to be mindful of is that some programs have a very low timeout for waiting on SSH authentication, particularly git. SSH itself will wait quite a long time for user presence when using a signing key, whereas Git requires me to confirm presence within about 5 seconds or else operations fail with a timeout.
    - nerdbert 2y ago
      Why would you ever do that? How do you know it is not compromised? Carry your phone (many people already do this on a daily or near-daily basis in 2024) and use that in an emergency.
  - Rucadi 2y ago
    It's just an usually bigger password.
- deleted 2y ago
  [deleted]
- deleted 2y ago
  [deleted]
securam 2y ago
Some might argue SSH certificates are even better: https://smallstep.com/blog/use-ssh-certificates/ https://smallstep.com/blog/use-ssh-certificates/
- mianosm 2y ago
  There's a high bar to set for most organizations. Leveraging certificates is excellent if the supporting and engineering actors are all in accordance with how to manage and train the users and workforce how to use them (think root authorities, and revoking issued certificates from an authority). I've seen a few attempts to leverage certificates, or GPG; and keys nearly always are an 'easier' process with less burden to teach (which smart(er) people at times hate to do).
  - wkat4242 2y ago
    You can store your regular keys in gpg, it's a nice middle ground especially if you store them on a yubikey with openpgp. Of course OpenSSH also supports fido2 now but it's pretty new and many embedded servers don't support it. So I'm ignoring it for now. I need an openpgp setup for my password manager anyway.
    - KAMSPioneer 2y ago
      I use both PKCS#11 and OpenPGP SSH keys and in my opinion, PKCS#11 is a better user experience if you don't also require PGP functionality. Especially if you're supporting MaxOS clients as you can just use Secretive[0]. As you say, FIDO is even better but comes with limitations on both client and server, which makes life tough. [0] https://github.com/maxgoedjen/secretive https://github.com/maxgoedjen/secretive
      - wkat4242 2y ago
        Oh yeah I don't really use macOS anymore. And I do really need PGP functionality for my password manager. I used pkcs11 before with openct and opensc (on OpenHSM PIV cards) and the problem I had with it was that I always needed to runtime-link a library to the SSH binary to make it work which was often causing problems on different platforms. The nice thing about using PGP/GPG is that it can simulate an SSH agent so none of this is necessary, it will just communicate with the agent over a local socket.
GordonS 2y ago
Another good option is making SSH only accessible over Tailscale or a VPN.
- nativeit 2y ago
  This, with key pairs, is the best blend of security and convenience. I use ZeroTier and UFW on the server and it’s really very simple and extremely reliable. On the very rare occasion that ZeroTier encounters a problem, or my login fails, I still have IPMI access through Proxmox/VMWare and/or my server provider.
- Someone1234 2y ago
  The two aren't exclusive of one another. We've also witnessed situations, with major companies, wherein an SSH "leaks" outside the VPN due to network misconfiguration or misconfiguring interfaces on the server. As I said above, keys are actually more convenient than passwords. Only reason people still use passwords is because they believe keys are difficult to use or manage.
- vaylian 2y ago
  How do you protect the access to the VPN/Tailscale? I suppose you are not using a password?
  - GordonS 2y ago
    SSO and MFA, with a Microsoft account.
    - vaylian 2y ago
      That's an easy solution. But there is a lot of hidden complexity and it also makes you reliant on third parties https://www.microsoft.com/en-us/security/blog/2024/01/25/midnight-blizzard-guidance-for-responders-on-nation-state-attack/ https://www.microsoft.com/en-us/security/blog/2024/01/25/mid...
      - GordonS 2y ago
_JamesA_ 2y ago
The number of expect scripts I find in production that are used to automate ssh password authentication is ridiculous.
TacticalCoder 2y ago
> ... using keys is actually more convenient and significantly more secure. And for those for whom it's an option, using U2F keys (like Yubikeys) is now easily doable with SSH. So unless the attacker can hack the HSM inside your Yubikey, he's simply not getting your private SSH keys.
im3w1l 2y ago
I resent that every application needs its own special snowflake auth method. One uses a certain 2fa app. Another uses another 2fa app. Another uses emailed code. Another uses text code. Another uses special ssh keys. Another opens a prompt in the browser where I have to confirm. Another uses special scoped tokens. Yes there are good reasons. But it is quite a hassle to manage too.
KennyBlanken 2y ago
> I would like to remind everyone that an internet facing SSH with a password is very unwise. Bullshit. You can have a terrible password and your system will still be nearly impossible to get into. Also, these attackers are usually looking for already exploited systems that have backdoor account/password combos, unless they are specifically attacking your organization. Repeat after me: dictionary attack concerns have nothing to do with remote access authentication concerns. Let's say my password is two common-use English words (100k-200k.) That's ten billion possibilities. Assume you hit on my password half-way through. That would be fifteen years of continuous, 24x7x365 testing at 10 password attempts per second....and then there's the small matter of you not knowing what my username is, or even whether you've got the right username or not, unless the ssh server has a timing-based detection attack. The only argument for putting this functionality in the daemon itself is that by locating it in the daemon, it can offer advanced application-layer capabilities, such as failing auth attempts no matter what after the limit is tripped so that brute-forcing becomes more pointless - unless you get it right within the first few attempts, you could hit the right password and never know it. If they intend to implement features like that in the future, great - but if it's just going to do what fail2ban does, then...just run fail2ban. Fail2ban has a higher overview of auth on the system, is completely disconnected from the ssh daemon in terms of monitoring and blocking, and the blocking it does happens at the kernel level in the networking stack instead of in userspace with much more overhead and in a proprietary system specific to SSH. As a sysadmin, this is 'yet another place you have to look' to see why something isn't working.
- palata 2y ago
  > You can have a terrible password and your system will still be nearly impossible to get into. Ok, let's try an example of a terrible password for the user "root": "password". Is that nearly impossible to get into? Or does that not qualify as a "terrible password" per your definition?
joelthelion 2y ago
> internet facing SSH with a password is very unwise If your password is strong, it's not.
- CGamesPlay 2y ago
  Don't forget to use a different strong password on each server! https://security.stackexchange.com/a/152132 https://security.stackexchange.com/a/152132
- oofabz 2y ago
  A strong username also helps! Most SSH brute force attempts are for root, admin, or ubnt.
- sneak 2y ago
  Nope, still unwise. Easy to steal, easy to clone, hard to script. Keys stored in hardware is simple and easy on most platforms these days. Yubikeys or Mac SEP is ideal.
  - joelthelion 2y ago
    It depends on your use case. I have a personal server only I use use. In this use case, being able to access it from anywhere without any device trumps other considerations. The password is ideal. In a corporate setting, things are of course different.
    - sneak 2y ago
      My use case is the same as yours. Malware can steal your credentials, it cannot steal mine. I also don't need fail2ban or to configure any of these new OpenSSH features. Users added to the server can't get compromised due to use of weak passwords. Passwords are obsolete in 2024, and using them is very nearly universally bad.
      - joelthelion 2y ago
        > I also don't need fail2ban or to configure any of these new OpenSSH features Me neither. If your password has sufficient entropy, you don't need any of this. > Malware can steal your credentials, it cannot steal mine The only solution around this is a hardware key or MFA. I find the convenience of not needing anything with me to be superior to the low risk of malware. I understand your opinion may differ here.

timw4mail 2y ago

Any time you access an SSH connection from a different computer, you basically need the password.

LtWorf 2y ago
If it's in the cloud, you pass the public key when creating the vm. If it's a real machine, ask the data center person to do it.
krisoft 2y ago
This is not true. SSH keys are a viable alternative.
- sseagull 2y ago
  If I can be charitable, I think they mean a different computer than one you usually use (that doesn’t have the SSH key already in authorized_keys). Spouses computer, etc.
  - traceroute66 2y ago
    > If I can be charitable, I think they mean a different computer than one you usually use If I can be charitable .... What the hell are you doing storing your SSH keys on-disk anyway ? :) Put your keys on a Yubikey, take your keys with you.
    - unethical_ban 2y ago
      Right, much easier than a password! And so easy to backup! I'm not arguing it isn't more secure. The point of this subthread is that SSH keys are not as easy to do ad-hoc as passwords, especially when moving workstations.
      - nottorp 2y ago
        > Right, much easier than a password! And so easy to backup! Extremely easy to recover from when the device you rely on to authenticate for everything gets lost or stolen too!
        unethical_ban 2y ago
        Exactly. If I can't use TOTP with backup codes, I'm not using MFA.
    - doublepg23 2y ago
      Does that work with macOS? I’m currently using 1Password as my ssh key agent.
      - koito17 2y ago
        It indeed works on Mac OS. I have been using SoloKeys with ed25519-sk keys for about three years now. It should be sufficient to run ssh-keygen -t ed25519-sk while a FIDO2 key is connected. You may need to touch the key to confirm user presence. (At least SoloKeys do). If I recall correctly, the SSH binaries provided by Apple don't have built-in support for signing keys, but if you install OpenSSH from Nix, MacPorts, etc., then you don't have to worry about this. Another thing to be mindful of is that some programs have a very low timeout for waiting on SSH authentication, particularly git. SSH itself will wait quite a long time for user presence when using a signing key, whereas Git requires me to confirm presence within about 5 seconds or else operations fail with a timeout.
  - nerdbert 2y ago
    Why would you ever do that? How do you know it is not compromised? Carry your phone (many people already do this on a daily or near-daily basis in 2024) and use that in an emergency.
- Rucadi 2y ago
  It's just an usually bigger password.
deleted 2y ago
[deleted]
deleted 2y ago
[deleted]

securam 2y ago

Some might argue SSH certificates are even better: https://smallstep.com/blog/use-ssh-certificates/ https://smallstep.com/blog/use-ssh-certificates/

mianosm 2y ago
There's a high bar to set for most organizations. Leveraging certificates is excellent if the supporting and engineering actors are all in accordance with how to manage and train the users and workforce how to use them (think root authorities, and revoking issued certificates from an authority). I've seen a few attempts to leverage certificates, or GPG; and keys nearly always are an 'easier' process with less burden to teach (which smart(er) people at times hate to do).
- wkat4242 2y ago
  You can store your regular keys in gpg, it's a nice middle ground especially if you store them on a yubikey with openpgp. Of course OpenSSH also supports fido2 now but it's pretty new and many embedded servers don't support it. So I'm ignoring it for now. I need an openpgp setup for my password manager anyway.
  - KAMSPioneer 2y ago
    I use both PKCS#11 and OpenPGP SSH keys and in my opinion, PKCS#11 is a better user experience if you don't also require PGP functionality. Especially if you're supporting MaxOS clients as you can just use Secretive[0]. As you say, FIDO is even better but comes with limitations on both client and server, which makes life tough. [0] https://github.com/maxgoedjen/secretive https://github.com/maxgoedjen/secretive
    - wkat4242 2y ago
      Oh yeah I don't really use macOS anymore. And I do really need PGP functionality for my password manager. I used pkcs11 before with openct and opensc (on OpenHSM PIV cards) and the problem I had with it was that I always needed to runtime-link a library to the SSH binary to make it work which was often causing problems on different platforms. The nice thing about using PGP/GPG is that it can simulate an SSH agent so none of this is necessary, it will just communicate with the agent over a local socket.

GordonS 2y ago

Another good option is making SSH only accessible over Tailscale or a VPN.

nativeit 2y ago
This, with key pairs, is the best blend of security and convenience. I use ZeroTier and UFW on the server and it’s really very simple and extremely reliable. On the very rare occasion that ZeroTier encounters a problem, or my login fails, I still have IPMI access through Proxmox/VMWare and/or my server provider.
Someone1234 2y ago
The two aren't exclusive of one another. We've also witnessed situations, with major companies, wherein an SSH "leaks" outside the VPN due to network misconfiguration or misconfiguring interfaces on the server. As I said above, keys are actually more convenient than passwords. Only reason people still use passwords is because they believe keys are difficult to use or manage.
vaylian 2y ago
How do you protect the access to the VPN/Tailscale? I suppose you are not using a password?
- GordonS 2y ago
  SSO and MFA, with a Microsoft account.
  - vaylian 2y ago
    That's an easy solution. But there is a lot of hidden complexity and it also makes you reliant on third parties https://www.microsoft.com/en-us/security/blog/2024/01/25/midnight-blizzard-guidance-for-responders-on-nation-state-attack/ https://www.microsoft.com/en-us/security/blog/2024/01/25/mid...
    - GordonS 2y ago

_JamesA_ 2y ago

The number of expect scripts I find in production that are used to automate ssh password authentication is ridiculous.

TacticalCoder 2y ago

> ... using keys is actually more convenient and significantly more secure. And for those for whom it's an option, using U2F keys (like Yubikeys) is now easily doable with SSH. So unless the attacker can hack the HSM inside your Yubikey, he's simply not getting your private SSH keys.

im3w1l 2y ago

I resent that every application needs its own special snowflake auth method. One uses a certain 2fa app. Another uses another 2fa app. Another uses emailed code. Another uses text code. Another uses special ssh keys. Another opens a prompt in the browser where I have to confirm. Another uses special scoped tokens. Yes there are good reasons. But it is quite a hassle to manage too.

KennyBlanken 2y ago

> I would like to remind everyone that an internet facing SSH with a password is very unwise. Bullshit. You can have a terrible password and your system will still be nearly impossible to get into. Also, these attackers are usually looking for already exploited systems that have backdoor account/password combos, unless they are specifically attacking your organization. Repeat after me: dictionary attack concerns have nothing to do with remote access authentication concerns. Let's say my password is two common-use English words (100k-200k.) That's ten billion possibilities. Assume you hit on my password half-way through. That would be fifteen years of continuous, 24x7x365 testing at 10 password attempts per second....and then there's the small matter of you not knowing what my username is, or even whether you've got the right username or not, unless the ssh server has a timing-based detection attack. The only argument for putting this functionality in the daemon itself is that by locating it in the daemon, it can offer advanced application-layer capabilities, such as failing auth attempts no matter what after the limit is tripped so that brute-forcing becomes more pointless - unless you get it right within the first few attempts, you could hit the right password and never know it. If they intend to implement features like that in the future, great - but if it's just going to do what fail2ban does, then...just run fail2ban. Fail2ban has a higher overview of auth on the system, is completely disconnected from the ssh daemon in terms of monitoring and blocking, and the blocking it does happens at the kernel level in the networking stack instead of in userspace with much more overhead and in a proprietary system specific to SSH. As a sysadmin, this is 'yet another place you have to look' to see why something isn't working.

palata 2y ago
> You can have a terrible password and your system will still be nearly impossible to get into. Ok, let's try an example of a terrible password for the user "root": "password". Is that nearly impossible to get into? Or does that not qualify as a "terrible password" per your definition?

joelthelion 2y ago

> internet facing SSH with a password is very unwise If your password is strong, it's not.

CGamesPlay 2y ago
Don't forget to use a different strong password on each server! https://security.stackexchange.com/a/152132 https://security.stackexchange.com/a/152132
oofabz 2y ago
A strong username also helps! Most SSH brute force attempts are for root, admin, or ubnt.
sneak 2y ago
Nope, still unwise. Easy to steal, easy to clone, hard to script. Keys stored in hardware is simple and easy on most platforms these days. Yubikeys or Mac SEP is ideal.
- joelthelion 2y ago
  It depends on your use case. I have a personal server only I use use. In this use case, being able to access it from anywhere without any device trumps other considerations. The password is ideal. In a corporate setting, things are of course different.
  - sneak 2y ago
    My use case is the same as yours. Malware can steal your credentials, it cannot steal mine. I also don't need fail2ban or to configure any of these new OpenSSH features. Users added to the server can't get compromised due to use of weak passwords. Passwords are obsolete in 2024, and using them is very nearly universally bad.
    - joelthelion 2y ago
      > I also don't need fail2ban or to configure any of these new OpenSSH features Me neither. If your password has sufficient entropy, you don't need any of this. > Malware can steal your credentials, it cannot steal mine The only solution around this is a hardware key or MFA. I find the convenience of not needing anything with me to be superior to the low risk of malware. I understand your opinion may differ here.