Git says "Warning: Permanently added to the list of known hosts"

Question

Every time I use git to interact with a remote, such as when pulling or pushing, I am shown the following message:

Warning: Permanently added '...' (RSA) to the list of known hosts.

How can I prevent this annoying message from displaying? It is only an annoyance—everything functions properly.

Answer 1

Solution: create a ~/.ssh/config file and insert the line:

UserKnownHostsFile ~/.ssh/known_hosts

You will then see the message the next time you access Github, but after that you'll not see it anymore because the host is added to the known_hosts file. This fixes the issue, rather than just hiding the log message.

This problem was bugging me for quite some time. The problem occurs because the OpenSSH client compiled for Windows doesn't check the known_hosts file in ~/.ssh/known_hosts

ssh -vvvvvvvvvvvvvvvvvvv [email protected]

debug3: check_host_in_hostfile: filename /dev/null
debug3: check_host_in_hostfile: filename /etc/ssh/ssh_known_hosts
debug3: check_host_in_hostfile: filename /dev/null
debug3: check_host_in_hostfile: filename /etc/ssh/ssh_known_hosts
Warning: Permanently added 'github.com,207.97.227.239' (RSA) to the list of known hosts.

Answer 2

Add the following line to your ssh config file ($HOME/.ssh/config):

LogLevel=quiet

If running ssh from the command line add the following option to the command string:

-o LogLevel=quiet

For example, the following prints out the gcc version installed on machine.example.org (and no warning):

ssh -o UserKnownHostsFile=/dev/null \
    -o StrictHostKeyChecking=no \
    -o LogLevel=quiet \
    -i identity_file \
    machine.example.org \
    gcc -dumpversion

Answer 3

Set LogLevel to ERROR (not QUIET) in ~/.ssh/config file to avoid seeing these errors:

Host *
   StrictHostKeyChecking no
   UserKnownHostsFile /dev/null
   LogLevel ERROR

Answer 4

That message is from SSH, which is warning you that you are connecting to a host which you've never connected to before. I wouldn't recommend turning it off, since it would mean that you might miss a warning about a host key changing, which can indicate a MITM attack on your SSH session.

Answer 5

To suppress warning messages for ssh you can add the following lines to ~/.ssh/config:

Host *
LogLevel error

That will disable warnings but not error messages. Like the other settings in ~/.ssh/config you can configure the LogLevel on a per-host basis if you want a more finegrained control.

Answer 6

It mainly means there are changes for the key for that host ~/.ssh/known_hosts, and it will not automatically UPDATE it. Therefore every time you get this warning message.

This happens often for the connecting to the re-created virtual machines, which changes the key with the same IP address

Solution

If you only have one entry, then you can delete the ~/.ssh/known_hosts file, and after first connection, that the key will be there, and no warning messages after that.

If you have multiple entries, then you can use command below to remove

$ ssh-keygen -R <hostname>

It works fine for me

Answer 7

If you are using a repository from GitHub, consider using the HTTPS version of the URL instead, to sidestep this problem entirely:

If you clone your repository from within the Windows GitHub application, this is what it uses for the remote URL. Maybe they know something we don't know.

Answer 8

I have the same question, and I found there is not a .ssh file in my ~. So I just create the .ssh directory under ~ path, and the issue solved.

Answer 9

I got into the same issue when I started using a Windows machine. In my case it was because my SSH setup was not done. Github has a very precise documentation on the SSH setup. Once that's taken care, the issue was resolved.

https://help.github.com/articles/checking-for-existing-ssh-keys/ https://help.github.com/articles/generating-a-new-ssh-key-and-adding-it-to-the-ssh-agent/

Answer 10

Add ssh key

ssh-keygen -t rsa -b 4096 -C "[email protected]"

eval "$(ssh-agent -s)"

ssh-add ~/.ssh/bitbucket_rsa

crate config file

crate ~/.ssh/config

add below line.

UserKnownHostsFile ~/.ssh/known_hosts

Then add pub key and clone your repository... Done.....

Answer 11

I had faced the same error in Linux/Cent OS VM and it was because the IP was changing after restart. In order to get around this problem, I defined a static IP in the network and added that entry to /etc/hosts file. For static IP mention a slightly higher range value. For example if your current IP (ipconfig/ifconfig) is 192.168.0.102, next time after restart this may become 192.168.0.103. So define your static IP in IPV4 settings as 192.168.0.181 which should do the trick.

Answer 12

In my case, it was because the admin who set up the server set these options in ~/.ssh/config

StrictHostKeyChecking no
UserKnownHostsFile /dev/null

Which worked fine for most cases by not using the ~/.ssh/known_hosts file. But for the enterprise gitlab repo, every time it gave the "Warning: Permanently added ... to the list of known hosts."

My solution was to comment out the UserKnownHostsFile /dev/null line, which allowed the creation of ~/.ssh/known_hosts. Then it didn't give any more warnings after that.

You might also have a old/invalid entries in your known_hosts.

# find entry in ~/.ssh/known_hosts
ssh-keygen -F <hostname>

# delete entry in ~/.ssh/known_hosts
ssh-keygen -R <hostname>

Answer 13

add your private key to the ssh-agent with:

ssh-add ~/.ssh/id_rsa

Answer 14

I my case I only got the ssh warning when using Gridengine qrsh remote shell login. Whereas a normal ssh would work as expected (warning first time, then quiet subsequent times).

My solution was to manually fill ~/.ssh/known_hosts with all the possible server names that Gridengine could choose (use qhost to list the servers):

for p in server1 server2 server3 server4; do
  ssh-keyscan -H ${p}.company.com;
  ssh-keyscan -H $(getent hosts $p | perl -lane 'print $F[0]');
done >> ~/.ssh/known_hosts

Background:

Gridengine is a job scheduler which can use ssh to select the least loaded server. The reason for the warning is that qrsh seem to always specify a non-standard port for doing the ssh connection, causing known_hosts to be updated with an entry also containing a port number. Next time when qrsh selects the same server there would be a new port-number and known_hosts would get updated with a new port-specific entry. The reason for also adding the raw host IP address is that some hosts used ecdsa-sha2-nistp521. If a raw IP entry is not added I would get the warning:

ECDSA host key for IP address '10.1.2.3' not in list of known hosts.

Answer 15

There is no clean solution for the problem you noted as far as I am aware.
The previously suggested /dev/null redirection will still display the warning, it just disables the security feature of storing the remote keys by redirecting the output into /dev/null.
So ssh would still think it writes something which is actually discarded.

As I know the only option is to catch the message and remove it from stdout.

ssh/scp..... 2>&1 | grep -v "^Warning: Permanently added"

Here is a complete example that you can use as wrapper to hide such warnings:

#!/bin/bash
remove="^Warning: Permanently added" # message to remove from output

cmd=${0##*/}

case $cmd in
 ssh)
  binary=/usr/bin/ssh
 ;;
 *)
  echo "unsupported binary ($0)"
  exit
 ;;
esac
$binary "$@" 2>&1 | grep -v "$remove"

To install it all you need to do is add/modify the "case" statement for the actual command you wish to modify. (ssh, scp, git etc).
the "ssh)" means the script has to be named "ssh" (or a link to the script is named ssh). The binary=/full/path is the path to the binary the script should wrap.
Then put the script with a name of your choice into /bin or somewhere else.

The script also the place where you can use a -o "UserKnownHostsFile=/dev/null" to the $binary variable, that's a lot better than putting such a security risk into the global ssh configuration which will affect all your ssh sessions and not just those you want to supress the message.

Disadvantages:
It's a bit overhead, not a perfectly clean solution and moves stderr into stdout which might not be good in all cases.
But it will get rid of any sort of warning messages you don't wish to see and you can use a single script to wrap all binaries you want (by using filesystem links to it)