5 ms·

I think he’s saying: a) Why are you using bleeding edge software in production, and especially so unreleased versions of OpenSSH? b) Why are your SSH servers

I think he’s saying: a) Why are you using bleeding edge software in production, and especially so unreleased versions of OpenSSH? b) Why are your SSH servers exposed to public traffic? c) User enumeration is useful for finding accounts with weak passwords. Why do you have personal accounts on prod servers? Why do you have _any_ accounts not using public key authentication at all?

exikyut 8y ago
FWIW, regarding a), > We believe that this issue warrants a CVE; it affects all operating systems, all OpenSSH versions (we went back as far as OpenSSH 2.3.0, released in November 2000), and is easier to exploit than previous OpenSSH username enumerations... As for b) and c), I 100% agree. In fact: if you're using KVM-based virtualization, and you have VNC or serial access to your node (GCP gives you serial access, via web UI or an SSH-based proxy), you could completely _disable_ standard network-based login. (Writing an admin tool that connects to the serial console, gets a usable shell, and enables your sshd for when you need it, is an exercise for the inspired sysadmin. :P) But this fun little trick is going to break a lot of stuff.
- oxymoron 8y ago
  Ah, my bad. I got the impression that it was introduced in the commit on the 31st of July.
  - exikyut 8y ago
    All good!
- e12e 8y ago
  Just remember (at least for non ephemeral systems): always have two ways in. That way if one path is down (fiber cable cut, serial disconnected, cloud admin panel down for maintenance, ssh authorized_keys file has wrong permissions, ssh/ssl cert(s) expired... ) - you can still get in via the other path.
  - exikyut 8y ago
    A very good idea. Perhaps a valuable resource would have a disposable proxy in front of it; then one way in (or even no ways in!) might be viable.
tjoff 8y ago
b) If not SSH what else would one use? c) Not only production servers utilize internet.
- oxymoron 8y ago
  b) use ssh, but control access with a firewall or vpn. c) fair enough, although you should probably be using keypairs and a vpn for test and dev envs too.
  - xorcist 8y ago
    I see that recommendation a lot, but I'd expect most VPN products in use to be _less_ secure than a standard OpenSSH. It's a comparably less complex protocol and codebase than IPsec, for example, and pretty well audited by now. It's not as if VPN products hasn't been open to this type of attacks before (I'm looking at you, Cisco).

exikyut 8y ago

FWIW, regarding a), > We believe that this issue warrants a CVE; it affects all operating systems, all OpenSSH versions (we went back as far as OpenSSH 2.3.0, released in November 2000), and is easier to exploit than previous OpenSSH username enumerations... As for b) and c), I 100% agree. In fact: if you're using KVM-based virtualization, and you have VNC or serial access to your node (GCP gives you serial access, via web UI or an SSH-based proxy), you could completely _disable_ standard network-based login. (Writing an admin tool that connects to the serial console, gets a usable shell, and enables your sshd for when you need it, is an exercise for the inspired sysadmin. :P) But this fun little trick is going to break a lot of stuff.

oxymoron 8y ago
Ah, my bad. I got the impression that it was introduced in the commit on the 31st of July.
- exikyut 8y ago
  All good!
e12e 8y ago
Just remember (at least for non ephemeral systems): always have two ways in. That way if one path is down (fiber cable cut, serial disconnected, cloud admin panel down for maintenance, ssh authorized_keys file has wrong permissions, ssh/ssl cert(s) expired... ) - you can still get in via the other path.
- exikyut 8y ago
  A very good idea. Perhaps a valuable resource would have a disposable proxy in front of it; then one way in (or even no ways in!) might be viable.

tjoff 8y ago

b) If not SSH what else would one use? c) Not only production servers utilize internet.

oxymoron 8y ago
b) use ssh, but control access with a firewall or vpn. c) fair enough, although you should probably be using keypairs and a vpn for test and dev envs too.
- xorcist 8y ago
  I see that recommendation a lot, but I'd expect most VPN products in use to be _less_ secure than a standard OpenSSH. It's a comparably less complex protocol and codebase than IPsec, for example, and pretty well audited by now. It's not as if VPN products hasn't been open to this type of attacks before (I'm looking at you, Cisco).