On Mon, Jun 28, 2010 at 09:32:06PM -0400, Dan Mahoney, System Admin wrote: > On Mon, 28 Jun 2010, Greg Wooledge wrote: > >It doesn't make sense. The point of a hash (at least in this context) > >is that you cannot reverse it to get the original data back. > The point of the hash is that if, someone has compromised my account (via > brute force, keyboard surfing, evil sysadmin, whatever, and whatever else > it contains (trusted keys, kerberos credentials, etc), they could look in > my known_hosts file and see what other hosts they could log into. You're discussing what you desire as an outcome. That's great. It's a perfectly reasonable thing to want. The problem is that it's not possible. > # Server in guam is on overloaded DSL link > Host slowpoke > HostName slowpoke.secure.server.ad.company.com > ConnectTimeout 600 > User admin Hashes are one-way. You can turn data into a hash, but you can't turn a hash back into data. > But compare this with > > HostnameHash |1|JYh/HiqdBkaEKeg0KrS9cHncJRI=|Qc2hMsrOMpReJLyOxwmps3nnb0k= > ConnectTimeout 600 > User admin There is no way to translate the hash into the string "slowpoke.secure.server.ad.company.com". If you had typed the string "slowpoke.secure.server.ad.company.com" on the command line, then the ssh client could hash it and compare that to what's in your options file. But if you only typed "slowpoke" on the command line, then the client can't even look up the canonical FQDN from that.
