1

I'm working on automating a whole environment by using AWS CloudFormation and during the testing period I'm required to kill and re-create the servers very often.

The servers are configured to set their IP addresses from a dedicated pool which means that on the first time I connect to them I have to accept the host key checking (the yes/no question) and then when I delete the server and re-create it, I have to delete the server's key from the known_hosts file each time.

My question is:

Is it possible to delete the key from known_hosts automatically when I close the session? is there such a setting which I've missed?

Itai Ganot
  • 10,644
  • 29
  • 93
  • 146
  • Just as a pointer: The answer of @ptman was posted earlier and contains the same content as the one you've accepted. – gxx Oct 16 '17 at 07:34

3 Answers3

4

You can configure ssh to use multiple files for the known_hosts and new entries only get added to the first, by setting that to /dev/null effectively they won't get saved:

UserKnownHostsFile /dev/null ~/.ssh/known_hosts

Combine it with your personal favourite of asking or automatically accepting unknown keys:

StrictHostKeyChecking no

You probably want to those options restricted to only (specific hosts in) your DEV environment rather than global defaults, as they will take away quite a bit of the security key checking provides so in your ~/.ssh/config:

Host *.dev.example.com
    IdentityFile ~/.ssh/id_rsa.dev.example.com
    UseKeychain yes
    User hbruijn-adm
    StrictHostKeyChecking ask
    UserKnownHostsFile /dev/null ~/.ssh/known_hosts
HBruijn
  • 77,029
  • 24
  • 135
  • 201
  • Please write one or two lines regarding the risks / disadvantages this is introducing – gxx Oct 16 '17 at 07:21
  • @gf_ You're of course right that doing so is insecure, but you can mitigate the impact somewhat as I updated above. – HBruijn Oct 16 '17 at 07:57
1

You could do:

ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null -l user host

StrictHostKeyChecking=no is of course a bad idea, since it will automatically accept all hosts keys

UserKnownHostsFile=/dev/null will not save anything to your normal known_hosts file.

ptman
  • 28,394
  • 2
  • 30
  • 45
  • Please write one or two lines regarding the risks / disadvantages this is introducing. – gxx Oct 16 '17 at 07:20
1

The proper way would be to put the SSHFP (automatically) into the DNS, sign the zone via DNSSEC and let SSH handle the rest, especially, if you need to do this very often and the keys are changing constantly.

gxx
  • 5,591
  • 2
  • 22
  • 42
  • Will ssh(1) actually verify the DNSSEC signature in order to trust the SSHFP record or will it blindly trust the system resolver? – ptman Oct 16 '17 at 07:23
  • @ptman I think (but don't take this for granted) it will rely on the system resolver. The response needs to have the `ad` bit set. – gxx Oct 16 '17 at 07:24
  • Sure, but the interface to the resolver (res_nquery(3)?) doesn't tell ssh(1) if the ad bit was set or not, or does it? – ptman Oct 16 '17 at 07:28
  • @ptman I can't explain the inner workings: I use this myself, but didn't dig into the code. All I can say is, that it makes a difference, it the `ad` bit is set or not. Without `ad`, `SSH` will print `Matching host key fingerprint found in DNS.` and will still ask you to manually accept or decline the fingerprint. – gxx Oct 16 '17 at 07:33