Can I automatically add a new host to known_hosts?

Question

Here's my situation: I'm setting up a test harness that will, from a central client, launch a number of virtual machine instances and then execute commands on them via ssh. The virtual machines will have previously unused hostnames and IP addresses, so they won't be in the ~/.ssh/known_hosts file on the central client.

The problem I'm having is that the first ssh command run against a new virtual instance always comes up with an interactive prompt:

The authenticity of host '[hostname] ([IP address])' can't be established.
RSA key fingerprint is [key fingerprint].
Are you sure you want to continue connecting (yes/no)?

Is there a way that I can bypass this and get the new host to be already known to the client machine, maybe by using a public key that's already baked into the virtual machine image ? I'd really like to avoid having to use Expect or whatever to answer the interactive prompt if I can.

Solution 1

Set the StrictHostKeyChecking option to no, either in the config file or via -o :

ssh -o StrictHostKeyChecking=no [email protected]

Solution 2

IMO, the best way to do this is the following:

ssh-keygen -R [hostname]
ssh-keygen -R [ip_address]
ssh-keygen -R [hostname],[ip_address]
ssh-keyscan -H [hostname],[ip_address] >> ~/.ssh/known_hosts
ssh-keyscan -H [ip_address] >> ~/.ssh/known_hosts
ssh-keyscan -H [hostname] >> ~/.ssh/known_hosts

That will make sure there are no duplicate entries, that you are covered for both the hostname and IP address, and will also hash the output, an extra security measure.

Solution 3

For the lazy ones:

ssh-keyscan -H <host> >> ~/.ssh/known_hosts

-H hashes the hostname / IP address

Solution 4

As mentioned, using key-scan would be the right & unobtrusive way to do it.

ssh-keyscan -t rsa,dsa HOST 2>&1 | sort -u - ~/.ssh/known_hosts > ~/.ssh/tmp_hosts
mv ~/.ssh/tmp_hosts ~/.ssh/known_hosts

The above will do the trick to add a host, ONLY if it has not yet been added. It is also not concurrency safe; you must not execute the snippet on the same origin machine more than once at the same time, as the tmp_hosts file can get clobbered, ultimately leading to the known_hosts file becoming bloated...

Solution 5

You could use ssh-keyscan command to grab the public key and append that to your known_hosts file.

View more solutions

Comments

[Admin]

For a test environment which is self-contained and physically secure, automated key acceptance may work just fine. But automatically accepting public keys in a production environment or across an untrusted network (such as the Internet) completely bypasses any protection against man-in-the-middle attacks that SSH would otherwise afford. The only valid way to make sure you're secure against MITM attacks is to verify the host's public key through some out-of-band trusted channel. There is no secure way to automate it without setting up a moderately complicated key signing infrastructure.

[Robert]

Why do you need all 3 ssh-keyscan's? Can't you get by with just the first one since it works for both hostname and ip?

[JasperWallace]

This leaves you open to man in the middle attacks, probably not a good idea.

[JasperWallace]

Can you be sure that the machine replying to the ssh-keyscan request is really the one you want to talk to? If not you've opened yourself to a man in the middle attack.

[Admin]

@JasperWallace Yes, for that you need at least the fingerprint or even better the public key, in which case you can add it directly to known_hosts, turning this question moot. If you only have the fingerprint, you will have to write an extra step which verifies the downloaded public key with your fingerprint...

[utapyngo]

Is there a way to check whether the key is in known_hosts before ssh-keyscan? The reason is that it requires some time and additional network connection.

[phasetwenty]

Calls to ssh-keyscan were failing for me because my target host doesn't support the default version 1 key type. Adding -t rsa,dsa to the command fixed this.

[Massimo]

@JasperWallace, while this is usually good advice, the specific use case (deploying test VMs and sending commands to them) should be safe enough.

[Peter V. Mørch]

This gives a Warning: Permanently added 'hostname,1.2.3.4' (RSA) to the list of known hosts. To avoid the warning, and to avoid the entry being added to any known_hosts file, I do: ssh -o StrictHostKeyChecking=no -o LogLevel=ERROR -o UserKnownHostsFile=/dev/null [email protected]

[DanielM]

Note that this must make the connection, so if you need to connect to a port, use -p [port], and if you're automating the process and need to immediate disconnect, send any command you're allowed to execute on the target machine. eg ssh -o StrictHostKeyChecking=no [email protected] -p 2020 'echo hello'

[paulmelnikow]

The original poster's version of this file had cat ~/.ssh/tmp_hosts > ~/.ssh/known_hosts, but a subsequent edit changed it to >>. Using >> is an error. It defeats the purpose of the uniqueness in the first line, and causes it to dump new entries into known_hosts every time it runs. (Just posted an edit to change it back.)

[Sarah Messer]

"ssh-keyscan -H <host> >> ~/.ssh/known_hosts" produces an entry more like what ssh does with user interaction. (The -H hashes the name of the remote host.)

[retrohacker]

This is probably a bad idea. You are opening yourself to a man-in-the-middle attack by updating these keys. To avoid duplicate entries, check the return status of ssh-keygen -F [address] instead. medium.com/@wblankenship/…

[marcv81]

Downvoting as this does not answer the question and opens to serious security vulnerabilities.

[Mnebuerquo]

I also downvoted this. I want to securely connect, not defeat my own ssh.

[Mnebuerquo]

This is only slightly better than the accepted answer. If someone does a MITM attack on you when you do this, then you store their fake keys, and you permanently accept their MITM attack.

[Mnebuerquo]

This is subject to the same MITM attacks as the others.

[Mnebuerquo]

Vulnerable to MITM attacks. You're not checking the key fingerprint.

[Mnebuerquo]

Make sure you check the fingerprint to ensure it is the correct key. Otherwise you open yourself up to MITM attacks.

[Mnebuerquo]

Are you uploading a known valid known_hosts file, or are you doing ssh-keyscan and dumping the output into known_hosts without verifying fingerprints?

[Mnebuerquo]

Vulnerable to MITM attacks. You're not checking the fingerprint.

[Ignacio Vazquez-Abrams]

@Mnebuerquo: If you were worried about security then you wouldn't have anything at all to do with this question. You'd have the correct host key in front of you, gathered from the console of the system you wanted to connect to, and you would manually verify it upon first connecting. You certainly wouldn't do anything "automatically".

[Zart]

This is simply dumps output of a keyscan, yes. So in effect it's the same as StrictHostKeyChecking=no, just with silent known_hosts updating without fiddling with ssh options. This solution also doesn't work well due to ssh-keyscan returning multiple lines which causes this task always be flagged as 'changed'

[Jim]

@Mnebuerquo You say what to do but not how, which would be helpful.

[deepelement]

@IgnacioVazquez-Abrams, just add a disclaimer about the security. This answer is perfectly acceptable with knowledge of impact to security. Many environments, like behind corp firewalls, make the security issue not as dramatic.

[SineSwiper]

Nobody checks the fingerprint.

[panticz]

Make shure you use the right hostname else the key will not by valid

[Brian Cline]

@Mnebuerquo Fair point in the general context, but why would someone be trying to programmatically gather keys if they already knew what the correct key was?

[blafasel]

Deactivating security features to supress 'irritating' warnings is a very bad practise!

[Rogers Sampaio]

This is the right answer if you want to update a host.

[craftomega]

This is not the way to do it. MITM.

[craftomega]

This is not the way to do it. MITM.

[craftomega]

This is not the way to do it. MITM.

[craftomega]

This is not the way to do it. MITM.

[craftomega]

This is not the way to do it. MITM.

[craftomega]

This is not the way to do it. MITM.

[craftomega]

This is not the way to do it. MITM.

[craftomega]

This is not the way to do it. MITM.

[Zart]

If you care that much about MITM, deploy DNSSEC and SSHFP records or use some other secure means of distributing the keys and this kludge solution will be irrelevant.

[fivef]

@jameshfisher Yes its vulnerable to MITM attacks, but have you ever compared the RSA fingerprint, which was shown to you with the actual one of the server, when you were doing this manually? No? So this answer is the way to do it for you. If yes, you shouldn't use this answer and do it manually or implement other security measures...

[Syed Waqas]

@Mnebuerquo I would be really glad if you also let us know a better way to handle this, when we need to clone a repo using batch scripts un-attended and we want to by-pass this prompt. Please shed some light on a real solution if you think this is not the right one!

[Syed Waqas]

@jameshfisher I would be really glad if you also let us know a better way to handle this, when we need to clone a repo using batch scripts un-attended and we want to by-pass this prompt. Please shed some light on a real solution if you think this is not the right one! Please let us know "how" to do it, if you think this is not the right way to do it!

[Syed Waqas]

@Mnebuerquo Thanks for the link, it's such a coincidence that today I used this same approach and to me too this seems like the best one. Thanks anyways!

[Syed Waqas]

I think this is the best solution to this problem. However, be very careful while using Nmap on something like Amazon EC2, I got a warning about the port scanning that Nmap does! Fill in their form before doing portscanning!

[BradChesney79]

...well, yeah. I don't know why you would do the port scanning from EC2. If you are logged in to your account, you can just get the keys from the actual machines. This is more for machines you don't have control over. I would assume you would have a local machine not subject to AWS port scanning restrictions to use. But, if you are in that edge case situation where you must run nmap with AWS, I suppose this warning would be helpful.

[Micah R Ledbetter]

Using nmap to read the SSH host key from your workstation and then trusting that value is no different than connecting via SSH with StructHostKeyChecking turned off. Its just as vulnerable to a man-in-the-middle attack.

[BradChesney79]

...@MicahRLedbetter which is why I suggested that "more comparisons from different computers & networks will usually increase your ability to trust the connection". But, that is my point. If you only ever check your target host from one set of environment conditions then how would you ever know of any discrepancies? Did you have any better suggestions?

[Eil]

The answer by BradChesney79 is not in any sense a better way to do it. Literally all he is doing there is using nmap to get the SSH host key fingerprint and then comparing it to what ssh-keyscan says the fingerprint is. In both cases, the fingerprint comes from the same place. It's just as vulnerable to MITM as any other of these automated solutions. The only secure and valid way to verify an SSH public key is over some trusted out-of-band channel. (Or set up some kind of key-signing infrastructure.)

[Limbo Peng]

This answer should mention the risk of MiTM.

[BradChesney79]

@vastlysuperiorman, from the same computer on the same network or even a different computer on the same network-- yes, it would be a waste of time. Different machine on a completely separate network-- no. If you achieve the same results from asking via different paths with isolated risks of a compromised request and tainted connection, you can increase the confidence your connection to the remote resource has not been unusually tampered with. In most cases, overkill. Just depends on the minimum security requirements.

[Cameron Lowell Palmer]

It is a perfectly valid method of adding values to known_hosts, but yes it is susceptible to MITM. However, for internal use it is fine.

[DylanYoung]

Key signing infrastructure +1 For out-of-band now-a-days, it often suffices to grab the fingerprint from your cloud dashboard (where you create your instances), which almost always have a direct console into the instance. Add these to your list of trusted fingerprints. Then simply compare with the ssh-keyscan result. If you have physical access to the machine, even better!

[DylanYoung]

@WaqasShah Just validate against your repos' possible fingerprints. For github they can be found here: help.github.com/articles/github-s-ssh-key-fingerprints. Now why is 'here' any more secure? Why PKI of course :)

[Martin Bramwell]

I like this answer best. For scripting initial setup of a random VPS of no importance to anyone but me, MITM risk is vanishingly small. Infinitesimal quibble ... first line needs to be mkdir -p ~/.ssh/known_hosts;

[Gabriel Staples]

Useful source: techrepublic.com/article/…; they recommend ssh-keyscan -H 192.168.1.162 >> ~/.ssh/known_hosts, as does @SarahMesser

[Michael]

although this answer is insecure it explicitly answers the question (which even includes the word "bypass") so it seems to me the most correct answer. If this was done in a secure testing network which seems to be the aim of the question this wouldn't be a problem. I've edited it to make the risks more clear. Hopefully that makes it okay.

[Dominik]

If really needed, use StrictHostKeyChecking=accept-new instead =no (see my answer). Otherwise @JasperWallace is right: you're always subject to a man-in-the-middle attack on each connection to the server.

[inetknght]

Your answer does not include a solution to the question: Can I automatically add a new host to known_hosts?

[inetknght]

Your answer does not include a solution to the question: Can I automatically add a new host to known_hosts?

[sodimel]

It includes a solution to the question The problem [...] is that the first ssh command run against a new virtual instance always comes up with an interactive prompt [...]. Is there a way that I can bypass this [...] ?. I found this question by typing interactive prompt fabric and thought that maybe other people will stumble across this for the same reasons.

[Codebling]

Aside from security concerns mentioned elsewhere, this will generate duplicates, as a new hash is generated every time

[Rainb]

This is the right way to do it, sometimes security just gets in the way, +1.

[jehon]

Since those are VM's, you could have a way to access the filesystem and get those keys...

[cjs]

@SyedWaqas As described in my answer, you avoid the risk of MITM on the SSH channel by getting the public key generated by the VM during installation through a different channel.

[Rohit Agrawal]

Hi @inetknght, request you to please read the last line I have mentioned in my answer to this problem statement. I have addressed 2 issues here: 1. When the known_hosts file itself is missing from the system and the system is read-only. 2. automatically add a new host to known_hosts Please let me know in case you need more clarity here.

[Neinstein]

Can HOSTS be a list of IP addresses, instead of only one?

[Dr-Bracket]

@jameshfisher Thanks for replying "MITM" to every answer on this thread. Do you have an actual solution? If not, please consider how your comments waste valuable screen space before hitting CTRL-V next time

[craftomega]

@Dr-Bracket the top comment says it best, "The only valid way to make sure you're secure against MITM attacks is to verify the host's public key through some out-of-band trusted channel". In OP's example, they're "launching a number of virtual machine instances from a central client", which must provide such a trusted channel.

[Dennis Williamson]

Use mktmp or tempfile or similar to avoid the issue with clobbering a hard-coded temporary file.

[Admin]

if ! ssh-keygen -F github.com > /dev/null; then ssh-keyscan github.com >> ~/.ssh/known_hosts; fi