I have two files, id_rsa
and id_rsa.pub
. What command can be used to validate if they are a valid pair?

- 2,318
- 5
- 23
- 24

- 5,831
- 24
- 72
- 91
-
I'll confirm Michuelnik's answer; it saved me from having to make a new key pair, thanks. `ssh -v` helps a lot too. – Krista K Dec 30 '13 at 05:06
5 Answers
I would prefer the ssh-keygen -y -e -f <private key>
way instead of the accepted answer of How do you test a public/private DSA keypair? on Stack Overflow.
ssh-keygen -y -e -f <private key>
takes a private key and prints the corresponding public key which can be directly compared to your available public keys. (Hint: beware of comments or key-options.)
(How the hell is it doing that? I can only hope the public key is encoded directly or indirectly in the private key...)
I needed this myself and used the following Bash one-liner. It should output nothing if the keys belong together. Apply a little -q
to the diff in scripts and diff only sets the return code appropriately.
PRIVKEY=id_rsa
TESTKEY=id_rsa.pub
diff <( ssh-keygen -y -e -f "$PRIVKEY" ) <( ssh-keygen -y -e -f "$TESTKEY" )

- 2,318
- 5
- 23
- 24

- 3,410
- 3
- 19
- 24
-
5"How the hell is it doing that".. The private key is generated from randomness so we all have a unique key. If you apply the repeatable one-way RSA algorithm on this private key, youll get the unique public key. There is no algorithm that you can perform on the public key thatll get a unique private key. – Sirch Sep 24 '13 at 14:29
-
1@Sirch: I thought the decision which key is private and which one is public is pure random since the two keys are equal. What one key encrypts can only be decrypted with the other. And if one key could be obtained from the other this all would not work out. – Michuelnik Sep 25 '13 at 11:42
-
3@Michuelnik You can derive the public key from the private key. You cant derive the private key from the public key. Were not talking about the material that it encrypts. – Sirch Sep 25 '13 at 13:35
-
-
1@Michuelnik imho, the question is off topic on SO and on-topic here (and/or Superuser). imho, it shouldn't be marked as duplicate and instead flagged there for migration. But it's covered on both so I like the more complete sharing of information. – Krista K Dec 30 '13 at 20:39
-
The cited question states to use OpenSSL commands. Unfortunately, those commands ***don't*** call their own relevant APIs, like `DSA_check` and `RSA_check`. The commands just parse and print. And if you check the return value from the `openssl dsa ...`, you will find that it returns 1, which is failure. – Sep 30 '14 at 01:01
-
22As long as id_rsa.pub exists, `ssh-keygen -y -e -f id_rsa` will not check id_rsa at all but just return the value from id_rsa.pub. So e.g. if you `echo 5 > id_rsa` to erase the private key, then do the diff, the diff will pass! Also, running `ssh-keygen -yef foo` where foo is not a valid key (and has no corresponding foo.pub) will block waiting for user input, so be careful using this in a script. – Jul 10 '15 at 22:45
-
Regarding your comment about them being the same. They are not. The public key is sufficient to encrypt the message, but insufficent to decrypt the message. Its security relies on the fact that if you take very large primes p and q and multiply them together to get n=pq, you can release n publicly and it is currently computationally infeasible for the attacker to be able to find p and q solely knowing n. If he can find p and q then the attacker can decrpyt the message. It is motivated by Euler's Theorem (Lagrange's theorem on the ring of integers modulo n).... – David Reed Oct 05 '22 at 17:13
-
... This solves the problem of two computers who have never met, and thus never having had an opportunity to agree on a secret key, being able to encrypt their comms over a public channel. The person receving encrypted data can thus make the encryption key publicly known, and have the encrypted response likewise be publicly known, and additionally have the public know exactly how the encrypted message was obtained from the encryption key, but still not be able to decrypt it. The decryption key is "hidden" inside the encryption key, Shor's algorithm in quantum computing will likely end RSA. – David Reed Oct 05 '22 at 17:17
Depending on where you get the public key file you are testing, the accepted answer may give false positive results. This is because of the behavior described in the comment by @drewbenn. Specifically, when the -e option is used with the private key file as the -f option parameter, it simply parrots (but reformats) what's in the associated public key file.
In other words,
ssh-keygen -y -f id_rsa
(apparently) generates the public key value, and
ssh-keygen -y -e -f id_rsa
simply and outputs (and reformats) the key in the existing id_rsa.pub whatever it is.
In my case, I have to verify that the pair has not been corrupted. So, I decided to compare the following:
ssh-keygen -y -f id_rsa | cut -d' ' -f 2
with
cut -d' ' -f 2 id_rsa.pub
Therefore:
diff <(cut -d' ' -f 2 id_rsa.pub) <(ssh-keygen -y -f id_rsa | cut -d' ' -f 2)
Perhaps this is not as flexible, but it is better for my needs. Maybe it helps someone else.

- 173
- 1
- 11

- 881
- 6
- 3
-
8This really should replace the accepted answer or at least surpass it in terms of upvotes. – thomanski Oct 05 '16 at 15:01
-
4Thank you! This command doesn't work with keys with a passphrase, it doesn't ask that interactively. I extracted the two () command contents to files and diff-ed them, that works. – Yaroslav Nikitenko Oct 18 '19 at 10:10
-
1@YaroslavNikitenko - I had the same problem. The answer by Olivier, which is similar but rearranged, removes the problem. – sancho.s ReinstateMonicaCellio Nov 26 '21 at 12:08
The easiest is to compare fingerprints as the public and private keys have the same. Visual comparison is pretty easy by putting the two commands on same line:
ssh-keygen -l -f PRIVATE_KEY; ssh-keygen -l -f PUBLIC_KEY
Programmatically, you'll want to ignore the comment portion so
diff -s <(ssh-keygen -l -f PRIVATE_KEY | cut -d' ' -f2) <(ssh-keygen -l -f PUBLIC_KEY | cut -d' ' -f2)

- 240
- 2
- 7
-
-
This holds the same limit as mentioned in the answer above: it will not calculate fingerprint from the private key if public key file exists. Instead, it will just print out the fingerprint of whatever is in public key file. Therefore, you may have public key different from private key and the test will still pass. – raspy Jun 07 '22 at 13:41
-
This CLI sequence assumes of course that the key does not require a password to decrypt. – Jason Hemann Sep 13 '22 at 23:12
If they're on your local system, stick id_rsa.pub
in your $HOME/.ssh/authorized_keys
and ssh
to localhost
using the id_rsa
key. If it works, then they match.
cat $HOME/.ssh/id_rsa.pub >> $HOME/.ssh/authorized_keys
ssh -i $HOME/.ssh/id_rsa localhost

- 244,070
- 43
- 506
- 972
-
1What if it's still prompting you for a password? Permissions of authorized_keys are correct, the public key has been copied correctly in the authorized_keys, I also did the diff mentioned in the verified answer and keys belong together. – Vasiliki Sep 30 '20 at 15:39
-
This might be a little intrusive. The answer by Olivier is not. – sancho.s ReinstateMonicaCellio Nov 26 '21 at 12:04
This is a very old thread, but I found the answers a little bit overengineered. So I just created yet another oneliner :)
[[ `ssh-keygen -yf /path/to/private_key_file` == `cat /path/to/public_key_file` ]] && echo "True" || echo "False"
There might be some edge cases because of the comments but it works fine for me since I never mess with them.
Hope it helps.
P.S.: And yes, please change that accepted answer. False positives might be problematic.

- 111
- 2