If you have a good story involving any kind of common sense violation when it comes to SSH fingerprints, would you please share it to motivate future colleagues to do better? Examples of common violations I see in practice: not checking the fingerprint upon first use, ignoring the "remote host identification has changed" warning, only checking a part of the fingerprint optically (instead of typing/pasting the fingerprint), etc.
Thanks!
> not checking the fingerprint upon first use,
I don't know a single engineer, including security engineers, who does this.
> ignoring the "remote host identification has changed" warning,
This has helped me operationally when I wrongfully log in to a different machine than the one I was expecting. It's definitely useful to understand what it means. I think it is low on the list of security problems.
If I were interviewing someone for a security/admin position I would expect some level of: Don't allow passwords for ssh period, only key pair authentication. Control key forwarding behavior. Implement 2fac. Log everything to another machine.
If I were forced to write an SSH lab, it would be to show what happens when your key forwarding behavior is poorly configured.
I think time would probably be better spent teaching about `auditd` and then running a lab where you run a script on a machine that someone has set up logging for, and then they have to tell you what it did.
If you really want something man in the middle then superfish is probably one of the best real world examples and probably not all that horrible to re-create.
https://en.wikipedia.org/wiki/Superfish
Arp cache poisoning was an absolute classic back in the day.
I haven't really worked on security in a long time, so I'm probably out of date.
Practical examples of common sense could be pipelines in gitlab where a ssh connection is started. In such situations, the easiest solution is to just ignore the fingerprint but of course if the gitlab server network environment is compromised, a MITM attack is very possible.