When connecting to an SSH server for the first time, you are often presented with a message like this:
The authenticity of host 'github.com (220.127.116.11)' can't be established. RSA key fingerprint is 16:27:ac:a5:76:28:2d:36:63:1b:56:4d:eb:df:a6:48. Are you sure you want to continue connecting (yes/no)?
You may have shrugged this off, since you only ever need to agree once. However, when provisioning servers out in the cloud, there is no option to type "yes" at the command line. Attempting to connect to a remote SSH server will fail unless authorized. As such, services like the following will could also fail to connect:
How do you safely enable connections to remote servers via SSH using Chef?
The answer lies with SSH. SSH looks at "known_hosts" to determine if a server can be accessed. If a server is not in SSH's "known_hosts", the SSH daemon will prompt you to continue connecting. We need a way to dynamically add servers to SSH's known hosts with Chef.
I looked around the community site and found Opscode's SSH Known Hosts Cookbook. It looked good, but required that I know my server's key beforehand. In the case of something like github, the remote key signature may change over time, and I don't want to do a mass find-and-replace across my Chef repo when a server changes - I'd rather rely on FQDNs. So I headed out to write my own.
Thus I created the Known Host Cookbook. It's actually not a cookbook at all, but rather an LWRP for specifying SSH known hosts. It accepts either a
host attribute. If the
host attribute is specified, Chef queries the remote server for its key. If
key is specified, the key is assumed to be valid (just like Opscode's version).
Seth Vargo is an engineer at Google Cloud. Previously he worked at HashiCorp, Chef Software, CustomInk, and some Pittsburgh-based startups. He is the author of Learning Chef and is passionate about reducing inequality in technology. When he is not writing, working on open source, teaching, or speaking at conferences, Seth advises non-profits.