Agnus Dei (jackal) wrote in linux,
Agnus Dei

How to log into a host via ssh and completely ignore host keys.

How to log into a host via ssh and completely ignore host keys.

[jackal@brads-mac]# ssh -o LogLevel=quiet -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no date
Thu Jun 6 15:32:55 UTC 2013

How cool is that?

Completely ignores host keys. So you'll never see an error like this again:

[jackal@brads-mac]# ssh
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the RSA host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
Please contact your system administrator.
Add correct host key in /home/user/.ssh/known_hosts to get rid of this message.
Offending key in /home/user/.ssh/known_hosts:1
Password authentication is disabled to avoid man-in-the-middle attacks.
Agent forwarding is disabled to avoid man-in-the-middle attacks.
X11 forwarding is disabled to avoid man-in-the-middle attacks.
Permission denied (publickey,password,keyboard-interactive).

Now to make it permanent:  Add the following lines to the beginning of the SSH configuration file (~/.ssh/config).

Host *
  StrictHostKeyChecking no

You can ever remove your ~/.ssh/known_hosts file as it will no longer be needed or read anymore.
  • Post a new comment


    Anonymous comments are disabled in this journal

    default userpic

    Your IP address will be recorded 

If you're going to do something as brain-dead as that, why are you even using SSH in the first place? Go back to using telnet and FTP.
because host get regenerated, and you can pass the -o StrictHostKeyChecking=no to get an interactive shell, but when you try to open tunnels the error of the host keys mismatch while prevent the port forwarding to work. So it's to just bypass that check since we aren't doing anything with host keys anyhow.

While it's certainly true that you *CAN* regenerate a host's RSA and DSA keys, you *DON'T*. The only legitimate reasons I'm aware of for regenning the keys are:

  1. The OS has been completely reinstalled on the system, so of course the keys are going to be different.(unless you restore the old keys from backups)

  2. You discovered that someone has copied the host keys and has another box out there pretending to be yours.

If the OS has NOT been reinstalled on the system, and the person responsible for adminning the box did not EXPLICITLY regen the keys (and tell you they did so) then you should never get that message unless either the box has been compromised or your traffic is being intercepted and decrypted by somebody other than the computer you're trying to connect to.
Again you didn't answer my questions.

I called me "Brain-dead" and told me I should go back to using "telnet", So I asked you if you were actually USING RSA Host-Based Authentication. Do you even know what RSA Host-Based Authentication is?

If you are not using it, and clearly don't understand it, then why would you be complaining about it?

Who's "brain-dead" here?
If you're regenerating the host key so often that it becomes a problem then you're doing it wrong. I've been using remote hosting for over a decade with companies that absolutely know their security and I've never had such a problem.

Don't take offense at melstav's words, he's just a little flipped out that anyone would do anything so utterly reckless. This, theoretically, isn't a problem if you're doing it entirely on a virtual machine with a host-only network and you need to work around regular re-installs but on any externally accessible computer you might as well hang up a big sign saying 'enter here, I won't know what's hit me'.

In case it's not quite clear enough, I use SSH all the time, including on virtual machines via host-only networks locked by IP and I would never even dream of muting the RSA key verification.
The problem is the keys getting regenerated. Fix that instead.
And why is it "brain-dead" are you doing anything with host keys? Have you enabled RSA Host based authentication?

If not, then why are you complaining? You are complaining about something you don't even use.
I like it : ) Thanks. Melstav's criticism is pretty harsh. Mostly because if you went to ssh in and got this warning you'd ignore it and update the key. If you were really worried about keys you'd be logging in with one and not a password anyways. Which is exactly what you were trying to explain. That's why i think it's a clever hack : )
If I get this warning in ssh I contact the admin and make sure he's aware his server is compromised.
If his server was compromised you'd get no warning from SSH. The only way you'd get this warning was if the traffic was being intercepted midway and you were actually connected to a middleman's box, not your target. Even then, if they had his key then you'd get no warning.
In my case I knew the servers were restarted/rebuilt, but another team had tunnels set up to connect to them under "autossh" and those tunnels all failed. With these options they could have it reconnect when we regenerate a new server and they will have no downtime.
"Regenerate a new server"? What kind of crazy setup do you have where host keys are constantly discarded? Fix the setup instead of breaking ssh!
Awesome, thanks! I reinstall our test boxes daily and the host key checking is doing my head in!