Hello all I have a somewhat annoying problem with OpenSSH. Now, granted, it's certainly not a bug. I'm just wondering what the best course of action is. At work, we have multiple customers with machines named "fw0", "fs0", etc. This is all good, since it conforms to a standard naming scheme, so it's easier to administrate. However, when we go to our customers' sites, we often issue commands like "ssh user at fw0", which of course gives out endless warnings about MITM attacks, and essentially makes host keys worthless on the internal customer networks. It seems somewhat wrong to me. Isn't there some way to make OpenSSH save the host key using the FQDN instead of just the local part? That would solve this problem. Is there some other commonly accepted way of dealing with this that doesn't involve making all our host names unique? Bonus question: We have 2 storage servers (let's call them storage0 and storage1), and between them they run a floating IP address with a heartbeat-monitored NFS daemon (let's call that nfs0). Now, obviously the host key changes whenever there's been a failover, and so again we get this same kind of problem. What to do in this case? Any ideas? Thank you all for your time. -- Med venlig hilsen Christian Iversen
El Mar 31 Mar 2009, Christian Iversen escribi?:> Isn't there some way to make OpenSSH save > the host key using the FQDN instead of just the local part? That would > solve this problem.Permit that is permit MitM when there is a DNS spoofing situation. luciano
Christian Iversen wrote:> Hello all > > I have a somewhat annoying problem with OpenSSH. Now, granted, it's > certainly not a bug. I'm just wondering what the best course of action is. > > At work, we have multiple customers with machines named "fw0", "fs0", > etc. This is all good, since it conforms to a standard naming scheme, so > it's easier to administrate. > > However, when we go to our customers' sites, we often issue commands > like "ssh user at fw0", which of course gives out endless warnings about > MITM attacks, and essentially makes host keys worthless on the internal > customer networks. > > It seems somewhat wrong to me. Isn't there some way to make OpenSSH save > the host key using the FQDN instead of just the local part? That would > solve this problem. Is there some other commonly accepted way of dealing > with this that doesn't involve making all our host names unique?FQDNs _are_ unique host names. Or at least they are supposed to be. So, it would seem that simply saying ssh user at FQDN is going to be the way to go. It has been my experience that if one uses the FQDN that is what will go into the file.> Bonus question: We have 2 storage servers (let's call them storage0 and > storage1), and between them they run a floating IP address with a > heartbeat-monitored NFS daemon (let's call that nfs0). > > Now, obviously the host key changes whenever there's been a failover, > and so again we get this same kind of problem. What to do in this case? > Any ideas?Always ssh to the unique rather than shared name? rick jones
Rick Jones wrote:> Christian Iversen wrote: >> Hello all >> >> I have a somewhat annoying problem with OpenSSH. Now, granted, it's >> certainly not a bug. I'm just wondering what the best course of action >> is. >> >> At work, we have multiple customers with machines named "fw0", "fs0", >> etc. This is all good, since it conforms to a standard naming scheme, >> so it's easier to administrate. >> >> However, when we go to our customers' sites, we often issue commands >> like "ssh user at fw0", which of course gives out endless warnings about >> MITM attacks, and essentially makes host keys worthless on the >> internal customer networks. >> >> It seems somewhat wrong to me. Isn't there some way to make OpenSSH >> save the host key using the FQDN instead of just the local part? That >> would solve this problem. Is there some other commonly accepted way of >> dealing with this that doesn't involve making all our host names unique? > > FQDNs _are_ unique host names. Or at least they are supposed to be.Oh, of course they are. But as I said, the problem is that we often use only the local part. Our FQDNs are always globally unique, otherwise a ton of things would break.> So, it would seem that simply saying ssh user at FQDN is going to be the > way to go. It has been my experience that if one uses the FQDN that is > what will go into the file.Mine too. I might just set up some zsh completion and perhaps some aliases to work around the extra typing involved.>> Bonus question: We have 2 storage servers (let's call them storage0 >> and storage1), and between them they run a floating IP address with a >> heartbeat-monitored NFS daemon (let's call that nfs0). >> >> Now, obviously the host key changes whenever there's been a failover, >> and so again we get this same kind of problem. What to do in this >> case? Any ideas? > > Always ssh to the unique rather than shared name?Well, since they mount a shared disk which is only available on the active nfs host, we need to actually ssh to the nfs server in maintenance and backup scripts. Any ideas? -- Med venlig hilsen Christian Iversen
Hi, Christian Iversen wrote:> However, when we go to our customers' sites, we often issue commands > like "ssh user at fw0", which of course gives out endless warnings about > MITM attacks, and essentially makes host keys worthless on the internal > customer networks. > > It seems somewhat wrong to me. Isn't there some way to make OpenSSH save > the host key using the FQDN instead of just the local part?What about a trick like : $ tail -2 .ssh/config Host fw0 Hostname fw0.client3.toto.org#CLIENTDOMAIN $ switch-ssh client2.org $ tail -2 .ssh/config Host fw0 Hostname fw0.client2.org#CLIENTDOMAIN "switch-ssh" can be a script or even an alias in your shell, that does : sed -i \ "s/^Hostname *\([^.]*\).*#CLIENTDOMAIN/Hostname \1.$1#CLIENTDOMAIN/" \ .ssh/config Hope this helps, Flavien.