How to fix warning about ECDSA host key












228















I'm trying to setup password-less SSH on an Ubuntu server with ssh-copy-id myuser@myserver, but I'm getting the error:




Warning: the ECDSA host key for 'myserver' differs from the key for the IP address '192.168.1.123'




What's causing this, and how do I fix it? I tried deleting the .ssh directory on the remote machine, and running ssh-keygen -R "myserver" locally, but this doesn't resolve the error.










share|improve this question

























  • in my case, I change the server(ip) bind with the domain, then the The ECDSA host key for server has changed. My way is remove the related cache string about domain in ~/.ssh/known_hosts. Then the ssh works.

    – Ninja
    Jul 11 '17 at 3:59


















228















I'm trying to setup password-less SSH on an Ubuntu server with ssh-copy-id myuser@myserver, but I'm getting the error:




Warning: the ECDSA host key for 'myserver' differs from the key for the IP address '192.168.1.123'




What's causing this, and how do I fix it? I tried deleting the .ssh directory on the remote machine, and running ssh-keygen -R "myserver" locally, but this doesn't resolve the error.










share|improve this question

























  • in my case, I change the server(ip) bind with the domain, then the The ECDSA host key for server has changed. My way is remove the related cache string about domain in ~/.ssh/known_hosts. Then the ssh works.

    – Ninja
    Jul 11 '17 at 3:59
















228












228








228


67






I'm trying to setup password-less SSH on an Ubuntu server with ssh-copy-id myuser@myserver, but I'm getting the error:




Warning: the ECDSA host key for 'myserver' differs from the key for the IP address '192.168.1.123'




What's causing this, and how do I fix it? I tried deleting the .ssh directory on the remote machine, and running ssh-keygen -R "myserver" locally, but this doesn't resolve the error.










share|improve this question
















I'm trying to setup password-less SSH on an Ubuntu server with ssh-copy-id myuser@myserver, but I'm getting the error:




Warning: the ECDSA host key for 'myserver' differs from the key for the IP address '192.168.1.123'




What's causing this, and how do I fix it? I tried deleting the .ssh directory on the remote machine, and running ssh-keygen -R "myserver" locally, but this doesn't resolve the error.







ssh security ubuntu-server ssh-keys






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Feb 10 '15 at 13:05









Owen Blacker

129111




129111










asked May 5 '12 at 19:05









CerinCerin

2,606123453




2,606123453













  • in my case, I change the server(ip) bind with the domain, then the The ECDSA host key for server has changed. My way is remove the related cache string about domain in ~/.ssh/known_hosts. Then the ssh works.

    – Ninja
    Jul 11 '17 at 3:59





















  • in my case, I change the server(ip) bind with the domain, then the The ECDSA host key for server has changed. My way is remove the related cache string about domain in ~/.ssh/known_hosts. Then the ssh works.

    – Ninja
    Jul 11 '17 at 3:59



















in my case, I change the server(ip) bind with the domain, then the The ECDSA host key for server has changed. My way is remove the related cache string about domain in ~/.ssh/known_hosts. Then the ssh works.

– Ninja
Jul 11 '17 at 3:59







in my case, I change the server(ip) bind with the domain, then the The ECDSA host key for server has changed. My way is remove the related cache string about domain in ~/.ssh/known_hosts. Then the ssh works.

– Ninja
Jul 11 '17 at 3:59












12 Answers
12






active

oldest

votes


















333














Remove the cached key for 192.168.1.123 on the local machine:



ssh-keygen -R 192.168.1.123





share|improve this answer



















  • 12





    Didn't work for me on newly install Debian server at work when SSHing in from home. Also, answer is pretty terse.

    – Chris K
    Jan 16 '14 at 7:29











  • /home/wf/.ssh/known_hosts updated. Original contents retained as /home/wf/.ssh/known_hosts.old "Warning: Permanently added the ECDSA host key for IP address 'x.x.x.x' to the list of known hosts." is displayed. and then it seems to work

    – Wolfgang Fahl
    Jul 25 '14 at 6:55








  • 10





    You can update key instead of removing it. Use ssh-keyscan -t ecdsa my.server.domain >> ~/.ssh/known_hosts after that you don't need to verificate new key at first connecting to host.

    – Alex
    Jul 13 '16 at 10:01






  • 1





    For whom don't succeed to make it work: I've had registered multiples occurrences of the same IP : 1/ the said IP address (xx.xx.xx.xx), domain (tomsihap.fr), provider's given vps server address (vpsxxx.ovh.net). ssh-keygen -R for each of these did the work.

    – tomsihap
    Dec 17 '16 at 23:02











  • Worked for me, but the confusion might be from which host should this command be run? The answer is from the one that exhibited the error. The second question and answer are more obvious, but just in case: which address to pass to ssh-keygen -R? The address that figures in the error statement.

    – Russ Bateman
    Oct 27 '17 at 0:27



















45














In my case ssh-keygen -R ... didn't fix the warning. I had extra information like this:



Offending key for IP in /home/myuser/.ssh/known_hosts:8
Matching host key in /home/myuser/.ssh/known_hosts:24


I simply manually edited ~/.ssh/known_hosts and deleted line 8 (the "offending key"). I tried reconnecting, the host was permanently added, and everything was fine after that!






share|improve this answer



















  • 1





    Works like a charm. Can fix this in one line with sed -e '8d' /home/myuser/.ssh/known_hosts, replacing the line number 8 and the filename with those displayed on your system.

    – Alex P. Miller
    Jun 22 '17 at 14:57





















14














I do lots of ssh-ing around between my LAN computers and my two webhosting accounts, so I've sorted out all kinds of odds and ends with SSH, including authentication problems using ssh -v to see where and what went wrong.



Having just resolved this issue and not being happy with the answers, I wanted to really know "why" myself...



The trigger for my case is: installed new server OS at work and upon installing openssh-server package, a new set of host keys were generated on work's server. Previously, all of my server OSs were Ubuntu and this time it changed to Debian (and I suspect there is a nuanced difference in permissions).



When all OSs were Ubuntu and I reinstall a server's OS, upon the first SSH in to it, I get this kind of warning, which I prefer over the silent warning above!



@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
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
06:ea:f1:f8:db:75:5c:0c:af:15:d7:99:2d:ef:08:2a.
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:4
RSA host key for domain.com has changed and you have requested strict checking.
Host key verification failed.


Then I open up ~/.ssh/known_hosts on the computer initiating the ssh, delete that line, reconnect and this happens:



chris@home ~ $ ssh work
The authenticity of host '[work]:11122 ([99.85.243.208]:11122)' can't be established.
ECDSA key fingerprint is 56:6d:13:be:fe:a0:29:ca:53:da:23:d6:1d:36:dd:c5.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '[work]:11122 ([99.85.243.208]:11122)' (ECDSA) to the list of known hosts.
Linux rock 3.2.0-4-amd64 #1 SMP Debian 3.2.51-1 x86_64


That bit about :11122 is the port number I route SSH from on the firewall



I checked backups from a former Ubuntu server and diff'd against my new Debian install:



Ubuntu:                                            Debian:
# Package generated configuration file # Package generated configuration file
# See the sshd(8) manpage for details # See the sshd_config(5) manpage for details

# What ports, IPs and protocols we listen for # What ports, IPs and protocols we listen for
Port 22 Port 22
# Use these options to restrict which interface # Use these options to restrict which interfaces
#ListenAddress :: #ListenAddress ::
#ListenAddress 0.0.0.0 #ListenAddress 0.0.0.0
Protocol 2 Protocol 2
# HostKeys for protocol version 2 # HostKeys for protocol version 2
HostKey /etc/ssh/ssh_host_rsa_key HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key HostKey /etc/ssh/ssh_host_dsa_key
------------------------------------------------ HostKey /etc/ssh/ssh_host_ecdsa_key
#Privilege Separation is turned on for security #Privilege Separation is turned on for security
UsePrivilegeSeparation yes UsePrivilegeSeparation yes


So yes, likely, the host started using ecdsa keys recently, which based upon Ubuntu's changes lately, I would blame on an update. Ubuntu's shift away from the rock-solid linux OS I counted on is why I installed Debian this time around.



I read a security.SE q/a on ecdsa and have already removed that line from sshd_config my new Debian server. (and ran service ssh restart)






share|improve this answer





















  • 2





    +1 for the nice side-by-side comparison block. Could you add a URL clariying "Ubuntu's shift away from the rock-solid linux OS" means?

    – bgoodr
    Feb 9 '14 at 16:43











  • @bgoodr it's my opinion & solely based upon setting up my own RAID fileserver several times over the past few years. :/ Crap for answer, but start googling ubuntu debian server and you'll see what I mean.

    – Chris K
    Feb 10 '14 at 7:00






  • 1





    @ChrisK You, sir, are a boss. Thanks for the detailed, yet concise, answer.

    – sargas
    Aug 12 '16 at 15:46



















5














ssh-keygen -f "/root/.ssh/known_hosts" -R 192.168.1.123



This should replace the existing keys under known_hosts.old and create a new one.
This solution worked for me in the same scenario






share|improve this answer































    4














    The prompt occurs every time because the IP addresses change all the time when using dynamic addressing. Try to use static IP so you only have to add the key only once.






    share|improve this answer



















    • 1





      Good point, did I miss where someone mentioned dynamic ips?

      – Chris K
      Jan 16 '14 at 20:13



















    2














    Are you using the same user for connecting?



    If you are logged into a local PC like user John and connected to the server B like user Adolf@B and everything is OK, it does not mean that everything is OK if you are logged to local PC like user Jane and connecting to the server B like user Adolf@B.



    If you want to login on server B as user Beda from PC A without password, try this command, all from PC A:



    ssh-keygen -t rsa


    This command generates the key and stores the key in the file. Please leave passphrase empty.



    ssh Beda@B mkdir -p .ssh


    This command creates the directory, if they do not already exist. Otherwise, do not print an error message.



    cd ~/.ssh


    This command changes the directory to your users home directory ./ssh.



    cat id_rsa.pub | ssh Beda@B 'cat >> .ssh/authorized_keys'


    This command prints the file id_rsa.pub (your public key) into authorized_keys on the server.



    IMPORTANT: Beda is your username on the server which you are connecting, B is your server IP.



    Now, you can connect to the server B without a password or passphrase:



    ssh Beda@B





    share|improve this answer


























    • Or just use ssh-copy-id to populate an authorized_keys file with your id_rsa.pub key without all the extra hassle.

      – BlakBat
      Aug 27 '18 at 11:03



















    1














    The thread here may help.



    Essentially, you want to remove both the RSA and ECDSA keys for that host, then use ssh-keyscan to put them back into your known_hosts file in a way that won't cause this conflict. It worked for me when I had the same issue.






    share|improve this answer

































      1














      Question: What's causing this, ...?



      So the ssh server host key changed. 
      What caused the change? 
      It is hard to say. 
      Here are some guesses:




      • Did sshd on myserver start using ECDSA keys, so it is a new key type?

      • Was myserver recently re-installed?

      • Was sshd on myserver recently re-insalled so a new ssh host key was generated?

      • Did someone re-generate or replace the sshd host key?

      • Has the IP address of myserver changed so that a different host is answering to that IP address?


      Question: ... and how do I fix it?



      As others have already answered, remove the cached ECDSA host key for myserver that your account has cached.






      share|improve this answer





















      • 2





        Good advice, but doesn't actually answer the question. Doesn't even TRY to answer the question.

        – boatcoder
        Apr 3 '13 at 14:18



















      1














      This error kept annoying me for a long time. For some reason it made a difference whether i would do a



      ssh host


      or



      ssh host.domain


      https://askubuntu.com/questions/87449/how-to-disable-strict-host-key-checking-in-ssh



      then pointed me to the option of changing the config file. See my script https://askubuntu.com/a/949731/129227 there for automating the process.






      share|improve this answer



















      • 1





        Using configuration values CanonicalizeHostname and CanonicalDomains would avoid removing strict checking and would make ssh consider host and host.domain to be same.

        – BlakBat
        Nov 3 '18 at 15:02



















      0














      I fixed this on a Chromebook by uninstalling and reinstalling Secure Shell... It worked like a charm.






      share|improve this answer
























      • This is overkill. See a simpler solution in my answer here.

        – Alex Yursha
        Jul 24 '17 at 7:57



















      0














      Here is how to remove a known host fingerprint (from known_hosts file) on a Chrome OS:



      Find the index of the offending host entry in the ssh output when the connection fails. For example in the line below offending index is 7:



      Offending ECDSA key in /.ssh/known_hosts:7


      Open the JavaScript console (CTRL+Shift+J) of Secure Shell window and type the following, replacing INDEX with the appropriate value (e.g. 7):



      term_.command.removeKnownHostByIndex(INDEX);


      This solution was borrowed from Leo Gaggl's Blog.






      share|improve this answer































        0














        I added the following lines to my ~/.ssh/config, thus disabling strict host checking for all .local addresses. (with DHCP address allocation, ip addresses of my local machines are always changing)



        host *.local
        StrictHostKeyChecking no


        You still get the warning, though, which is fine by me.






        share|improve this answer






















          protected by Community Dec 30 '18 at 22:02



          Thank you for your interest in this question.
          Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).



          Would you like to answer one of these unanswered questions instead?














          12 Answers
          12






          active

          oldest

          votes








          12 Answers
          12






          active

          oldest

          votes









          active

          oldest

          votes






          active

          oldest

          votes









          333














          Remove the cached key for 192.168.1.123 on the local machine:



          ssh-keygen -R 192.168.1.123





          share|improve this answer



















          • 12





            Didn't work for me on newly install Debian server at work when SSHing in from home. Also, answer is pretty terse.

            – Chris K
            Jan 16 '14 at 7:29











          • /home/wf/.ssh/known_hosts updated. Original contents retained as /home/wf/.ssh/known_hosts.old "Warning: Permanently added the ECDSA host key for IP address 'x.x.x.x' to the list of known hosts." is displayed. and then it seems to work

            – Wolfgang Fahl
            Jul 25 '14 at 6:55








          • 10





            You can update key instead of removing it. Use ssh-keyscan -t ecdsa my.server.domain >> ~/.ssh/known_hosts after that you don't need to verificate new key at first connecting to host.

            – Alex
            Jul 13 '16 at 10:01






          • 1





            For whom don't succeed to make it work: I've had registered multiples occurrences of the same IP : 1/ the said IP address (xx.xx.xx.xx), domain (tomsihap.fr), provider's given vps server address (vpsxxx.ovh.net). ssh-keygen -R for each of these did the work.

            – tomsihap
            Dec 17 '16 at 23:02











          • Worked for me, but the confusion might be from which host should this command be run? The answer is from the one that exhibited the error. The second question and answer are more obvious, but just in case: which address to pass to ssh-keygen -R? The address that figures in the error statement.

            – Russ Bateman
            Oct 27 '17 at 0:27
















          333














          Remove the cached key for 192.168.1.123 on the local machine:



          ssh-keygen -R 192.168.1.123





          share|improve this answer



















          • 12





            Didn't work for me on newly install Debian server at work when SSHing in from home. Also, answer is pretty terse.

            – Chris K
            Jan 16 '14 at 7:29











          • /home/wf/.ssh/known_hosts updated. Original contents retained as /home/wf/.ssh/known_hosts.old "Warning: Permanently added the ECDSA host key for IP address 'x.x.x.x' to the list of known hosts." is displayed. and then it seems to work

            – Wolfgang Fahl
            Jul 25 '14 at 6:55








          • 10





            You can update key instead of removing it. Use ssh-keyscan -t ecdsa my.server.domain >> ~/.ssh/known_hosts after that you don't need to verificate new key at first connecting to host.

            – Alex
            Jul 13 '16 at 10:01






          • 1





            For whom don't succeed to make it work: I've had registered multiples occurrences of the same IP : 1/ the said IP address (xx.xx.xx.xx), domain (tomsihap.fr), provider's given vps server address (vpsxxx.ovh.net). ssh-keygen -R for each of these did the work.

            – tomsihap
            Dec 17 '16 at 23:02











          • Worked for me, but the confusion might be from which host should this command be run? The answer is from the one that exhibited the error. The second question and answer are more obvious, but just in case: which address to pass to ssh-keygen -R? The address that figures in the error statement.

            – Russ Bateman
            Oct 27 '17 at 0:27














          333












          333








          333







          Remove the cached key for 192.168.1.123 on the local machine:



          ssh-keygen -R 192.168.1.123





          share|improve this answer













          Remove the cached key for 192.168.1.123 on the local machine:



          ssh-keygen -R 192.168.1.123






          share|improve this answer












          share|improve this answer



          share|improve this answer










          answered May 5 '12 at 20:20









          grawitygrawity

          233k36494549




          233k36494549








          • 12





            Didn't work for me on newly install Debian server at work when SSHing in from home. Also, answer is pretty terse.

            – Chris K
            Jan 16 '14 at 7:29











          • /home/wf/.ssh/known_hosts updated. Original contents retained as /home/wf/.ssh/known_hosts.old "Warning: Permanently added the ECDSA host key for IP address 'x.x.x.x' to the list of known hosts." is displayed. and then it seems to work

            – Wolfgang Fahl
            Jul 25 '14 at 6:55








          • 10





            You can update key instead of removing it. Use ssh-keyscan -t ecdsa my.server.domain >> ~/.ssh/known_hosts after that you don't need to verificate new key at first connecting to host.

            – Alex
            Jul 13 '16 at 10:01






          • 1





            For whom don't succeed to make it work: I've had registered multiples occurrences of the same IP : 1/ the said IP address (xx.xx.xx.xx), domain (tomsihap.fr), provider's given vps server address (vpsxxx.ovh.net). ssh-keygen -R for each of these did the work.

            – tomsihap
            Dec 17 '16 at 23:02











          • Worked for me, but the confusion might be from which host should this command be run? The answer is from the one that exhibited the error. The second question and answer are more obvious, but just in case: which address to pass to ssh-keygen -R? The address that figures in the error statement.

            – Russ Bateman
            Oct 27 '17 at 0:27














          • 12





            Didn't work for me on newly install Debian server at work when SSHing in from home. Also, answer is pretty terse.

            – Chris K
            Jan 16 '14 at 7:29











          • /home/wf/.ssh/known_hosts updated. Original contents retained as /home/wf/.ssh/known_hosts.old "Warning: Permanently added the ECDSA host key for IP address 'x.x.x.x' to the list of known hosts." is displayed. and then it seems to work

            – Wolfgang Fahl
            Jul 25 '14 at 6:55








          • 10





            You can update key instead of removing it. Use ssh-keyscan -t ecdsa my.server.domain >> ~/.ssh/known_hosts after that you don't need to verificate new key at first connecting to host.

            – Alex
            Jul 13 '16 at 10:01






          • 1





            For whom don't succeed to make it work: I've had registered multiples occurrences of the same IP : 1/ the said IP address (xx.xx.xx.xx), domain (tomsihap.fr), provider's given vps server address (vpsxxx.ovh.net). ssh-keygen -R for each of these did the work.

            – tomsihap
            Dec 17 '16 at 23:02











          • Worked for me, but the confusion might be from which host should this command be run? The answer is from the one that exhibited the error. The second question and answer are more obvious, but just in case: which address to pass to ssh-keygen -R? The address that figures in the error statement.

            – Russ Bateman
            Oct 27 '17 at 0:27








          12




          12





          Didn't work for me on newly install Debian server at work when SSHing in from home. Also, answer is pretty terse.

          – Chris K
          Jan 16 '14 at 7:29





          Didn't work for me on newly install Debian server at work when SSHing in from home. Also, answer is pretty terse.

          – Chris K
          Jan 16 '14 at 7:29













          /home/wf/.ssh/known_hosts updated. Original contents retained as /home/wf/.ssh/known_hosts.old "Warning: Permanently added the ECDSA host key for IP address 'x.x.x.x' to the list of known hosts." is displayed. and then it seems to work

          – Wolfgang Fahl
          Jul 25 '14 at 6:55







          /home/wf/.ssh/known_hosts updated. Original contents retained as /home/wf/.ssh/known_hosts.old "Warning: Permanently added the ECDSA host key for IP address 'x.x.x.x' to the list of known hosts." is displayed. and then it seems to work

          – Wolfgang Fahl
          Jul 25 '14 at 6:55






          10




          10





          You can update key instead of removing it. Use ssh-keyscan -t ecdsa my.server.domain >> ~/.ssh/known_hosts after that you don't need to verificate new key at first connecting to host.

          – Alex
          Jul 13 '16 at 10:01





          You can update key instead of removing it. Use ssh-keyscan -t ecdsa my.server.domain >> ~/.ssh/known_hosts after that you don't need to verificate new key at first connecting to host.

          – Alex
          Jul 13 '16 at 10:01




          1




          1





          For whom don't succeed to make it work: I've had registered multiples occurrences of the same IP : 1/ the said IP address (xx.xx.xx.xx), domain (tomsihap.fr), provider's given vps server address (vpsxxx.ovh.net). ssh-keygen -R for each of these did the work.

          – tomsihap
          Dec 17 '16 at 23:02





          For whom don't succeed to make it work: I've had registered multiples occurrences of the same IP : 1/ the said IP address (xx.xx.xx.xx), domain (tomsihap.fr), provider's given vps server address (vpsxxx.ovh.net). ssh-keygen -R for each of these did the work.

          – tomsihap
          Dec 17 '16 at 23:02













          Worked for me, but the confusion might be from which host should this command be run? The answer is from the one that exhibited the error. The second question and answer are more obvious, but just in case: which address to pass to ssh-keygen -R? The address that figures in the error statement.

          – Russ Bateman
          Oct 27 '17 at 0:27





          Worked for me, but the confusion might be from which host should this command be run? The answer is from the one that exhibited the error. The second question and answer are more obvious, but just in case: which address to pass to ssh-keygen -R? The address that figures in the error statement.

          – Russ Bateman
          Oct 27 '17 at 0:27













          45














          In my case ssh-keygen -R ... didn't fix the warning. I had extra information like this:



          Offending key for IP in /home/myuser/.ssh/known_hosts:8
          Matching host key in /home/myuser/.ssh/known_hosts:24


          I simply manually edited ~/.ssh/known_hosts and deleted line 8 (the "offending key"). I tried reconnecting, the host was permanently added, and everything was fine after that!






          share|improve this answer



















          • 1





            Works like a charm. Can fix this in one line with sed -e '8d' /home/myuser/.ssh/known_hosts, replacing the line number 8 and the filename with those displayed on your system.

            – Alex P. Miller
            Jun 22 '17 at 14:57


















          45














          In my case ssh-keygen -R ... didn't fix the warning. I had extra information like this:



          Offending key for IP in /home/myuser/.ssh/known_hosts:8
          Matching host key in /home/myuser/.ssh/known_hosts:24


          I simply manually edited ~/.ssh/known_hosts and deleted line 8 (the "offending key"). I tried reconnecting, the host was permanently added, and everything was fine after that!






          share|improve this answer



















          • 1





            Works like a charm. Can fix this in one line with sed -e '8d' /home/myuser/.ssh/known_hosts, replacing the line number 8 and the filename with those displayed on your system.

            – Alex P. Miller
            Jun 22 '17 at 14:57
















          45












          45








          45







          In my case ssh-keygen -R ... didn't fix the warning. I had extra information like this:



          Offending key for IP in /home/myuser/.ssh/known_hosts:8
          Matching host key in /home/myuser/.ssh/known_hosts:24


          I simply manually edited ~/.ssh/known_hosts and deleted line 8 (the "offending key"). I tried reconnecting, the host was permanently added, and everything was fine after that!






          share|improve this answer













          In my case ssh-keygen -R ... didn't fix the warning. I had extra information like this:



          Offending key for IP in /home/myuser/.ssh/known_hosts:8
          Matching host key in /home/myuser/.ssh/known_hosts:24


          I simply manually edited ~/.ssh/known_hosts and deleted line 8 (the "offending key"). I tried reconnecting, the host was permanently added, and everything was fine after that!







          share|improve this answer












          share|improve this answer



          share|improve this answer










          answered Mar 11 '14 at 18:52









          aardvarkkaardvarkk

          73731021




          73731021








          • 1





            Works like a charm. Can fix this in one line with sed -e '8d' /home/myuser/.ssh/known_hosts, replacing the line number 8 and the filename with those displayed on your system.

            – Alex P. Miller
            Jun 22 '17 at 14:57
















          • 1





            Works like a charm. Can fix this in one line with sed -e '8d' /home/myuser/.ssh/known_hosts, replacing the line number 8 and the filename with those displayed on your system.

            – Alex P. Miller
            Jun 22 '17 at 14:57










          1




          1





          Works like a charm. Can fix this in one line with sed -e '8d' /home/myuser/.ssh/known_hosts, replacing the line number 8 and the filename with those displayed on your system.

          – Alex P. Miller
          Jun 22 '17 at 14:57







          Works like a charm. Can fix this in one line with sed -e '8d' /home/myuser/.ssh/known_hosts, replacing the line number 8 and the filename with those displayed on your system.

          – Alex P. Miller
          Jun 22 '17 at 14:57













          14














          I do lots of ssh-ing around between my LAN computers and my two webhosting accounts, so I've sorted out all kinds of odds and ends with SSH, including authentication problems using ssh -v to see where and what went wrong.



          Having just resolved this issue and not being happy with the answers, I wanted to really know "why" myself...



          The trigger for my case is: installed new server OS at work and upon installing openssh-server package, a new set of host keys were generated on work's server. Previously, all of my server OSs were Ubuntu and this time it changed to Debian (and I suspect there is a nuanced difference in permissions).



          When all OSs were Ubuntu and I reinstall a server's OS, upon the first SSH in to it, I get this kind of warning, which I prefer over the silent warning above!



          @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
          @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
          @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
          IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
          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
          06:ea:f1:f8:db:75:5c:0c:af:15:d7:99:2d:ef:08:2a.
          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:4
          RSA host key for domain.com has changed and you have requested strict checking.
          Host key verification failed.


          Then I open up ~/.ssh/known_hosts on the computer initiating the ssh, delete that line, reconnect and this happens:



          chris@home ~ $ ssh work
          The authenticity of host '[work]:11122 ([99.85.243.208]:11122)' can't be established.
          ECDSA key fingerprint is 56:6d:13:be:fe:a0:29:ca:53:da:23:d6:1d:36:dd:c5.
          Are you sure you want to continue connecting (yes/no)? yes
          Warning: Permanently added '[work]:11122 ([99.85.243.208]:11122)' (ECDSA) to the list of known hosts.
          Linux rock 3.2.0-4-amd64 #1 SMP Debian 3.2.51-1 x86_64


          That bit about :11122 is the port number I route SSH from on the firewall



          I checked backups from a former Ubuntu server and diff'd against my new Debian install:



          Ubuntu:                                            Debian:
          # Package generated configuration file # Package generated configuration file
          # See the sshd(8) manpage for details # See the sshd_config(5) manpage for details

          # What ports, IPs and protocols we listen for # What ports, IPs and protocols we listen for
          Port 22 Port 22
          # Use these options to restrict which interface # Use these options to restrict which interfaces
          #ListenAddress :: #ListenAddress ::
          #ListenAddress 0.0.0.0 #ListenAddress 0.0.0.0
          Protocol 2 Protocol 2
          # HostKeys for protocol version 2 # HostKeys for protocol version 2
          HostKey /etc/ssh/ssh_host_rsa_key HostKey /etc/ssh/ssh_host_rsa_key
          HostKey /etc/ssh/ssh_host_dsa_key HostKey /etc/ssh/ssh_host_dsa_key
          ------------------------------------------------ HostKey /etc/ssh/ssh_host_ecdsa_key
          #Privilege Separation is turned on for security #Privilege Separation is turned on for security
          UsePrivilegeSeparation yes UsePrivilegeSeparation yes


          So yes, likely, the host started using ecdsa keys recently, which based upon Ubuntu's changes lately, I would blame on an update. Ubuntu's shift away from the rock-solid linux OS I counted on is why I installed Debian this time around.



          I read a security.SE q/a on ecdsa and have already removed that line from sshd_config my new Debian server. (and ran service ssh restart)






          share|improve this answer





















          • 2





            +1 for the nice side-by-side comparison block. Could you add a URL clariying "Ubuntu's shift away from the rock-solid linux OS" means?

            – bgoodr
            Feb 9 '14 at 16:43











          • @bgoodr it's my opinion & solely based upon setting up my own RAID fileserver several times over the past few years. :/ Crap for answer, but start googling ubuntu debian server and you'll see what I mean.

            – Chris K
            Feb 10 '14 at 7:00






          • 1





            @ChrisK You, sir, are a boss. Thanks for the detailed, yet concise, answer.

            – sargas
            Aug 12 '16 at 15:46
















          14














          I do lots of ssh-ing around between my LAN computers and my two webhosting accounts, so I've sorted out all kinds of odds and ends with SSH, including authentication problems using ssh -v to see where and what went wrong.



          Having just resolved this issue and not being happy with the answers, I wanted to really know "why" myself...



          The trigger for my case is: installed new server OS at work and upon installing openssh-server package, a new set of host keys were generated on work's server. Previously, all of my server OSs were Ubuntu and this time it changed to Debian (and I suspect there is a nuanced difference in permissions).



          When all OSs were Ubuntu and I reinstall a server's OS, upon the first SSH in to it, I get this kind of warning, which I prefer over the silent warning above!



          @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
          @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
          @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
          IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
          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
          06:ea:f1:f8:db:75:5c:0c:af:15:d7:99:2d:ef:08:2a.
          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:4
          RSA host key for domain.com has changed and you have requested strict checking.
          Host key verification failed.


          Then I open up ~/.ssh/known_hosts on the computer initiating the ssh, delete that line, reconnect and this happens:



          chris@home ~ $ ssh work
          The authenticity of host '[work]:11122 ([99.85.243.208]:11122)' can't be established.
          ECDSA key fingerprint is 56:6d:13:be:fe:a0:29:ca:53:da:23:d6:1d:36:dd:c5.
          Are you sure you want to continue connecting (yes/no)? yes
          Warning: Permanently added '[work]:11122 ([99.85.243.208]:11122)' (ECDSA) to the list of known hosts.
          Linux rock 3.2.0-4-amd64 #1 SMP Debian 3.2.51-1 x86_64


          That bit about :11122 is the port number I route SSH from on the firewall



          I checked backups from a former Ubuntu server and diff'd against my new Debian install:



          Ubuntu:                                            Debian:
          # Package generated configuration file # Package generated configuration file
          # See the sshd(8) manpage for details # See the sshd_config(5) manpage for details

          # What ports, IPs and protocols we listen for # What ports, IPs and protocols we listen for
          Port 22 Port 22
          # Use these options to restrict which interface # Use these options to restrict which interfaces
          #ListenAddress :: #ListenAddress ::
          #ListenAddress 0.0.0.0 #ListenAddress 0.0.0.0
          Protocol 2 Protocol 2
          # HostKeys for protocol version 2 # HostKeys for protocol version 2
          HostKey /etc/ssh/ssh_host_rsa_key HostKey /etc/ssh/ssh_host_rsa_key
          HostKey /etc/ssh/ssh_host_dsa_key HostKey /etc/ssh/ssh_host_dsa_key
          ------------------------------------------------ HostKey /etc/ssh/ssh_host_ecdsa_key
          #Privilege Separation is turned on for security #Privilege Separation is turned on for security
          UsePrivilegeSeparation yes UsePrivilegeSeparation yes


          So yes, likely, the host started using ecdsa keys recently, which based upon Ubuntu's changes lately, I would blame on an update. Ubuntu's shift away from the rock-solid linux OS I counted on is why I installed Debian this time around.



          I read a security.SE q/a on ecdsa and have already removed that line from sshd_config my new Debian server. (and ran service ssh restart)






          share|improve this answer





















          • 2





            +1 for the nice side-by-side comparison block. Could you add a URL clariying "Ubuntu's shift away from the rock-solid linux OS" means?

            – bgoodr
            Feb 9 '14 at 16:43











          • @bgoodr it's my opinion & solely based upon setting up my own RAID fileserver several times over the past few years. :/ Crap for answer, but start googling ubuntu debian server and you'll see what I mean.

            – Chris K
            Feb 10 '14 at 7:00






          • 1





            @ChrisK You, sir, are a boss. Thanks for the detailed, yet concise, answer.

            – sargas
            Aug 12 '16 at 15:46














          14












          14








          14







          I do lots of ssh-ing around between my LAN computers and my two webhosting accounts, so I've sorted out all kinds of odds and ends with SSH, including authentication problems using ssh -v to see where and what went wrong.



          Having just resolved this issue and not being happy with the answers, I wanted to really know "why" myself...



          The trigger for my case is: installed new server OS at work and upon installing openssh-server package, a new set of host keys were generated on work's server. Previously, all of my server OSs were Ubuntu and this time it changed to Debian (and I suspect there is a nuanced difference in permissions).



          When all OSs were Ubuntu and I reinstall a server's OS, upon the first SSH in to it, I get this kind of warning, which I prefer over the silent warning above!



          @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
          @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
          @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
          IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
          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
          06:ea:f1:f8:db:75:5c:0c:af:15:d7:99:2d:ef:08:2a.
          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:4
          RSA host key for domain.com has changed and you have requested strict checking.
          Host key verification failed.


          Then I open up ~/.ssh/known_hosts on the computer initiating the ssh, delete that line, reconnect and this happens:



          chris@home ~ $ ssh work
          The authenticity of host '[work]:11122 ([99.85.243.208]:11122)' can't be established.
          ECDSA key fingerprint is 56:6d:13:be:fe:a0:29:ca:53:da:23:d6:1d:36:dd:c5.
          Are you sure you want to continue connecting (yes/no)? yes
          Warning: Permanently added '[work]:11122 ([99.85.243.208]:11122)' (ECDSA) to the list of known hosts.
          Linux rock 3.2.0-4-amd64 #1 SMP Debian 3.2.51-1 x86_64


          That bit about :11122 is the port number I route SSH from on the firewall



          I checked backups from a former Ubuntu server and diff'd against my new Debian install:



          Ubuntu:                                            Debian:
          # Package generated configuration file # Package generated configuration file
          # See the sshd(8) manpage for details # See the sshd_config(5) manpage for details

          # What ports, IPs and protocols we listen for # What ports, IPs and protocols we listen for
          Port 22 Port 22
          # Use these options to restrict which interface # Use these options to restrict which interfaces
          #ListenAddress :: #ListenAddress ::
          #ListenAddress 0.0.0.0 #ListenAddress 0.0.0.0
          Protocol 2 Protocol 2
          # HostKeys for protocol version 2 # HostKeys for protocol version 2
          HostKey /etc/ssh/ssh_host_rsa_key HostKey /etc/ssh/ssh_host_rsa_key
          HostKey /etc/ssh/ssh_host_dsa_key HostKey /etc/ssh/ssh_host_dsa_key
          ------------------------------------------------ HostKey /etc/ssh/ssh_host_ecdsa_key
          #Privilege Separation is turned on for security #Privilege Separation is turned on for security
          UsePrivilegeSeparation yes UsePrivilegeSeparation yes


          So yes, likely, the host started using ecdsa keys recently, which based upon Ubuntu's changes lately, I would blame on an update. Ubuntu's shift away from the rock-solid linux OS I counted on is why I installed Debian this time around.



          I read a security.SE q/a on ecdsa and have already removed that line from sshd_config my new Debian server. (and ran service ssh restart)






          share|improve this answer















          I do lots of ssh-ing around between my LAN computers and my two webhosting accounts, so I've sorted out all kinds of odds and ends with SSH, including authentication problems using ssh -v to see where and what went wrong.



          Having just resolved this issue and not being happy with the answers, I wanted to really know "why" myself...



          The trigger for my case is: installed new server OS at work and upon installing openssh-server package, a new set of host keys were generated on work's server. Previously, all of my server OSs were Ubuntu and this time it changed to Debian (and I suspect there is a nuanced difference in permissions).



          When all OSs were Ubuntu and I reinstall a server's OS, upon the first SSH in to it, I get this kind of warning, which I prefer over the silent warning above!



          @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
          @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
          @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
          IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
          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
          06:ea:f1:f8:db:75:5c:0c:af:15:d7:99:2d:ef:08:2a.
          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:4
          RSA host key for domain.com has changed and you have requested strict checking.
          Host key verification failed.


          Then I open up ~/.ssh/known_hosts on the computer initiating the ssh, delete that line, reconnect and this happens:



          chris@home ~ $ ssh work
          The authenticity of host '[work]:11122 ([99.85.243.208]:11122)' can't be established.
          ECDSA key fingerprint is 56:6d:13:be:fe:a0:29:ca:53:da:23:d6:1d:36:dd:c5.
          Are you sure you want to continue connecting (yes/no)? yes
          Warning: Permanently added '[work]:11122 ([99.85.243.208]:11122)' (ECDSA) to the list of known hosts.
          Linux rock 3.2.0-4-amd64 #1 SMP Debian 3.2.51-1 x86_64


          That bit about :11122 is the port number I route SSH from on the firewall



          I checked backups from a former Ubuntu server and diff'd against my new Debian install:



          Ubuntu:                                            Debian:
          # Package generated configuration file # Package generated configuration file
          # See the sshd(8) manpage for details # See the sshd_config(5) manpage for details

          # What ports, IPs and protocols we listen for # What ports, IPs and protocols we listen for
          Port 22 Port 22
          # Use these options to restrict which interface # Use these options to restrict which interfaces
          #ListenAddress :: #ListenAddress ::
          #ListenAddress 0.0.0.0 #ListenAddress 0.0.0.0
          Protocol 2 Protocol 2
          # HostKeys for protocol version 2 # HostKeys for protocol version 2
          HostKey /etc/ssh/ssh_host_rsa_key HostKey /etc/ssh/ssh_host_rsa_key
          HostKey /etc/ssh/ssh_host_dsa_key HostKey /etc/ssh/ssh_host_dsa_key
          ------------------------------------------------ HostKey /etc/ssh/ssh_host_ecdsa_key
          #Privilege Separation is turned on for security #Privilege Separation is turned on for security
          UsePrivilegeSeparation yes UsePrivilegeSeparation yes


          So yes, likely, the host started using ecdsa keys recently, which based upon Ubuntu's changes lately, I would blame on an update. Ubuntu's shift away from the rock-solid linux OS I counted on is why I installed Debian this time around.



          I read a security.SE q/a on ecdsa and have already removed that line from sshd_config my new Debian server. (and ran service ssh restart)







          share|improve this answer














          share|improve this answer



          share|improve this answer








          edited Mar 17 '17 at 13:21









          Community

          1




          1










          answered Jan 16 '14 at 8:12









          Chris KChris K

          7932821




          7932821








          • 2





            +1 for the nice side-by-side comparison block. Could you add a URL clariying "Ubuntu's shift away from the rock-solid linux OS" means?

            – bgoodr
            Feb 9 '14 at 16:43











          • @bgoodr it's my opinion & solely based upon setting up my own RAID fileserver several times over the past few years. :/ Crap for answer, but start googling ubuntu debian server and you'll see what I mean.

            – Chris K
            Feb 10 '14 at 7:00






          • 1





            @ChrisK You, sir, are a boss. Thanks for the detailed, yet concise, answer.

            – sargas
            Aug 12 '16 at 15:46














          • 2





            +1 for the nice side-by-side comparison block. Could you add a URL clariying "Ubuntu's shift away from the rock-solid linux OS" means?

            – bgoodr
            Feb 9 '14 at 16:43











          • @bgoodr it's my opinion & solely based upon setting up my own RAID fileserver several times over the past few years. :/ Crap for answer, but start googling ubuntu debian server and you'll see what I mean.

            – Chris K
            Feb 10 '14 at 7:00






          • 1





            @ChrisK You, sir, are a boss. Thanks for the detailed, yet concise, answer.

            – sargas
            Aug 12 '16 at 15:46








          2




          2





          +1 for the nice side-by-side comparison block. Could you add a URL clariying "Ubuntu's shift away from the rock-solid linux OS" means?

          – bgoodr
          Feb 9 '14 at 16:43





          +1 for the nice side-by-side comparison block. Could you add a URL clariying "Ubuntu's shift away from the rock-solid linux OS" means?

          – bgoodr
          Feb 9 '14 at 16:43













          @bgoodr it's my opinion & solely based upon setting up my own RAID fileserver several times over the past few years. :/ Crap for answer, but start googling ubuntu debian server and you'll see what I mean.

          – Chris K
          Feb 10 '14 at 7:00





          @bgoodr it's my opinion & solely based upon setting up my own RAID fileserver several times over the past few years. :/ Crap for answer, but start googling ubuntu debian server and you'll see what I mean.

          – Chris K
          Feb 10 '14 at 7:00




          1




          1





          @ChrisK You, sir, are a boss. Thanks for the detailed, yet concise, answer.

          – sargas
          Aug 12 '16 at 15:46





          @ChrisK You, sir, are a boss. Thanks for the detailed, yet concise, answer.

          – sargas
          Aug 12 '16 at 15:46











          5














          ssh-keygen -f "/root/.ssh/known_hosts" -R 192.168.1.123



          This should replace the existing keys under known_hosts.old and create a new one.
          This solution worked for me in the same scenario






          share|improve this answer




























            5














            ssh-keygen -f "/root/.ssh/known_hosts" -R 192.168.1.123



            This should replace the existing keys under known_hosts.old and create a new one.
            This solution worked for me in the same scenario






            share|improve this answer


























              5












              5








              5







              ssh-keygen -f "/root/.ssh/known_hosts" -R 192.168.1.123



              This should replace the existing keys under known_hosts.old and create a new one.
              This solution worked for me in the same scenario






              share|improve this answer













              ssh-keygen -f "/root/.ssh/known_hosts" -R 192.168.1.123



              This should replace the existing keys under known_hosts.old and create a new one.
              This solution worked for me in the same scenario







              share|improve this answer












              share|improve this answer



              share|improve this answer










              answered May 14 '15 at 18:16









              Jignesh RawalJignesh Rawal

              15111




              15111























                  4














                  The prompt occurs every time because the IP addresses change all the time when using dynamic addressing. Try to use static IP so you only have to add the key only once.






                  share|improve this answer



















                  • 1





                    Good point, did I miss where someone mentioned dynamic ips?

                    – Chris K
                    Jan 16 '14 at 20:13
















                  4














                  The prompt occurs every time because the IP addresses change all the time when using dynamic addressing. Try to use static IP so you only have to add the key only once.






                  share|improve this answer



















                  • 1





                    Good point, did I miss where someone mentioned dynamic ips?

                    – Chris K
                    Jan 16 '14 at 20:13














                  4












                  4








                  4







                  The prompt occurs every time because the IP addresses change all the time when using dynamic addressing. Try to use static IP so you only have to add the key only once.






                  share|improve this answer













                  The prompt occurs every time because the IP addresses change all the time when using dynamic addressing. Try to use static IP so you only have to add the key only once.







                  share|improve this answer












                  share|improve this answer



                  share|improve this answer










                  answered Jan 16 '14 at 9:06









                  Gaurav JosephGaurav Joseph

                  1,4021120




                  1,4021120








                  • 1





                    Good point, did I miss where someone mentioned dynamic ips?

                    – Chris K
                    Jan 16 '14 at 20:13














                  • 1





                    Good point, did I miss where someone mentioned dynamic ips?

                    – Chris K
                    Jan 16 '14 at 20:13








                  1




                  1





                  Good point, did I miss where someone mentioned dynamic ips?

                  – Chris K
                  Jan 16 '14 at 20:13





                  Good point, did I miss where someone mentioned dynamic ips?

                  – Chris K
                  Jan 16 '14 at 20:13











                  2














                  Are you using the same user for connecting?



                  If you are logged into a local PC like user John and connected to the server B like user Adolf@B and everything is OK, it does not mean that everything is OK if you are logged to local PC like user Jane and connecting to the server B like user Adolf@B.



                  If you want to login on server B as user Beda from PC A without password, try this command, all from PC A:



                  ssh-keygen -t rsa


                  This command generates the key and stores the key in the file. Please leave passphrase empty.



                  ssh Beda@B mkdir -p .ssh


                  This command creates the directory, if they do not already exist. Otherwise, do not print an error message.



                  cd ~/.ssh


                  This command changes the directory to your users home directory ./ssh.



                  cat id_rsa.pub | ssh Beda@B 'cat >> .ssh/authorized_keys'


                  This command prints the file id_rsa.pub (your public key) into authorized_keys on the server.



                  IMPORTANT: Beda is your username on the server which you are connecting, B is your server IP.



                  Now, you can connect to the server B without a password or passphrase:



                  ssh Beda@B





                  share|improve this answer


























                  • Or just use ssh-copy-id to populate an authorized_keys file with your id_rsa.pub key without all the extra hassle.

                    – BlakBat
                    Aug 27 '18 at 11:03
















                  2














                  Are you using the same user for connecting?



                  If you are logged into a local PC like user John and connected to the server B like user Adolf@B and everything is OK, it does not mean that everything is OK if you are logged to local PC like user Jane and connecting to the server B like user Adolf@B.



                  If you want to login on server B as user Beda from PC A without password, try this command, all from PC A:



                  ssh-keygen -t rsa


                  This command generates the key and stores the key in the file. Please leave passphrase empty.



                  ssh Beda@B mkdir -p .ssh


                  This command creates the directory, if they do not already exist. Otherwise, do not print an error message.



                  cd ~/.ssh


                  This command changes the directory to your users home directory ./ssh.



                  cat id_rsa.pub | ssh Beda@B 'cat >> .ssh/authorized_keys'


                  This command prints the file id_rsa.pub (your public key) into authorized_keys on the server.



                  IMPORTANT: Beda is your username on the server which you are connecting, B is your server IP.



                  Now, you can connect to the server B without a password or passphrase:



                  ssh Beda@B





                  share|improve this answer


























                  • Or just use ssh-copy-id to populate an authorized_keys file with your id_rsa.pub key without all the extra hassle.

                    – BlakBat
                    Aug 27 '18 at 11:03














                  2












                  2








                  2







                  Are you using the same user for connecting?



                  If you are logged into a local PC like user John and connected to the server B like user Adolf@B and everything is OK, it does not mean that everything is OK if you are logged to local PC like user Jane and connecting to the server B like user Adolf@B.



                  If you want to login on server B as user Beda from PC A without password, try this command, all from PC A:



                  ssh-keygen -t rsa


                  This command generates the key and stores the key in the file. Please leave passphrase empty.



                  ssh Beda@B mkdir -p .ssh


                  This command creates the directory, if they do not already exist. Otherwise, do not print an error message.



                  cd ~/.ssh


                  This command changes the directory to your users home directory ./ssh.



                  cat id_rsa.pub | ssh Beda@B 'cat >> .ssh/authorized_keys'


                  This command prints the file id_rsa.pub (your public key) into authorized_keys on the server.



                  IMPORTANT: Beda is your username on the server which you are connecting, B is your server IP.



                  Now, you can connect to the server B without a password or passphrase:



                  ssh Beda@B





                  share|improve this answer















                  Are you using the same user for connecting?



                  If you are logged into a local PC like user John and connected to the server B like user Adolf@B and everything is OK, it does not mean that everything is OK if you are logged to local PC like user Jane and connecting to the server B like user Adolf@B.



                  If you want to login on server B as user Beda from PC A without password, try this command, all from PC A:



                  ssh-keygen -t rsa


                  This command generates the key and stores the key in the file. Please leave passphrase empty.



                  ssh Beda@B mkdir -p .ssh


                  This command creates the directory, if they do not already exist. Otherwise, do not print an error message.



                  cd ~/.ssh


                  This command changes the directory to your users home directory ./ssh.



                  cat id_rsa.pub | ssh Beda@B 'cat >> .ssh/authorized_keys'


                  This command prints the file id_rsa.pub (your public key) into authorized_keys on the server.



                  IMPORTANT: Beda is your username on the server which you are connecting, B is your server IP.



                  Now, you can connect to the server B without a password or passphrase:



                  ssh Beda@B






                  share|improve this answer














                  share|improve this answer



                  share|improve this answer








                  edited Nov 12 '15 at 3:21









                  Jamal

                  4561617




                  4561617










                  answered Oct 21 '14 at 9:17









                  Petr DerianPetr Derian

                  212




                  212













                  • Or just use ssh-copy-id to populate an authorized_keys file with your id_rsa.pub key without all the extra hassle.

                    – BlakBat
                    Aug 27 '18 at 11:03



















                  • Or just use ssh-copy-id to populate an authorized_keys file with your id_rsa.pub key without all the extra hassle.

                    – BlakBat
                    Aug 27 '18 at 11:03

















                  Or just use ssh-copy-id to populate an authorized_keys file with your id_rsa.pub key without all the extra hassle.

                  – BlakBat
                  Aug 27 '18 at 11:03





                  Or just use ssh-copy-id to populate an authorized_keys file with your id_rsa.pub key without all the extra hassle.

                  – BlakBat
                  Aug 27 '18 at 11:03











                  1














                  The thread here may help.



                  Essentially, you want to remove both the RSA and ECDSA keys for that host, then use ssh-keyscan to put them back into your known_hosts file in a way that won't cause this conflict. It worked for me when I had the same issue.






                  share|improve this answer






























                    1














                    The thread here may help.



                    Essentially, you want to remove both the RSA and ECDSA keys for that host, then use ssh-keyscan to put them back into your known_hosts file in a way that won't cause this conflict. It worked for me when I had the same issue.






                    share|improve this answer




























                      1












                      1








                      1







                      The thread here may help.



                      Essentially, you want to remove both the RSA and ECDSA keys for that host, then use ssh-keyscan to put them back into your known_hosts file in a way that won't cause this conflict. It worked for me when I had the same issue.






                      share|improve this answer















                      The thread here may help.



                      Essentially, you want to remove both the RSA and ECDSA keys for that host, then use ssh-keyscan to put them back into your known_hosts file in a way that won't cause this conflict. It worked for me when I had the same issue.







                      share|improve this answer














                      share|improve this answer



                      share|improve this answer








                      edited Aug 12 '13 at 23:30









                      ergosys

                      195112




                      195112










                      answered Dec 20 '12 at 16:47









                      Paul A JungwirthPaul A Jungwirth

                      1236




                      1236























                          1














                          Question: What's causing this, ...?



                          So the ssh server host key changed. 
                          What caused the change? 
                          It is hard to say. 
                          Here are some guesses:




                          • Did sshd on myserver start using ECDSA keys, so it is a new key type?

                          • Was myserver recently re-installed?

                          • Was sshd on myserver recently re-insalled so a new ssh host key was generated?

                          • Did someone re-generate or replace the sshd host key?

                          • Has the IP address of myserver changed so that a different host is answering to that IP address?


                          Question: ... and how do I fix it?



                          As others have already answered, remove the cached ECDSA host key for myserver that your account has cached.






                          share|improve this answer





















                          • 2





                            Good advice, but doesn't actually answer the question. Doesn't even TRY to answer the question.

                            – boatcoder
                            Apr 3 '13 at 14:18
















                          1














                          Question: What's causing this, ...?



                          So the ssh server host key changed. 
                          What caused the change? 
                          It is hard to say. 
                          Here are some guesses:




                          • Did sshd on myserver start using ECDSA keys, so it is a new key type?

                          • Was myserver recently re-installed?

                          • Was sshd on myserver recently re-insalled so a new ssh host key was generated?

                          • Did someone re-generate or replace the sshd host key?

                          • Has the IP address of myserver changed so that a different host is answering to that IP address?


                          Question: ... and how do I fix it?



                          As others have already answered, remove the cached ECDSA host key for myserver that your account has cached.






                          share|improve this answer





















                          • 2





                            Good advice, but doesn't actually answer the question. Doesn't even TRY to answer the question.

                            – boatcoder
                            Apr 3 '13 at 14:18














                          1












                          1








                          1







                          Question: What's causing this, ...?



                          So the ssh server host key changed. 
                          What caused the change? 
                          It is hard to say. 
                          Here are some guesses:




                          • Did sshd on myserver start using ECDSA keys, so it is a new key type?

                          • Was myserver recently re-installed?

                          • Was sshd on myserver recently re-insalled so a new ssh host key was generated?

                          • Did someone re-generate or replace the sshd host key?

                          • Has the IP address of myserver changed so that a different host is answering to that IP address?


                          Question: ... and how do I fix it?



                          As others have already answered, remove the cached ECDSA host key for myserver that your account has cached.






                          share|improve this answer















                          Question: What's causing this, ...?



                          So the ssh server host key changed. 
                          What caused the change? 
                          It is hard to say. 
                          Here are some guesses:




                          • Did sshd on myserver start using ECDSA keys, so it is a new key type?

                          • Was myserver recently re-installed?

                          • Was sshd on myserver recently re-insalled so a new ssh host key was generated?

                          • Did someone re-generate or replace the sshd host key?

                          • Has the IP address of myserver changed so that a different host is answering to that IP address?


                          Question: ... and how do I fix it?



                          As others have already answered, remove the cached ECDSA host key for myserver that your account has cached.







                          share|improve this answer














                          share|improve this answer



                          share|improve this answer








                          edited Dec 22 '16 at 8:08









                          Scott

                          15.6k113890




                          15.6k113890










                          answered Aug 7 '12 at 15:42









                          Lars NordinLars Nordin

                          1584




                          1584








                          • 2





                            Good advice, but doesn't actually answer the question. Doesn't even TRY to answer the question.

                            – boatcoder
                            Apr 3 '13 at 14:18














                          • 2





                            Good advice, but doesn't actually answer the question. Doesn't even TRY to answer the question.

                            – boatcoder
                            Apr 3 '13 at 14:18








                          2




                          2





                          Good advice, but doesn't actually answer the question. Doesn't even TRY to answer the question.

                          – boatcoder
                          Apr 3 '13 at 14:18





                          Good advice, but doesn't actually answer the question. Doesn't even TRY to answer the question.

                          – boatcoder
                          Apr 3 '13 at 14:18











                          1














                          This error kept annoying me for a long time. For some reason it made a difference whether i would do a



                          ssh host


                          or



                          ssh host.domain


                          https://askubuntu.com/questions/87449/how-to-disable-strict-host-key-checking-in-ssh



                          then pointed me to the option of changing the config file. See my script https://askubuntu.com/a/949731/129227 there for automating the process.






                          share|improve this answer



















                          • 1





                            Using configuration values CanonicalizeHostname and CanonicalDomains would avoid removing strict checking and would make ssh consider host and host.domain to be same.

                            – BlakBat
                            Nov 3 '18 at 15:02
















                          1














                          This error kept annoying me for a long time. For some reason it made a difference whether i would do a



                          ssh host


                          or



                          ssh host.domain


                          https://askubuntu.com/questions/87449/how-to-disable-strict-host-key-checking-in-ssh



                          then pointed me to the option of changing the config file. See my script https://askubuntu.com/a/949731/129227 there for automating the process.






                          share|improve this answer



















                          • 1





                            Using configuration values CanonicalizeHostname and CanonicalDomains would avoid removing strict checking and would make ssh consider host and host.domain to be same.

                            – BlakBat
                            Nov 3 '18 at 15:02














                          1












                          1








                          1







                          This error kept annoying me for a long time. For some reason it made a difference whether i would do a



                          ssh host


                          or



                          ssh host.domain


                          https://askubuntu.com/questions/87449/how-to-disable-strict-host-key-checking-in-ssh



                          then pointed me to the option of changing the config file. See my script https://askubuntu.com/a/949731/129227 there for automating the process.






                          share|improve this answer













                          This error kept annoying me for a long time. For some reason it made a difference whether i would do a



                          ssh host


                          or



                          ssh host.domain


                          https://askubuntu.com/questions/87449/how-to-disable-strict-host-key-checking-in-ssh



                          then pointed me to the option of changing the config file. See my script https://askubuntu.com/a/949731/129227 there for automating the process.







                          share|improve this answer












                          share|improve this answer



                          share|improve this answer










                          answered Aug 25 '17 at 12:43









                          Wolfgang FahlWolfgang Fahl

                          154110




                          154110








                          • 1





                            Using configuration values CanonicalizeHostname and CanonicalDomains would avoid removing strict checking and would make ssh consider host and host.domain to be same.

                            – BlakBat
                            Nov 3 '18 at 15:02














                          • 1





                            Using configuration values CanonicalizeHostname and CanonicalDomains would avoid removing strict checking and would make ssh consider host and host.domain to be same.

                            – BlakBat
                            Nov 3 '18 at 15:02








                          1




                          1





                          Using configuration values CanonicalizeHostname and CanonicalDomains would avoid removing strict checking and would make ssh consider host and host.domain to be same.

                          – BlakBat
                          Nov 3 '18 at 15:02





                          Using configuration values CanonicalizeHostname and CanonicalDomains would avoid removing strict checking and would make ssh consider host and host.domain to be same.

                          – BlakBat
                          Nov 3 '18 at 15:02











                          0














                          I fixed this on a Chromebook by uninstalling and reinstalling Secure Shell... It worked like a charm.






                          share|improve this answer
























                          • This is overkill. See a simpler solution in my answer here.

                            – Alex Yursha
                            Jul 24 '17 at 7:57
















                          0














                          I fixed this on a Chromebook by uninstalling and reinstalling Secure Shell... It worked like a charm.






                          share|improve this answer
























                          • This is overkill. See a simpler solution in my answer here.

                            – Alex Yursha
                            Jul 24 '17 at 7:57














                          0












                          0








                          0







                          I fixed this on a Chromebook by uninstalling and reinstalling Secure Shell... It worked like a charm.






                          share|improve this answer













                          I fixed this on a Chromebook by uninstalling and reinstalling Secure Shell... It worked like a charm.







                          share|improve this answer












                          share|improve this answer



                          share|improve this answer










                          answered May 18 '15 at 23:26









                          msersenmsersen

                          1




                          1













                          • This is overkill. See a simpler solution in my answer here.

                            – Alex Yursha
                            Jul 24 '17 at 7:57



















                          • This is overkill. See a simpler solution in my answer here.

                            – Alex Yursha
                            Jul 24 '17 at 7:57

















                          This is overkill. See a simpler solution in my answer here.

                          – Alex Yursha
                          Jul 24 '17 at 7:57





                          This is overkill. See a simpler solution in my answer here.

                          – Alex Yursha
                          Jul 24 '17 at 7:57











                          0














                          Here is how to remove a known host fingerprint (from known_hosts file) on a Chrome OS:



                          Find the index of the offending host entry in the ssh output when the connection fails. For example in the line below offending index is 7:



                          Offending ECDSA key in /.ssh/known_hosts:7


                          Open the JavaScript console (CTRL+Shift+J) of Secure Shell window and type the following, replacing INDEX with the appropriate value (e.g. 7):



                          term_.command.removeKnownHostByIndex(INDEX);


                          This solution was borrowed from Leo Gaggl's Blog.






                          share|improve this answer




























                            0














                            Here is how to remove a known host fingerprint (from known_hosts file) on a Chrome OS:



                            Find the index of the offending host entry in the ssh output when the connection fails. For example in the line below offending index is 7:



                            Offending ECDSA key in /.ssh/known_hosts:7


                            Open the JavaScript console (CTRL+Shift+J) of Secure Shell window and type the following, replacing INDEX with the appropriate value (e.g. 7):



                            term_.command.removeKnownHostByIndex(INDEX);


                            This solution was borrowed from Leo Gaggl's Blog.






                            share|improve this answer


























                              0












                              0








                              0







                              Here is how to remove a known host fingerprint (from known_hosts file) on a Chrome OS:



                              Find the index of the offending host entry in the ssh output when the connection fails. For example in the line below offending index is 7:



                              Offending ECDSA key in /.ssh/known_hosts:7


                              Open the JavaScript console (CTRL+Shift+J) of Secure Shell window and type the following, replacing INDEX with the appropriate value (e.g. 7):



                              term_.command.removeKnownHostByIndex(INDEX);


                              This solution was borrowed from Leo Gaggl's Blog.






                              share|improve this answer













                              Here is how to remove a known host fingerprint (from known_hosts file) on a Chrome OS:



                              Find the index of the offending host entry in the ssh output when the connection fails. For example in the line below offending index is 7:



                              Offending ECDSA key in /.ssh/known_hosts:7


                              Open the JavaScript console (CTRL+Shift+J) of Secure Shell window and type the following, replacing INDEX with the appropriate value (e.g. 7):



                              term_.command.removeKnownHostByIndex(INDEX);


                              This solution was borrowed from Leo Gaggl's Blog.







                              share|improve this answer












                              share|improve this answer



                              share|improve this answer










                              answered Jul 24 '17 at 7:55









                              Alex YurshaAlex Yursha

                              1012




                              1012























                                  0














                                  I added the following lines to my ~/.ssh/config, thus disabling strict host checking for all .local addresses. (with DHCP address allocation, ip addresses of my local machines are always changing)



                                  host *.local
                                  StrictHostKeyChecking no


                                  You still get the warning, though, which is fine by me.






                                  share|improve this answer




























                                    0














                                    I added the following lines to my ~/.ssh/config, thus disabling strict host checking for all .local addresses. (with DHCP address allocation, ip addresses of my local machines are always changing)



                                    host *.local
                                    StrictHostKeyChecking no


                                    You still get the warning, though, which is fine by me.






                                    share|improve this answer


























                                      0












                                      0








                                      0







                                      I added the following lines to my ~/.ssh/config, thus disabling strict host checking for all .local addresses. (with DHCP address allocation, ip addresses of my local machines are always changing)



                                      host *.local
                                      StrictHostKeyChecking no


                                      You still get the warning, though, which is fine by me.






                                      share|improve this answer













                                      I added the following lines to my ~/.ssh/config, thus disabling strict host checking for all .local addresses. (with DHCP address allocation, ip addresses of my local machines are always changing)



                                      host *.local
                                      StrictHostKeyChecking no


                                      You still get the warning, though, which is fine by me.







                                      share|improve this answer












                                      share|improve this answer



                                      share|improve this answer










                                      answered Mar 15 '18 at 12:23









                                      KimSJKimSJ

                                      1




                                      1

















                                          protected by Community Dec 30 '18 at 22:02



                                          Thank you for your interest in this question.
                                          Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).



                                          Would you like to answer one of these unanswered questions instead?



                                          Popular posts from this blog

                                          Probability when a professor distributes a quiz and homework assignment to a class of n students.

                                          Aardman Animations

                                          Are they similar matrix