I’m trying to live in that immutable infrastructure world where you just rebuild your machines images instead of patching running systems and then deploy them to the cloud. But, I am so used to ssh’ing into things, especially test things where you are trying to figure out how to do something and just need to log in to the system and tinker about.
So I’ll use Packer to rebuild a machine image, run some scripts via provisioners and launch and image, but the app I’m trying to deploy isn’t quite configured correctly, or I want to look at some logs. Yeah, I know I should be shipping those into some search instance, but I’m still in the habit of going directly to the source and looking at running processes and debugging from there.
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
I finally got tired of copying the command that removes the offending host key, tabbing up and running the ssh command to the host again, and typing ‘yes’ to save the new key. Now, when I rebuild a host and it’s up and responding to ssh again, I go and run this little script:
I was searching for something like it, and the closest I found was:
This just makes that a little easier than having to remember the two commands you need to do that.
Of course, I only use Ubuntu LTS distros and the script assumes some default things specific to that OS.
The way of setting the host key like this might be obsolete in this day and age, I’ve read some discussion of SSH fingerprint DNS records:
- https://en.wikipedia.org/wiki/SSHFP_record
I think it was from here:
- https://security.stackexchange.com/questions/56268/ssh-benefits-of-using-hashed-known-hosts
At any rate at least after I rebuild the instance, I can reset the key and feel somewhat sure I’m logging into the correct thing until I rebuild again.
Leave a Reply