I suppose even minimal extra security would've helped (no root user, only allow x login attempts in y time, changing the port for ssh), but I was still surprised someone got in so soon by simply guessing a 20+ string of gibberish (I still wonder if maybe something else happened).
All that said, I've had servers running for years without any successful hack, and in all those cases using ssh keys instead of password logins probably made all the difference.
The only alternative that I can think of is that one of the two other users' machines was compromised, but AFAIK I didn't give them root access. Plus, the logs show an extreme number of login attempts (tens of thousands of entries in auth.log) with an eventually successful root login.
Any other ideas of what might've been an alternative cause?
Maybe you’re right though.
EDIT: to be clear, I am pretty sure was the only person who used the root password to log in, and the single other user used a similarly long and random password with a different username. if I'd been compromised my problems would be quite a bit bigger. All I know is that right before the 'fatal' root login, there are 40.000+ lines of login attempts from ip's that originated from shady places (at least based on entering them in various GeoIP sites).
Just to be sure: PasswordAuthentication does not need to be enabled for the PoC to work, and username testing can also be used for software enumeration by testing for common/default non-SSH users, .g. "_tor", "debian-tor", etc. (I apologize for repeating here what I also stated in other comments in this thread, but this aspect should not be overlooked.)
If somebody hacked into my password manager and managed to steal the root user's password then they could do the same with my private key. Where is the difference?
Also, if somebody hacked into a non-root administrative account, they can just use sudo to elevate. What makes disabling root login more secure?
2. When using real password authentication, connecting to a compromised server results in a disclosure of your password. When using challenge-response authentication, it does not. Note that correctly-configured OpenSSH uses challenge-response even for password-based methods. Incorrectly configured SSH will send passwords over the wire.
What do you mean?
With real password when you type your password into the ssh password prompt it then sends that password to the server.
Challenge response is a method in which you usually encrypt or hash random server provided data. You send the hash. The server knows your password and can hash the data with it too. The hashes are compared not the password. In this method the password never leaves your machine. Replay attacks are prevented due to the server sending different data for you to hash on different login attempts.
http://www.securiteam.com/securitynews/5KP0O0A3PU.html
Does anyone know of recent work on passively attacking interactive ssh in order to guess what's being typed? I could see machine learning helping here, given the ability to observe enough sessions to form a training set...
Keys can be leaked but since it involves copying files and users aren’t penalized for using strong ones it’s much less common.
Point being - it needs to be managed like a key: it's inconvenient to type, hard to remember, should be stored encrypted at rest, preferably in an hsm.
Gnupg agent/ssh agent and the various key agents for desktops all do this, and generally support hsm as well.
There's also a small difference in the complexity of enumerating the keyspace of rsa/ed2259 vs trying random passwords. With key stretching I'm not sure if there's implicit differences in rate of attempting login.
As for no direct root login via ssh - I think it depends a bit on the server. On a shared system login via regular user +sudo leaves an easier audit trail (who ran "sudo apt-get dist-upgrade" on Friday evening and took the weekend off without checking that production systems didn't crash... Was it "root" or "bob "?).
Then there's the nudge towards only doing what needs root as root (eg: curl/wget stuff as regular user, verify signatures, content - then run as root).
Is it more secure to locally dump and asymmetrically encrypt backups on disk as root - locally, and have a dedicated backup-user that gets the archives? Probably.
In general ssh keys (and certs more so) makes it feasible to split up access and authorization, revoke access etc without relying on something complex like ldap/kerberos for user management.
> Also, if somebody hacked into a non-root administrative account, they can just use sudo to elevate.
If they only have your ssh key, they'd typically need your password to elevate. Or you might require a shared root password - or set a password on wheel and require newgrp wheel before sudo. Not sure if the latter with disabled root account has much benefit, though.