5 ms·

> using decent passwords For anyone else reading this, generally speaking one shouldn't use passwords for SSH in 2024. Use public key auth instead. > Why is i

by sevg 2y ago

> using decent passwords 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.

Demiurge 2y ago
Generally speaking, you’re right, but I have servers I want to be able to access from anywhere, because I support some app running on them. Until 1password agent setup, having keys only and password disabled was too difficult, and yet, also unnecessary. 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.
- sevg 2y ago
  Ah yes, the "I've never been hacked so I must be secure" argument ;) 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.
  - Demiurge 2y ago
    I’m not trying to convince anyone, I’m trying to understand what drives sone security focused people to make things more complicated and harder without practical justification. So, are you NSA? How many servers have you lost to the password attack vector?
    - sevg 2y ago
      > I'm trying to understand 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 :)
      - Demiurge 2y ago
        Yeah, it might read like that, but it also is how I feel. If I was running a crypto farm, or if I was doing security research, I would have different levels of concerns. 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.
      - Bluestein 2y ago
        For the record, and whatever worth - it is the (it seems, serious) conviction of here folks (and I concur) that the NSA is at least a reader of these threads.- PS. So, hi!
        Bluestein 2y ago
        PS. I'll take the negvotes as confirmation I guess ...
    - michaelt 2y ago
      Every large- or medium-sized multi-user server disables passwords for SSH login, because they're worried about things like password stuffing - and because they know password reuse is unavoidable when you've got even a small fleet of servers. 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.
  - nine_k 2y ago
    OK, let's assume SSH is configured to accept one 30-character random password as an escape hatch. All normal auth is done using pre-shared keys. What are the risks, from your point of view? From my POV, the principal risk is opsec mishaps, which may lead to leaking a public key or a password alike.
    - KAMSPioneer 2y ago
      One difference is that MitM attacks can capture your password, thereby giving persistent access to at least that system (more, if you reuse passwords). 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).
      - kazinator 2y ago
        SSH is always using public keys even when you use password authentication. Your SSH client knows the host the key. If you're not connecting to the right host, you are informed.
        KAMSPioneer 2y ago
        I know that, but "public keys" is long enough on mobile without typing "public user-authentication keys." 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).
        kazinator 2y ago
- kalaksi 2y ago
  Some of them may then be vulnerable. This is the recent SSH vulnerability: https://arstechnica.com/security/2024/07/regresshion-vulnerability-in-openssh-gives-attackers-root-on-linux/ https://arstechnica.com/security/2024/07/regresshion-vulnera...

by sevg 2y ago

Demiurge 2y ago

Generally speaking, you’re right, but I have servers I want to be able to access from anywhere, because I support some app running on them. Until 1password agent setup, having keys only and password disabled was too difficult, and yet, also unnecessary. 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.

sevg 2y ago
Ah yes, the "I've never been hacked so I must be secure" argument ;) 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.
- Demiurge 2y ago
  I’m not trying to convince anyone, I’m trying to understand what drives sone security focused people to make things more complicated and harder without practical justification. So, are you NSA? How many servers have you lost to the password attack vector?
  - sevg 2y ago
    > I'm trying to understand 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 :)
    - Demiurge 2y ago
      Yeah, it might read like that, but it also is how I feel. If I was running a crypto farm, or if I was doing security research, I would have different levels of concerns. 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.
    - Bluestein 2y ago
      For the record, and whatever worth - it is the (it seems, serious) conviction of here folks (and I concur) that the NSA is at least a reader of these threads.- PS. So, hi!
      - Bluestein 2y ago
        PS. I'll take the negvotes as confirmation I guess ...
  - michaelt 2y ago
    Every large- or medium-sized multi-user server disables passwords for SSH login, because they're worried about things like password stuffing - and because they know password reuse is unavoidable when you've got even a small fleet of servers. 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.
- nine_k 2y ago
  OK, let's assume SSH is configured to accept one 30-character random password as an escape hatch. All normal auth is done using pre-shared keys. What are the risks, from your point of view? From my POV, the principal risk is opsec mishaps, which may lead to leaking a public key or a password alike.
  - KAMSPioneer 2y ago
    One difference is that MitM attacks can capture your password, thereby giving persistent access to at least that system (more, if you reuse passwords). 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).
    - kazinator 2y ago
      SSH is always using public keys even when you use password authentication. Your SSH client knows the host the key. If you're not connecting to the right host, you are informed.
      - KAMSPioneer 2y ago
        I know that, but "public keys" is long enough on mobile without typing "public user-authentication keys." 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).
        kazinator 2y ago
kalaksi 2y ago
Some of them may then be vulnerable. This is the recent SSH vulnerability: https://arstechnica.com/security/2024/07/regresshion-vulnerability-in-openssh-gives-attackers-root-on-linux/ https://arstechnica.com/security/2024/07/regresshion-vulnera...