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.
This problem was bugging me for quite some time. The problem is, the OpenSSH client they've compiled for Windows doesn't check the known_hosts file in ~/.ssh/known_hosts
ssh -vvvvvvvvvvvvvvvvvvv git@github.com
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. The answer is to 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 as the host is added to the known_hosts file. This actually fixes the issue, rather than just hiding the log message.
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 Set LogLevel to ERROR (not QUIET) in ~/.ssh/config file to avoid seeing these errors:
Host * StrictHostKeyChecking no UserKnownHostsFile /dev/null LogLevel ERROR 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.
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.
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
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)
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.
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.
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/