Thanks for replying Nico. I do have stable hosts, one in the cloud and one local. My options are to rely on known_hosts or disable host key checking ( StrictHostKeyChecking no), which opens ssh to man in the middle attacks. I have no idea if they are common, but I'd prefer to keep people from being able to do it. I understand your points about the location of known_hosts. I was using what works for the servers I'm on and realize that it may not be as portable as it should be, but I do have control over the OSes on these machines so I should be relatively safe from change. I am using RSA keys to enable the machines to ssh to each other without passwords from specific accounts, so perhaps the host keys aren't as important? I wonder what other's think about "StrictHostKeyChecking no". Everything I've read online indicates that's a dangerous thing to do. Brian On 01/28/17 15:36, Nico Kadel-Garcia wrote: > On Sat, Jan 28, 2017 at 2:15 PM, Brian McKee <btmckee9@xxxxxxxxx> wrote: >> Hello & thanks for reading. >> >> I'm having a problem configuring known_hosts from scripts so an accept >> key yes/no prompt doesn't appear. > I'd suggest that you *stop using it*. Unless you have a well-defined > set of stable hosts, whose SSH host keys are not likely to change, > there hasn't been a point to relying on known_hosts in *years*. > There's no good signature structure for it to verify the authenticity > of published host keys, and too many environments simply re-assign IP > addresses for changing back end hosts, and or alternatively the hosts > are rebuilt with alternative SSH hostkeys with no announcement to > users. Maintaining and relying on a known_hosts has traditionally > broken more automated scripting and forced far more dangerous hacks > and workaounds than it has benefited security. > > The relevant options to disable the use of known_hosts are well > explained in an article at > http://linuxcommando.blogspot.com/2008/10/how-to-disable-ssh-host-key-checking.html, > and are: > > * StrictHostKeyChecking no # this gets the questions to stop being > asked for new connections > * UserKnownHostsFile=/dev/null # This prevents the client from > retaining old, mismatched known_hosts entries that will screw up new > connections > > Additionally, it can be specified in your script or your .ssh/config > on a host-by-host basis, so that if you really *want*, you can use it. > >> I'm using this command to detect if the server is known and add it to >> known_hosts: >> >> if ! ssh-keygen -F ${IP_ADDR} -f ~/.ssh/known_hosts > /dev/null 2>&1; then \ >> ssh-keyscan -p ${PORT} ${IP_ADDR} >> ~/.ssh/known_hosts; fi > The "~/", or "$HOME/", is not set for various shell environments. This > is especially true for cron jobs run from /etc/cron.d, for which $HOME > is always set to "/" by default > >> This works fine for the machine that has only one port (22) in >> sshd_config, but for a machine that is being accessed on a >> non-standard port (they happen to be different versions of Ubuntu as >> well, I don't think that's the difference), the code has to be changed >> to this: >> >> if ! ssh-keygen -F [${IP_ADDR}]:${PORT} -f ~/.ssh/known_hosts > /dev/null 2>&1; >> then ssh-keyscan -p ${PORT} ${IP_ADDR} >> ~/.ssh/known_hosts; fi >> >> And, as suggested for security, if I add -H to the ssh-keyscan, then >> the IP addresses are hashed and the if statement fails every time, no >> matter what so the keys are added over and over again. >> >> I figure I'm doing something wrong. Is there a generic way to cause >> ssh to generate keys for known_hosts consistently across multiple >> configurations with a hash? > Probably. But it's typically not worth the effort, because if the same > IP address is re-assigned to a different host with a different key, > your saved known_hosts file is going to *break*. And in many > environments where hosts re built from images without host keys, and > create keys at boot time, and the new hosts re being cycled quickly in > a limited address space, well, the results are not going to be pretty. > There is no automatic setup in your script to *clear* mismatched > hostkeys, and frankly, they're a common problem. They're even a > problem when visiting new sites were both site happen to use the same > non-routable address space, such as 192.168.1.0/24. Been there, done > that, had to explain to people churning through address spaces for > VM's and CICD that this was a problem. _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
