client$ ssh -p 8123 firstname.lastname@example.org -i ~/.ssh/id_dsa Permission denied (publickey).
The answer to this problem is replacing the DSA key with an RSA key, but how do you do on the server when your only means for connecting is the OSX client machine you just upgraded? Here’s how:
First, create a new 4096 bit RSA keypair on the local machine (don’t delete your DSA keys yet!). Don’t use anything less than 4096 bits, and protect it with a lengthy passphrase. This key will replace the DSA key later on.
client$ ssh-keygen -b 4096 -t rsa -f ~/.ssh/id_rsa Generating public/private rsa key pair. Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in id_rsa. Your public key has been saved in id_rsa.pub. The key fingerprint is: SHA256:OA3Vx8qb4kKRWYs8qsq5/EywaLLdwZdlCIITFPnRtt8 email@example.com The key's randomart image is: +---[RSA 4096]----+ |ooo . .. . | | + . o .. . o | |o o +.o= o o | | . o oB=. o | | . .=oS o | |. o.. .*.Eo | |oo oo.o. . | |=o=. o. . | |o*+o. . | +----[SHA256]-----+
Don’t worry about that long passphrase, Sierra now stores that in your Keychain. Now, log into your server by temporarily enabling ssh-dss public key support on the ssh command line, like so:
client$ ssh -p 8123 firstname.lastname@example.org -i ~/.ssh/id_dsa \ -o PubkeyAcceptedKeyTypes=+ssh-dss
If all went well, you should now be connected to your server, but with your old DSA key. The DSA support was disabled in Sierra because it is no longer considered to be a safe option as it is based on the discrete logarithm problem and the key is required to be just 1024 bits long.
What we need to do now is remove the DSA public key from the server and add the newly created RSA key. Start your editor with:
server$ vim ~/.ssh/authorized_keys
Find the old DSA public key, remove it. Add the contents of the
id_rsa.pub on your client machine to this file on the server. Save the file with
Now exit the server and reconnect with your new RSA key from the client:
server$ exit client$ ssh -p 8123 email@example.com -i ~/.ssh/id_rsa
You should now see the welcome message from the server and the command prompt. Please note that the -i option is here for clarity; if your key is in
~/.ssh/id_rsa it will be used as default identity.
If everything worked, please delete the id_dsa key to prevent confusion. All operations should now be back to normal (but safer).
Bonus 1: Tab-completion for SSH
If you are tired of typing the long ssh commands and remembering ip addresses and key files, create a file called
~/.ssh/config and give it the following contents:
# My Super secret server Host secret-server HostName 10.0.0.1 Port 8123 User george IdentityFile ~/.ssh/id_rsa
After saving the file, you can use tab completion after the ssh command, and you will notice that the following command will work:
client$ ssh secret-server
Bonus 2: Per-server identity
With the powers of the config file mentioned earlier, there is no longer a reason to have one key file or one userid per server. Suppose somebody accidentally gets a hold of a key file, or someone figures out a way to find a key for a bunch of packets between two machines. This would mean immediate compromise of all machines. Because there is no extra effort in using multiple keys, I use a new private key for each server. My
~/.ssh/config file looks similar to this:
# My Super secret server Host secret-server HostName 10.0.0.1 Port 8123 User george IdentityFile ~/.ssh/id_george_secret_rsa # The DMZ firewall Host dmz-firewall HostName 10.0.0.21 Port 8623 User jack IdentityFile ~/.ssh/id_jack_dmz_fw_rsa
Because just like passwords, I never use the same private key twice.