3 ms·
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,
by 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 agoAh, my bad. I got the impression that it was introduced in the commit on the 31st of July.
- exikyut 8y agoAll good!
- e12e 8y agoJust 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 agoA 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.