Hacker News new | past | comments | ask | show | jobs | submit login

There are also some significant vulnerabilities [1] in SSH by design / by default that must be disabled if used everywhere.

[1] https://news.ycombinator.com/item?id=11052745




It is very easy to write a virus that is not detected by any anti-virus. I don't see how dropping an SSH key on some machine is worse than dropping a remote shell on it.

It's not like SSH keys are stealthy or something - any sysadmin worth his salt will occasionally look at his authorized_keys list.


I use an SSH CA and it solves this problem.

It's simple to setup. You first create a CA, and then you sign the servers public key and the client's public key, and you take the resulting certs (alongside the CA's pubkey) and move them over to the machines. And I think it's important to note that you can do this process on any machine-- perhaps an air-gapped $30 Raspberry Pi, or if you're less paranoid you can do it on your laptop, but the point is that you can generate keys in bulk, offline, and move them over to dozens of machines in one fell swoop.

You still need to maintain an authorized_keys file in your homedir with your client public key, which means if someone was able to get the CA key they still wouldn't be able to get into the server without first getting the key that corresponds to the entry in your authorized_keys file. And likewise, if someone was able to get access to your user key, they would be able to login with it but wouldn't be able to add a backdoor key to the authorized_keys file unless they also had the CA key to sign it with, because both the client and server check the other's certificate against the CA pubkey.

Of course, if you see ssh keys as a panacea and subsequently use passwordless sudo or a weak enough password, they have root and can just edit your sshd_config and this was all for naught. But it does solve the problem of an unchecked authorized_keys file.


That helps, but you would still need to disable ssh multiplexing on all of your servers.


Why?


Any process running as you can piggy-back on those default-enabled channels without authentication or logging on the destination servers.


I wish everyone checked their authorized_keys file like you do. Sadly, this is rarely the case across the board, based on my experience. People are lazy. There are good aspects of being lazy, but this is one of the sub-optimal cases.

In summary, this methodology would not likely be detected even in places where folks and admins are quite vigilant. The behavior and usage is expected. If I were unethical, I could gain access to thousands of companies by simply emailing a link to github and saying, "This script is giving me errors, what am I doing wrong?" Using the default settings in ssh an sudo, I can access all of their systems with no syslog entries and gain root to anything they have sudo on.


> any sysadmin worth his salt will have automated the population of his authorized_keys file and alert on any unauthorized changes.

FTFY


That appears to be surprisingly uncommon. By that I mean maintaining the authorized keys file at all.




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: