I can imagine a scenario where a user that logs into a machine and tries to read a very sensitive file that they shouldn't have access to (should only be read by sshd and a specific automation user) trips an alarm via hooks in SELinux or something similar that causes the host to shut down immediately and security admins notified. It should just outright deny it I'd argue instead of shutting down, but I've seen really weird security policies before that make little practical sense and wouldn't be too surprised if someone created an IDS enforcement policy similar to this.

> I can imagine a scenario where a user that logs into a machine and tries to read a very sensitive file...

That's several steps beyond connecting to port 22 and slurping up the host fingerprint. At that point, SSH has prompted for credentials, accepted them, and set up a shell or SFTP session for you.

Hell, if the system lets you log in using SSH and read files, that really sounds like the system has granted you permission to access those files. (I'm sure a lawyer could argue with me, but I think we're all aware of how (willfully?) ignorant members of the Judicial branch can be of the nuances of computer things.)

An interesting argument. With telnet it's easy to argue that it wasn't supposed to allow access, it was just a default and you should have known better. With ssh you have to go pretty far out of your way to allow someone to log in without having a key or password. Sounds like something that would imply authorization.

> With ssh you have to go pretty far out of your way to allow someone to log in without having a key or password.

Yeah. It's certainly not the default config. From what I can tell, you can either

* Activate PAM support and have a PAM module that just authorizes users, regardless of credentials.

* Enable PermitEmptyPasswords and have an account on the system that has no password.

So, I guess if you SSH to a machine that lets you log in with no password, or any username/password combo, you might want to consider that maybe your use of the machine is not necessarily authorized. :p

My hypothetical in the previous comment presumed that you presented a username/key or a username/password combo that you knew to the system and it granted you access... but I guess the situation can get a little more murky, if you're accessing a system managed by a pathologically lazy sysadmin. ;)

Eh, if you're in a position to know a legitimate account like that, you should already know whether you're authorized. In that case "it let me in so surely it was okay" is not a very strong argument.

Script kiddies run SSH brute forcers on every IP they can.

If all you do is grab a fingerprint, you will interact with the system less than the script kiddies.

So, if it was going to fall over, it would without you grabbing the fingerprint.

True unless the server is not on the public internet. In that case, pulling the plug if port 22 is accessed would be a reasonably defensible idea (you are being attacked for sure, and it's hard to attack a machine that is off) ...albeit paranoid in the extreme.

Okay well, a probably more realistic solution would be "peek at the host keys from the hypervisor" anyway. :)