This describes how to connect with SSH

To not provide password manually a public/private keys can be generated and stored at appropriate directories in host (private key) and target (public key).

To generate keys on my host (Linux or MacBook) and then store the public key on the raspberry host rpi1 do

$ ssh-keygen -t rsa -C pi@rpi1
$ cat ~/.ssh/ | ssh pi@rpi1.local 'cat >> .ssh/authorized_keys'
alternatively, use the command below instead of cat...
$ ssh-copy-id -i ~/.ssh/ -p 22 pi@

Note that the last command transfer the public key to rpi1 using ssh and store it in file ~/.ssh/authorized_keys. This will invoke to provide password for SSH.

If this doesn't work and you get an error message like pi@ Permission denied (publickey). then check PasswordAuthentication at rpi1 in /etc/ssh/sshd_config and if it's no change it to yes. Don't forget to restart ssh service after that ($ sudo systemctl restart sshd).

Make sure that directory .ssh exists on home directory for user pi at the raspberry host rpi1. If not do $ install -d -m 700 ~/.ssh at the rpi1 first

Note, if file ~/.ssh/ already exists at host there is no need to do ssh-keygen, simply do the last command above ($ cat ~/.ssh...).

To remove an entry in ~/.ssh/known_hosts do

$ ssh-keygen -R rpi1.local

See SSH passwordless.

If ssh tries to connect to a known IP address but receives a different ssh key compared to the one it got before, it makes sense to treat this as a possible security problem and refuse to connect. This can happen if there is a new installation of Raspbian and most commonly manifests by the ssh client reporting something like:

Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the ECDSA key sent by the remote host is

To mitigate this the local ssh client file known_hosts needs to be updated. Do this locally assuming the issues occur while using ssh vs host (rpi1.local).

$ ssh-keyscan >> ~/.ssh/known_hosts

If the IP address or the node name (e.g. "" or "rpi1.local") has been used before, an error message might occur. To find out which entry is for a known hostname in known_hosts:

$ ssh-keygen -H  -F <hostname or IP address>

To delete a single entry from known_hosts (remove both IP address and node name as needed):

$ ssh-keygen -R <hostname or IP address>

Then re-do the command $ ssh-keyscan >> ~/.ssh/known_hosts.

Github ssh access

On Raspberry Pi do (see

$ ssh-keygen -t rsa -b 4096 -C "" # Generate public/private rsa keys in ~/.ssh directory
$ eval "$(ssh-agent -s)"                                 # Make sure ssh is running, should respond "Agent pid 12693"
$ ssh-add ~/.ssh/id_rsa
$ cat .ssh/                                    # List content, copy the content

Go to github and login, under settings/SSH keys, do "add new key". Copy content from the public key.

Verify on RPi with

$ ssh -T
Warning: Permanently added the RSA host key for IP address '' to the list of known hosts.
Hi Wolfrax! You've successfully authenticated, but GitHub does not provide shell access.

To have github working with ssh rather than https do (see, below is valid for user Wolfrax and repository "Swind")

$ git remote -v
origin\ (fetch)
origin\ (push)
$ git remote set-url origin
$ git remote -v
origin\ (fetch)
origin\ (push)


On Mac OSX, I made the following update to ~/.ssh/config (user config file, the system wide file is on /etc/ssh/ssh_config, or equivalently /private/etc/ssh/ssh_config).

AddressFamily inet

This forces ssh to use IPv4 only, default value is "any" which enables both IPv4 and IPv6. I had some trouble with one Raspberry (rpi2, when using $ ssh pi@rpi2.local. When debugging (using $ ssh -vvv pi@rpi2.local ``) it turned out that ``rpi2.local were translated into an IPv6 address instead of an IPv4 for unknown reasons. Using an IPv6, ssh command had to timeout then it retried with a correct IPv4 address instead and connected successfully. This caused and a long connection time.

For my other raspberries, this has not been a problem. I have not digged further into why this became a problem for rpi2 only.