I have tried to match the public keys and private keys on both my client and server as well as the configuration files but cannot get my head around the mismatches. I can successfully connect to the server on ssh despite the mismatches. This is a bit worrying.

I will show exactly what is stored where.

Client: Mac Server: Ubuntu (hosted on AWS)

Files on my local mac /Users/sm/.ssh directory

ls -la 
Sanjays-iMac:.ssh sm$ ls -la
total 24
drwx------   5 sm  staff   160 26 Nov 21:29 .
drwxr-xr-x+ 59 sm  staff  1888 26 Nov 21:29 ..
-rw-------   1 sm  staff  1696 26 Nov 20:49 id_rsa
-rw-r--r--@  1 sm  staff   451 26 Nov 20:50 id_rsa.pub
-rw-r--r--   1 sm  staff  1151 26 Nov 21:08 known_hosts

Files on my ubuntu server:

ubuntu@ip-172-31-30-19:~/.ssh$ ls -la
total 12
drwx------ 2 ubuntu ubuntu 4096 Nov 26 14:37 .
drwxr-xr-x 8 ubuntu ubuntu 4096 Oct 30 18:02 ..
-rw------- 1 ubuntu ubuntu  391 May 25  2018 authorized_keys

Present working directory on Ubuntu:

ubuntu@ip-172-31-30-19:~/.ssh$ pwd

Contents of authorized_keys file on the server:

ubuntu@ip-172-31-30-19:~/.ssh$ cat authorized_keys 
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAA....0g1bMv+p11K8MDH sanjaydev

(contents are chopped off for privacy reasons)

Similarly, there is a known_hosts file on my local server:

Sanjays-iMac:.ssh sm$ cat known_hosts ecdsa-sha2-nistp256 AAAAE2VjZHNhLX..Xsb/RBY= ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTI....hAkfLOc5g=
ec2-13-127-241-121.ap-south-1.compute.amazonaws.com, ecdsa-sha2-nistp256 AAAAE2VjZHNhLXN....fu5Co4vYB0=
ec2-13-232-81-251.ap-south-1.compute.amazonaws.com, ecdsa-sha2-nistp256 AAAAE2VjZHNhL....nhNcRyfu5Co4vYB0= ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNo....NcRyfu5Co4vYB0= ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTIt....NcRyfu5Co4vYB0=

(contents are chopped off for privacy reasons)

Now my question is:

What should be equal to what?

I would think that the public key on the client should match with one of the entries inside the authorised_keys file on the server and the public key of the server should match with one of the entres in the known_hosts file on the client.

Unfortunately, when I manually try to match them they did not match fully (only first few characters match). It is important to note that the ssh connection still goes through without giving the -i <pemfile> on the command line.

4 Answers 4


There are two kinds of keys: Server or host keys, which identify the server to the user, and user keys, which allow logging in.

The private host key of the server is stored in /etc/ssh/. The corresponding public key is automatically added (after a prompt) to known_hosts in ~/.ssh on the client. The purpose of these keys is detect a man-in-the-middle (MITM) attack: If the host key suddenly changes when you type ssh ... as usual, and you know nothing has changed on the server, you should get suspicious.

Usually you don't have to concern yourself with the host keys, they are managed automatically.

User keys allow authentication without entering passwords. User keys are managed on the client: You have created a key pair consisting of your public key id_rsa.pub and your private key id_rsa. They are stored on the client under ~/.ssh. The public key is not used, it's just stored there to be available when needed. You must manually add the public key to the ~/.ssh/authorized_keys for the corresponding user on the server. One key per line; if the authorized_keys file is empty, a copy (e.g. via scp and password) of id_rsa.pub is enough.

So in your case, the

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAA....0g1bMv+p11K8MDH sanjaydev

in the authorized_keys file on the Ubuntu server must be equal to your id_rsa.pub key on the Mac.

If it is equal and you still can't log in, something else is wrong.

  • ... and if you don’t like manually editing authorized_keys, ssh-copy-id can take care of it for you. Nov 27, 2018 at 7:59
  • 1
    One advantage of editing authorized_keys manually is that while you are doing that, you'll also look at it and can verify that it contains all the keys it should (no more, and no less; and often enough I find a key that shouldn't be in there anymore). But yes, you can automate it.
    – dirkt
    Nov 27, 2018 at 8:04
  • Indeed, I like your point about taking the opportunity to check the keys which are already there! Good key hygiene is important. Nov 27, 2018 at 8:07
  • What you conclude at the end is actually my question. Your statement: "the entry in the authorised_keys file on the Ubuntu must be equal to your id_rsa.pub on the Mac". Well they aren;t equal but I still am able to ssh successfully. i also get a warning while connecting: key_load_public: invalid format. So perhaps the id_rsa.pub is corrupted. So as a summary my question is still open.
    – user30994
    Nov 27, 2018 at 8:17
  • 1
    @user30994+ you revealed on another answer you used openssl rsa -pubout to create the public key. That's wrong; OpenSSL uses very different format for public key than OpenSSH. Use ssh-keygen -y -f privatefile if you need to (re)generate the public key for OpenSSH. Nov 28, 2018 at 8:15

Key Format Fun

From your comments listed on other answers, it looks like you may have a key format problem.

It is true that a cryptographic key created with one standardized program is the same mathematically as a key generated in another. However, a given cryptographic protocol expects keys in a given format.

Converting Keys

  • openssl to ssh keys

Keys generated in openssl and outputted in PEM format can be converted to ssh format using the ssh-keygen program.

ssh-keygen -i -m pem -f key.pem

  • ssh keys to PEM

Keys generated using ssh-keygen can be converted to PEM format:

ssh-keygen -e -m pem -f id_rsa.pub

  • PGP to ssh keys

PGP keys generated in GPG can be converted to ssh format using the --export-ssh-key option:

gpg --export-ssh-key <keyid>

Location of keys

As listed in other answers, the remote system requires the public key stored in ssh format in the ~/.ssh/authorized_keys file. And the local system requires that the private key is:

  • Stored as id_rsa in ~/.ssh


  • Supplied using the ssh -i option


  • Added to the ssh agent using ssh-add


  • Added to the ssh agent using GPG's sshcontrol file

Comparing Public Keys

In order to compare public keys, those keys must be in the same format. Otherwise, the keys won't look the same, even though they are the same objects mathematically. So, since you've indicated that you generated your ssh public key using openssl in PEM format, the public key is probably not going to look the same as the one stored in the server's ~/.ssh/authorized_keys file.

PEM format keys look like this:


SSH Public Keys look like this:

ssh-rsa AAAAB3N...voZypjC/Y2UFwJie...t20Ih7

PGP Public Keys look like this:



So, make sure you are comparing keys in the same format.


The known_hosts is from the server's sshd key - in /etc/ssh/*pub


The authorized_keys file should have a line containing the contents of id_rsa.pub, and the known_hosts file should have a line containing the server's host key. (The server usually stores its host keys in a file under /etc/ssh/.)

Also, id_rsa should kind of match id_rsa.pub in the sense that they need to be a key pair, but unless you mangle it manually, that's how ssh-keygen always places them.

  • I did not have an id_rsa.pub so I generated a public key using openssl rsa -in mykey.pem -pubout
    – user30994
    Nov 27, 2018 at 8:26
  • @user30994 Hmm? Your question clearly lists your id_rsa.pub with a matching id_rsa?
    – Bass
    Nov 27, 2018 at 8:34
  • I presume it is a paired public key as I generated it from the private key that is stored in id_rsa. Is there a way to confirm if the public key is matching with the private key?
    – user30994
    Nov 27, 2018 at 10:19
  • @user30994 ... You used openssl to create a public key from a private key. However, ssh usually doesn't generate PEM format keys by default. So, you may have better luck finding your "match" by comparing the PEM public key in ssh format ... ssh-keygen -i -m pem -f id_rsa.pem ... Please add your key generation process to your question Nov 28, 2018 at 3:04
  • @RubberStamp: ssh-keygen mostly did create OpenSSL-style ('legacy') PEM private key files except for 7.8 up (released 3 months ago and not yet widespread), or ed25519 or -o since 6.5 in 2014. But the public key format used by OpenSSH has always been totally different from the OpenSSL format, so always need(ed) ssh-keygen -y -f private to generate OpenSSH public key. Nov 28, 2018 at 8:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.