How To Fix Offending key in ~/.ssh/known_hosts file

by Ramesh Natarajan on April 30, 2010

As we discussed earlier in our basic ssh client commands article, when you do ssh to a machine for the 1st time (or whenever there is a key change in the remote machine), you will be prompted to say ‘yes’ for authenticity of host.

This feature is controlled using StrictHostKeyChecking ssh parameter. By default StrictHostKeyChecking is set to yes.

The default setting of “StrictHostKeyChecking yes” is the best option from security point of view to protect your system against any trojan horse attacks. If you don’t know what you are doing, you should not set StrictHostKeyChecking to no.

Sometimes it might be good to disable it temporarily. For example, 1st time when you are connecting to lot of known hosts, you might want to set disable this feature (i.e asking yes for host keys) and let ssh add automatically all the host keys. Later you can enable this feature.

When you have configured automated passwordless login for a server and if the remote host key keeps changing for a reason (that you know why it is changing), you might want to consider setting StrictHostKeyChecking to no until the problem of remote host key keep changing is fixed.

From the ssh command line, you can pass StrictHostKeyChecking option as shown below. You can also set this option in your ssh_config file

# ssh -o 'StrictHostKeyChecking no' user@host

If you are logging in to the server for the 1st time, it would permanently add the RSA to the list of known hosts without prompting you.

But, if there is a key change (normally if the OS (or sshd) is reinstalled, the remote host key will change), then you have to delete old invalid key as shown below.

Remove the offending ssh key

Following error will be displayed when the remote host key changes (after you’ve connected earlier with a valid remote host key).

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/ramesh/.ssh/known_hosts to get rid of this message.
Offending key in /home/ramesh/.ssh/known_hosts: 6
Permission denied (publickey,password).

You have to remove the key to proceed further. Use the following command to remove the offending key.,

# sed -i '6d' ~/.ssh/known_hosts

Note: Change the 6d according to the line number shown.

If your sed does not have -i option, use perl or use some editor to remove the offending key.

Perl solution:

# perl -pi -e 's/\Q$_// if ($. == 6);' ~/.ssh/known_hosts

Note: Change the line number from 6 to appropriate line number.

If you enjoyed this article, you might also like..

  1. 50 Linux Sysadmin Tutorials
  2. 50 Most Frequently Used Linux Commands (With Examples)
  3. Top 25 Best Linux Performance Monitoring and Debugging Tools
  4. Mommy, I found it! – 15 Practical Linux Find Command Examples
  5. Linux 101 Hacks 2nd Edition eBook Linux 101 Hacks Book

Bash 101 Hacks Book Sed and Awk 101 Hacks Book Nagios Core 3 Book Vim 101 Hacks Book

{ 27 comments… read them below or add one }

1 unixadmin007 April 30, 2010 at 2:30 am

how can we do same in vi.. i.e. without opening the vi editor how can we delete this line number??

2 fedov April 30, 2010 at 4:22 am

A less cryptic Perl-Solution:

perl -ni -e ‘print if ($. != 6);’ ~/.ssh/known_hosts

3 Lonnie Olson April 30, 2010 at 10:41 am

You should update your post to include the official OpenSSH way to do it.

ssh-keygen -R hostname

4 Mithun April 30, 2010 at 12:39 pm

# More straight forward

# Remove offending key
ssh-keygen -R hostname

# Add it back
ssh -o ‘StrictHostKeyChecking no’ user@host

5 Jim Douglas April 30, 2010 at 3:52 pm

Thanks…. this was a good tip for me…..

6 Sivakumar May 5, 2010 at 10:49 pm

The below option also does the same tricks, with much less hazels

ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no

7 Thiruvenkatasamy January 10, 2012 at 9:48 am

I faced the same issue in two different (Unix)flavors. The first time i used the “Sed” with -i syntax. It works out.
Second time in Sun OS it was not worked and i tried the “perl” syntax… awesome..!!
Good result … Thanks Geeks for your stuffs!!!

8 Sonam June 28, 2012 at 7:18 pm

this is written for vi newbies. Others please excuse.

vi +6 ~.ssh/known_hosts (Instruct vi to take you directly to the offending line in file)
(Take a look at the hostname — verify this is the key you want to delete)
(Press ‘dd’ to delete the line)
(Command ‘:wq’ to write the file and quit)

Alternatively, open known_hosts using vi and issue command ‘:se nu’ to make line numbers visible.

9 Doug September 28, 2012 at 2:18 pm

Thanks for this article. I used the info. here and it fixed my problem.

10 Kuldeep November 9, 2012 at 1:41 pm

Thanks ……It works . ……..I have used it when I installed new OS (ubuntu 12.04)

11 Shva December 18, 2012 at 11:08 pm

Thank you! This helped me

12 dr memals January 20, 2013 at 3:41 pm

I was booting the same hardware with different media, so completely different OSs and needed BOTH ssh keys to work. The solution
ssh-keyscan -t rsa ip_address >> ~/.ssh/known_hosts

13 stu February 14, 2013 at 10:29 am

Thanks Dude, this post saved me a motorway crawl.


14 Rihan February 25, 2013 at 11:04 pm

Thanks, it helped me.. :)

15 bucshee March 8, 2013 at 9:31 am

But is there a way to do this automatically? I mean if the SSH Key changes for a device already in the known hosts file to have the new key overwritten and then connect via ssh using the new key.

16 Mikey April 25, 2013 at 9:51 am

Much appreciated for you posting this page. It helped me solve my problem.

17 Brad Allison June 8, 2013 at 1:38 am

sed always has the -i option.

just BSD sed (like you find on macosx) requires you pass -i and option like “sed -i .bak”.

But sed always has the -i option. GNU sed just doesn’t require a field after it like BSD sed does.

18 Ismaila Ajenifuja August 28, 2013 at 1:48 pm

The solution provided is awesome and the best so far. Just the one line command: “sed -i ’6d’ ~/.ssh/known_hosts”

Thanks a lot

19 Chris September 10, 2013 at 2:53 am

Lonnie and Mithun, said it easiest way I always forget the letter, R, which is how I just ended up here, but… ~$ ssh-keygen -R (IP or Host) and then just connect as normal ssh user@(ip or host) again! YThen yes to confirm add to known hosts.

20 Suresh September 11, 2013 at 3:45 pm

It really worked

21 julian December 8, 2013 at 1:46 am

Doesn’t work:
Julians-Air:~ jellycat$ sed -i ’13d’ ~/.ssh/known_hosts
sed: 1: “/Users/jellycat/.ssh/kn …”: invalid command code j
(on OSX)

22 Yeaoh February 24, 2014 at 9:57 pm

the sed method didn’t work for me, but the perl one worked fine. I was on MAC OSX 10.9. Still I’m curious about why the sed would return something like like this
sed: 1: “/Users/myuser/.ssh/kno …”: extra characters at the end of g command

23 kk June 9, 2014 at 3:51 am

This helped me in realtime production environment thanks a lot…

24 Rodrigo November 2, 2014 at 9:53 pm

Thank you very much…. I used the perl solution because sed didn’t work to me..
Working very well here…

25 Elham December 3, 2014 at 2:46 am

Tanks very problem is solved

26 factgasm February 20, 2015 at 7:41 pm

Thanks for the post, but had Linux’s developers included this advice in the error message in instead of the juvenile crap they did inculde then this post – and all the searches performed to find it – would never have been necessary in the first place

This mentality sums up Linux very well indeed; they’d rather snigger at the expense of inexperienced users than provide a professional solution that produces fast and effective results. And to think that they have the temerity to knock Microsoft.

27 factgasm February 20, 2015 at 8:03 pm

Thanks for the post, but had Linux’s developers displayed this advice in their error message instead of the irresponsible juvenile nonsense they do, then this article – and all the searches performed to find it – would never have been necessary in the first place.

Leave a Comment

Previous post:

Next post: