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.

Solution 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.

Solution 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

Solution 3

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

Host *
   StrictHostKeyChecking no
   UserKnownHostsFile /dev/null
   LogLevel ERROR

Solution 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.

Solution 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.

View more solutions

Comments

[Cascabel]

Do you really mean every time? Is it giving you a prompt of the form The authenticity of host '...' can't be established. RSA key fingerprint is .... Are you sure you want to continue connecting (yes/no)?, or have you suppressed that? If it is, is it the same fingerprint every time? If it's not, that's really scary. The less scary option would be that somehow it's not actually managing to write to the hosts file, so it tries again every time. Have a look at ~/.ssh/known_hosts?

[Donald T]

Yes. <i>Every</i> time. However, I don't see the "Are you sure..." message - maybe I've suppressed it.

[Cascabel]

Is the host listed in ~/.ssh/known_hosts? (Is it listed 5000 times?) Does ~/.ssh/config exist/contain anything (especially a value for StrictHostKeyChecking)?

[Donald T]

The host is listed in that file once, and it is the only entry.

[Borealid]

@JackB. Is the file readable/writable? What about by users other than you (ssh will ignore it if so)? Your ~/.ssh directory needs to be mod 700 in order for SSH to pay any attention at all.

[Donald T]

Unfortunately, changing the permissions as suggested didn't fix the problem.

[Donald T]

@Jefromi The config file contains "StrictHostKeyChecking no"

[Cascabel]

That's exactly what suppresses the warning message, and that's not there by default. However, since there's only one host, it sounds like it's supplying the same key every time. If remove/comment that line, then with every push/pull do you see the same message, with the same key?

[Donald T]

I tried removing "StrictHostKeyChecking no", but that caused the server to be rejected.

[tripleee]

I'm guessing the contents of your known_hosts file are bad. It should be the host key, on one terribly long line. If you only have the host name there (for example) it will not work. I recommend that you remove this file (if indeed it only contains the information for this single host) and allow SSH to create it next time you connect. It should be silent after that.

[Chris Page]

In general, if a program invokes ssh and ssh misbehaves, the first thing to try is running ssh on its own to connect to the same host and see what happens.

[Donald T]

tripleee, I tried deleting the "known_hosts" file so that it could be recreated, but the problem persists.

[Donald T]

But I connect to it 10-15 times each day, and still I receive this warning.

[Borealid]

@JackB. Look at ~/.ssh/known_hosts and see if your host is in there.

[Jason Carreiro]

Is the key changing for some reason? Check the fingerprint in the file vs the fingerprint that is output by ssh. Also, is the mode of your .ssh directory set to 0700?

[Donald T]

Adding "LogLevel=quiet" to the "config" file worked. Thank you.

[Joe]

To maintain security, it would be good to put the "LogLevel=quiet" inside a "Host" section.

[Elazar Leibovich]

LogLevel=quiet is a bad idea, he wants all errors to be displayed, he just want to avoid this specific obnoxious error. Probably because he tricked ssh to use /dev/null as the known_hosts file, probably because he wanted to turn off known_hosts fingerprint checking, but couldn't, because ssh overlords didn't allow him to.

[Elazar Leibovich]

@JasonCarreiro, I'm a big boy, I know no one will pull MITM attack inside my rack, security is a tradeoff, and I want new computers to work out of the box with preshared key, with no need to manage a CA or ssh-keyscan.

[Jeremiah Gowdy]

Yeah, I don't consider suppressing warnings or errors a proper solution to a problem. ;)

[m-ric]

recently, I faced same issue on my ubuntu machine. It started to behave this way after I used a different (from my default ~/.ssh/id_rsa) key to connect to a server. As @JeremiahGowdy mentioned, I have debug3: load_hostkeys: loading entries for host "172.16.3.101" from file "/dev/null". Why does SSH starts using /dev/null as known_hosts after I changed key?

[Guss]

@bukzor loglevel=error still displays "Connection to <server> closed" when the connection is terminated, which is also really annoying for scripting.

[qwertzguy]

Note: If you use private key authentication, you cannot use HTTP(S).

[Brad]

This worked best in my case - or you can specify "-oLogLevel=ERROR" on the command line

[ADTC]

Works great! Finally the stupid warning stopped. Btw on Windows, the ~ in ~/.ssh/config is the user's home folder. To open it easily, Press Win-R, type cmd Enter. Command prompt should already open in your home folder. Type cd .ssh Enter, and then start . Enter to open the folder in Windows Explorer. Then you can create the config file in Notepad (no .txt extension when saving). (Pro users can echo directly to a new file in command prompt itself ;)). Run a git command involving remote twice (like git fetch), and you're done.

[bubakazouba]

why do you have 20 v's for ssh?

[Petr Mánek]

@bubakazouba The more v's, the more verbose the log gets, check the docs for that. Three would suffice, twenty are an overkill :D

[Jeremiah Gowdy]

Yeah, holding down v for a second is faster than checking the docs to determine the maximum number of useful v's

[rhand]

Worked for me on OSX High Sierra as well. Afterwards I had to remove the key though and log in another two times.. Makes me wonder if just replacing the offending key would have worked as well as Larry Cai mentioned in his answer: stackoverflow.com/a/16432171/460885

[Agilanbu]

try to highlight the keywords and be clear with the format it will help to reach out your answer for others

[alaboudi]

I downvoted this as it doesn't really solve the problem. It just hides it.

[TNT]

I use these settings only for local ips and hosts which are mostly vms where the hostkey changes relatively often: Host 192.* 10.* *.mylocal.domain.

[ThangTD]

Super smart =)) this one works perfectly and simply: LogLevel ERROR

[Qiyu Zhong]

I was curious if the evolution of macOS system versions would change the steps the take here in the solution? Thanks!