LinuxQuestions.org - Understanding server ssh keys

- Linux - Newbie (https://www.linuxquestions.org/questions/linux-newbie-8/)

- - Understanding server ssh keys (https://www.linuxquestions.org/questions/linux-newbie-8/understanding-server-ssh-keys-4175606967/)

Understanding server ssh keys

Trying to better understand server ssh keys, and have a few questions.

It is my understanding that all the ssh_host_* key pairs all perform the same function to allow ssh between two machines but use different algorithms. Correct?
EDIT. Actually, it seems that ssh_host_rsa_key and ssh_host_dsa_key are used in conjunction for ssh2, right?
How do the two machines determine which one to use?
Why is the private key for ssh_host_key the only one that is encrypted?
Why isn't ssh_host_key on all systems? I have a Raspberry Pi 2 which doesn't have one and a Raspberry Pi 3 which does.
Why is the user who initially created the keys displayed in the public key?
Is the algorithm for private keys determined by the filename (i.e. ssh_host_dsa_key), or their deliminator (i.e. -----BEGIN DSA PRIVATE KEY----- and -----END DSA PRIVATE KEY----- )?
Confirm the algorithms for public keys are known not by the file name but by content in the string (i.e. ssh-dss for ssh_host_dsa_key.pub).
Please confirm that there is no information included in these public and private keys other than the user which created them, the algorithm, and of course the random hashes. Or in other words, they are not tied to a host name or IP or anything.
Please confirm that if one key pair is regenerated, there is no need to regenerate another.
What are the implications of having two machines with the same keys?
I accidentally deleted my ssh_host_rsa_key key. Why is the -N flag needed (ssh-keygen -f /etc/ssh/ssh_host_rsa_key -N '' -t rsa)? No need to regenerate my ssh_host_rsa_key keys, right?

Thank you

Code:

michael@pi:/etc/ssh $ ls -l

total 288

-rw-r--r-- 1 root root 242091 Jul 24  2016 moduli

-rw-r--r-- 1 root root  1690 Jul 24  2016 ssh_config

-rw-r--r-- 1 root root  2541 Mar  3 15:31 sshd_config

-rw------- 1 root root    668 Apr  2 10:52 ssh_host_dsa_key

-rw-r--r-- 1 root root    606 Apr  2 10:52 ssh_host_dsa_key.pub

-rw------- 1 root root    227 Apr  2 10:52 ssh_host_ecdsa_key

-rw-r--r-- 1 root root    178 Apr  2 10:52 ssh_host_ecdsa_key.pub

-rw------- 1 root root    411 Apr  2 10:52 ssh_host_ed25519_key

-rw-r--r-- 1 root root    98 Apr  2 10:52 ssh_host_ed25519_key.pub

-rw------- 1 root root    981 Mar  3 16:18 ssh_host_key

-rw-r--r-- 1 root root    646 Mar  3 16:18 ssh_host_key.pub

-rw------- 1 root root  1675 May 30 13:03 ssh_host_rsa_key

-rw-r--r-- 1 root root    398 May 30 13:03 ssh_host_rsa_key.pub

michael@pi:/etc/ssh $ ssh-keygen -l -f ssh_host_dsa_key.pub

1024 fc:3c:7e:e0:9a:d3:3d:c9:c3:07:cc:ad:a6:e3:9f:ba ssh_host_dsa_key.pub (DSA)

michael@pi:/etc/ssh $ ssh-keygen -l -f ssh_host_ecdsa_key.pub

256 b4:98:7e:61:f7:a5:c1:2a:1d:05:c1:c2:00:e7:0a:d9 ssh_host_ecdsa_key.pub (ECDSA)

michael@pi:/etc/ssh $ ssh-keygen -l -f ssh_host_ed25519_key.pub

256 7e:07:e3:9b:a9:7b:4f:8a:87:74:ab:44:81:df:e0:1c ssh_host_ed25519_key.pub (ED25519)

michael@pi:/etc/ssh $ ssh-keygen -l -f ssh_host_key.pub

2048 f7:1e:d6:67:38:36:c2:60:35:4d:31:27:2a:8a:80:f6 root@raspberrypi (RSA1)

michael@pi:/etc/ssh $ ssh-keygen -l -f ssh_host_rsa_key.pub

2048 94:21:d2:fc:70:2d:8d:bb:71:30:0f:4d:52:49:01:43 ssh_host_rsa_key.pub (RSA)

michael@pi:/etc/ssh $

#10 is a bad idea.

#11 -N is allowing you to specify a (new) passphrase.
Personally, I don't use any passphrases - maybe some people would have issues with this???

Don't use the default port 22 for ssh.

Quote:

Originally Posted by JeremyBoden (Post 5716985)

#10 I figured so much, but why? Also, if I create an iso of my installation, and then install it on a different machine, they will have the same keys, right?

#11 I accidentally read the MAN incorrectly, and thought it had something ports. Sorry.

Essentially, if you put your private key on multiple machines, you lose security.
Your host is going to get confused about the client machine and can't be warned that someone appears to have seized control of your private key.

Why not write a script to setup your SSH keys after the install?

The reason I originally started looking into this is to find a way to ssh into a host which is located behind a firewall where the firewall doesn't allow incoming communication. To do so, on the machine behind the firewall, I would do the following:

Code:

ssh -R 2222:localhost:22 sshtunnel@192.168.1.10

Then on the machine behind the firewall, would do this:

Code:

ssh -p 2222 sshtunnel@localhost

But then, if I have user sshtunnel on two machines, and try to do the second above command, I will get a key changed error unless the ssh host keys are the same.

If you want to have an incoming connection, surely you need to allow an incoming communication of some kind?
You would want a host that doesn't allow incoming connections to actually not allow incoming connections!! :twocents:

For example, you could open port 2222 for SSH communication from just your list of approved devices....
(More ingenious packet blocking strategies are possible).

Quote:

Originally Posted by JeremyBoden (Post 5717036)

If you want to have an incoming connection, surely you need to allow an incoming communication of some kind?

No you don't. Kind of scary, isn't it. The two lines I showed will allow incoming communication if the firewall is configured to allow no incoming initiating communication and only outgoing communication on port 2222.

Quote:

Originally Posted by NotionCommotion (Post 5716973)

Trying to better understand server ssh keys, and have a few questions.

It is my understanding that all the ssh_host_* key pairs all perform the same function to allow ssh between two machines but use different algorithms. Correct?
EDIT. Actually, it seems that ssh_host_rsa_key and ssh_host_dsa_key are used in conjunction for ssh2, right?

If these are the SSH server's keys you are writing about, they are found in /etc/ssh/ssh_host_*_key. They are used by the server to identify itself to the client when it connects. The client queries the server for one of these keys and then verifies it with the help of the public key stored locally in ~/.ssh/known_hosts or the designated equivalent.

Quote:

Originally Posted by NotionCommotion (Post 5716973)

Trying to better understand server ssh keys, and have a few questions.

How do the two machines determine which one to use?

The client asks for one. Depending on the version of the client, one algorithm will be prioritized over another unless a public key alread exists in ~/.ssh/known_hosts or the designated alternative.

You can retrieve a server's public key(s) manually using ssh-keyscan

If a training language is easier to read than C, you can check this project to see the actual process the client uses to verify the server's authenticity:
https://karla.io/2016/04/30/ssh-for-fun-and-profit.html

Quote:

Originally Posted by NotionCommotion (Post 5716973)

Trying to better understand server ssh keys, and have a few questions.

Why is the private key for ssh_host_key the only one that is encrypted?

If you are talking about the server's private key, that is not encrypted.

If you are talking about the private keys that you are keepig on your client, only the private key is considered a secret. The public key is, well, public information.

Quote:

Originally Posted by NotionCommotion (Post 5716973)

Trying to better understand server ssh keys, and have a few questions.

Why isn't ssh_host_key on all systems? I have a Raspberry Pi 2 which doesn't have one and a Raspberry Pi 3 which does.

Can you elaborate in more detail? Are you writing about a server key pair or a client key pair?

Quote:

Originally Posted by NotionCommotion (Post 5716973)

Trying to better understand server ssh keys, and have a few questions.

Why is the user who initially created the keys displayed in the public key?

That's because you forgot to add a comment using the -C option when making the key. You can add it in manually or with ssh-keygen

See "man ssh-keygen"

Quote:

Originally Posted by NotionCommotion (Post 5716973)

Trying to better understand server ssh keys, and have a few questions.

Is the algorithm for private keys determined by the filename (i.e. ssh_host_dsa_key), or their deliminator (i.e. -----BEGIN DSA PRIVATE KEY----- and -----END DSA PRIVATE KEY----- )?

Neither. The algorithm is determined by the options you provide ssh-keygen at the moment you create the key pair.
But as far as identifiying an exiting key goes, it is done by the "delimter" as you call it.

If you have the source for OpenSSH-portable, look in the file named PROTOCOL.key for the details.

Quote:

Originally Posted by NotionCommotion (Post 5716973)

Trying to better understand server ssh keys, and have a few questions.

Confirm the algorithms for public keys are known not by the file name but by content in the string (i.e. ssh-dss for ssh_host_dsa_key.pub).

Yes, that field identifies the algorithm used by that public key.

Quote:

Originally Posted by NotionCommotion (Post 5716973)

Trying to better understand server ssh keys, and have a few questions.

Please confirm that there is no information included in these public and private keys other than the user which created them, the algorithm, and of course the random hashes. Or in other words, they are not tied to a host name or IP or anything.

The private key has only the private key, plus maybe some metadata describing the encryption method if the private key was created with a pass phrased.

The public key has whatever restrictions and comments you did or didn't add. See the manual page "man sshd" in the section "AUTHORIZED_KEYS FILE FORMAT" for your full set of options.

Quote:

Originally Posted by NotionCommotion (Post 5716973)

Trying to better understand server ssh keys, and have a few questions.

Please confirm that if one key pair is regenerated, there is no need to regenerate another.

Regenerated? Which kind of key pair, a client key pair or a pair for the server?

Quote:

Originally Posted by NotionCommotion (Post 5716973)

Trying to better understand server ssh keys, and have a few questions.

I accidentally deleted my ssh_host_rsa_key key. Why is the -N flag needed (ssh-keygen -f /etc/ssh/ssh_host_rsa_key -N '' -t rsa)? No need to regenerate my ssh_host_rsa_key keys, right?

It's not actually needed. You can enter an empty pass phrase manually if you like. The -N is just there so you skip that step.

Thanks Turbocapitalist,

These keys have always been a mystery to me, however, spending a little time learning about them has really helped.

Maybe "encrypted" was not the right world, but it is definitely not text. The ssh_host_key/ssh_host_key.pub pair is only on one of the devices (not pi2). Is ssh_host_key a client key, and are client keys stored in the same /etc/ssh directory? If so, I don't recall what I might have done to gain this client key.

Quote:

Me:
Why is the private key for ssh_host_key the only one that is encrypted?

You:
If you are talking about the server's private key, that is not encrypted.
If you are talking about the private keys that you are keepig on your client, only the private key is considered a secret. The public key is, well, public information.

Quote:

Me:
Why isn't ssh_host_key on all systems? I have a Raspberry Pi 2 which doesn't have one and a Raspberry Pi 3 which does.

You:
Can you elaborate in more detail? Are you writing about a server key pair or a client key pair?

Code:

michael@pi2:/etc/ssh $ ls -l

total 280

-rw-r--r-- 1 root root 242091 Jul 24  2016 moduli

-rw-r--r-- 1 root root  1690 Jul 24  2016 ssh_config

-rw-r--r-- 1 root root  2541 Sep 23  2016 sshd_config

-rw------- 1 root root    668 Sep 23  2016 ssh_host_dsa_key

-rw-r--r-- 1 root root    606 Sep 23  2016 ssh_host_dsa_key.pub

-rw------- 1 root root    227 Sep 23  2016 ssh_host_ecdsa_key

-rw-r--r-- 1 root root    178 Sep 23  2016 ssh_host_ecdsa_key.pub

-rw------- 1 root root    411 Sep 23  2016 ssh_host_ed25519_key

-rw-r--r-- 1 root root    98 Sep 23  2016 ssh_host_ed25519_key.pub

-rw------- 1 root root  1675 Sep 23  2016 ssh_host_rsa_key

-rw-r--r-- 1 root root    398 Sep 23  2016 ssh_host_rsa_key.pub

michael@pi2:/etc/ssh $

Code:

michael@pi:/etc/ssh $ ls -l

total 288

-rw-r--r-- 1 root root 242091 Jul 24  2016 moduli

-rw-r--r-- 1 root root  1690 Jul 24  2016 ssh_config

-rw-r--r-- 1 root root  2541 Mar  3 15:31 sshd_config

-rw------- 1 root root    668 Apr  2 10:52 ssh_host_dsa_key

-rw-r--r-- 1 root root    606 Apr  2 10:52 ssh_host_dsa_key.pub

-rw------- 1 root root    227 Apr  2 10:52 ssh_host_ecdsa_key

-rw-r--r-- 1 root root    178 Apr  2 10:52 ssh_host_ecdsa_key.pub

-rw------- 1 root root    411 Apr  2 10:52 ssh_host_ed25519_key

-rw-r--r-- 1 root root    98 Apr  2 10:52 ssh_host_ed25519_key.pub

-rw------- 1 root root    981 Mar  3 16:18 ssh_host_key

-rw-r--r-- 1 root root    646 Mar  3 16:18 ssh_host_key.pub

-rw------- 1 root root  1675 May 30 13:03 ssh_host_rsa_key

-rw-r--r-- 1 root root    398 May 30 13:03 ssh_host_rsa_key.pub

michael@pi:/etc/ssh $ sudo cat ssh_host_key

[sudo] password for michael:

SSH PRIVATE KEY FILE FORMAT 1.1                                                                                                                                                                                                            ▒▒▒▒▒uX?▒;▒▒▒E▒▒-)h▒I▒▒▒L▒▒▒▒sЀ̔j78GO#G▒3ߞ ▒▒L>▒b



▒5▒x▒

▒▒▒H %▒)▒98▒5▒X▒▒9▒▒Iq侑▒T▒0▒

                            ▒▒qek▒▒E▒

,▒▒▒ٍy▒▒8pF▒5▒▒▒▒H6▒0xC▒#▒▒˗▒k!ژ▒▒▒▒▒W▒▒▒5▒On4▒▒3▒▒d3.`۪▒▒FN+▒YK▒=▒O▒▒▒1~#4C▒/x▒▒3,˕▒c¹9~>▒ޓR▒▒▒t;▒\`▒▒{▒̬▒root@raspberrypi▒q▒q▒"fnÉ?▒H▒[

▒Z▒֎|jZJ▒▒W▒▒▒_N▒▒▒kd▒▒핻O▒▒▒▒▒M7ct▒▒▒C▒▒Z▒ֹ▒ǞO▒▒%▒˯Xm%▒▒3j▒▒]i▒▒▒▒▒/&w▒

▒QA▒▒I▒|▒ͷ▒▒N▒▒▒z▒7▒▒▒▒q▒▒▒A▒x▒;▒▒▒jÎ▒5▒a▒▒▒▒[^? ▒tIx▒▒*▒>▒+p▒▒▒IR▒q▒9B▒        ▒▒@▒|▒▒T▒̅▒▒;▒▒J▒▒(▒}K▒^i▒2▒▒ȻV▒r▒c▒q▒k▒▒▒-▒

▒v▒6{W▒y▒▒▒P,▒▒i1▒ǭ

              ▒▒▒j▒VY1▒▒▒▒▒▒[▒H/▒▒9C▒▒){Z:y'f▒▒F#/է▒▒8.▒▒▒!▒▒،▒▒▒P▒▒1>FVN▒▒▒ ▒XT&▒^3%▒�▒▒▒▒0qDb▒▒▒▒▒ܜP▒▒r▒>Sk▒▒5i}▒$▒▒▒~▒[▒▒c▒iV7▒@▒

^▒ $▒F▒o▒o^jj▒▒▒13▒▒▒▒`A▒m▒▒Ҿ^d▒:▒?U

▒6▒▒A,▒▒E▒▒▒>D▒▒]▒؅Ɯ▒o▒r_f▒Q▒▒]▒i*▒E&9▒=▒▒!▒▒▒PuTTYPuTTYPuTTYPuTTYmichael@pi:/etc/ssh $ PuTTYPuTTYPuTTYPuTTY^C

michael@pi:/etc/ssh $

Hmm. That's not part of any key normally generated or used by OpenSSH. Furthermore, it appears to be some kind of binary. Perhaps you can see what the file utility has to say about identifying it:

Code:

file /etc/ssh/ssh_host_key

Or if you are on an APT-based distro, try tracking its package down:

Code:

dpkg -S /etc/ssh/ssh_host_key

The files normally seen in /etc/ssh/ are :

/etc/ssh/ssh_host_ecdsa_key
/etc/ssh/ssh_host_ed25519_key
/etc/ssh/ssh_host_rsa_key

and, on outdated systems also:

/etc/ssh/ssh_host_dsa_key

Quote:

Originally Posted by Turbocapitalist (Post 5717484)

Hmm. That's not part of any key normally generated or used by OpenSSH. Furthermore, it appears to be some kind of binary. Perhaps you can see what the file utility has to say about identifying it:

Code:

file /etc/ssh/ssh_host_key

...

The files normally seen in /etc/ssh/ are :

/etc/ssh/ssh_host_ecdsa_key
/etc/ssh/ssh_host_ed25519_key
/etc/ssh/ssh_host_rsa_key

...

Code:

michael@pi:~ $ sudo file /etc/ssh/ssh_host_key

/etc/ssh/ssh_host_key: OpenSSH RSA1 private key, version 1.1

michael@pi:~ $

Please see my previous post for the keys I show in this folder.

Quote:

Originally Posted by NotionCommotion (Post 5717491)

Code:

michael@pi:~ $ sudo file /etc/ssh/ssh_host_key

/etc/ssh/ssh_host_key: OpenSSH RSA1 private key, version 1.1

michael@pi:~ $

Please see my previous post for the keys I show in this folder.

That's really old. You should find a way to remove use of it. Which version of OpenSSH is running on that machine?

I hope it is set to use only protocol 2:

Code:

$ sudo grep -i '^protocol' /etc/ssh/sshd_config

Protocol 2

Yes, protocol 2.

That's really old or really odd? Hope just old!

How do I determine if anything is using it? Should I just delete them?

Here are a few answers to a few of the OP questions . . .

(1) Host keys / User keys:
(good explanation here) When two parties want to communicate securely, both parties must possess a means of identifying each other. Not only does the host machine need to verify that you are authorized to access it, but your machine must be able to verify that it is talking to the expected host. When you connect to a server for the first time, you'll be presented with that key and must approve it. You'll subsequently be notified if the host key changes.

All keys are pairs, with a private (secret ...) key, and a public (not-secret ...) key that can only be generated by a possessor of the (secret) private key.

- - -
(2) The Need for Uniqueness:
In any public-key cryptosystem, the private key should always be distinct. In this way, it uniquely identifies a particular user, or a particular machine. There should be no other extant copies of any machine's private key, except securely upon that machine.

- - -
(3) Key Content / Identifying Keys:
As you see, each key file begins (and maybe, ends) with a human-readable identifier. It is this identifier which cues the system as to what to expect. But, if anything is "out of the ordinary," the software will detect it and raise an alarm.

Within their content, keys contain not only "key material" but also certain "metadata." The metadata is only for descriptive purposes, to assist in identifying and managing the file. Furthermore, both the key material and the metadata are protected from alteration, so you can always be confident that the metadata has not been altered and that it is the correct metadata for the accompanying key material.