Using one user certificate and one server certificate for an entire LAN

[rhk]

For purposes of this question, consider a LAN with 7 computers: 3 client machines, 3 server machines, 1 CA machine, and 3 users who might use any of the client machines to ssh to any of the server machines. (And, at least initially, I'm not concerned with ssh'ing in or out of the LAN to any "external" computer.)

1. I've read and/or received hints from a variety of sources that I can use one user certificate and one server certificate on such a LAN to authenticate ssh between any user on any client machine and any server on that LAN -- can someone confirm that?

Follow-up questions -- for the following I'm going to ask about user certificates -- if I get these answers for user certificates, I believe I can "extrapolate" them to server / host certificates.

(Aside -- reminding myself: user certificates are created by signing the public key of a user public keypair using the private key of the user CA keypair. Thus, with respect to user certificates, somewhere I must have at least one user keypair and one user CA keypair to create the user certificate.

2. To use one user certificate to allow any user on any client machine to access any server, I'm quite sure that I'd have to copy that user certificate to each client machine?

3. Also, to do that (to use one user certificate to allow any user on any client machine to access any server), would I also have to copy the user private key from the client machine from / on which I created the user certificate to each of the other client machines?

Note: I recognize that copying private keys to another machine is a security risk -- for the moment, for the purpose of learning, I don't want to consider that.

Aside: I recognize that I can limit which users can use a certificate by specifying users (principals) with the -n option when I create a user certificate.

Thanks!

 

[VladiBG]

ssh doesn't use certificates it use key-pairs for user authentication.

The public key is stored on the ssh server inside each user home directory in ~/.ssh/authorized_keys with user:wheel 600 permission
The private key is also know as identity file it can be stored anywhere on the client machine usually in ~/.ssh/id_rsa or it can be specified when connecting to ssh server using "-i" like ssh user@hostname -i /home/user/my_id.key

I would not recommend to have same private key shared between multiple users because it will allow users to log in as other user.

The host ident itself using HostKey in /etc/ssh/ssh_host_rsa_key which is generated upon first start of the sshd if it's missing. And then trusted by each client on the first connect.

 

[rhk]

ssh doesn't use certificates it use key-pairs for user authentication.

The public key is stored on the ssh server inside each user home directory in ~/.ssh/authorized_keys with user:wheel 600 permission
The private key is also know as identity file it can be stored anywhere on the client machine usually in ~/.ssh/id_rsa or it can be specified when connecting to ssh server using "-i" like ssh user@hostname -i /home/user/my_id.key

I would not recommend to have same private key shared between multiple users because it will allow users to log in as other user.

The host ident itself using HostKey in /etc/ssh/ssh_host_rsa_key which is generated upon first start of the sshd if it's missing. And then trusted by each client on the first connect.

Actually, ssh does use certificates. It does not use the same certificates as ssl (and maybe tls?).

From (an older version of) man ssh (because I'm using older versions of ssh):

<quote>
A variation on public key authentication is available in the form of certificate authentication: instead of a set of public/private keys, signed certificates are used. This has the advantage that a single trusted certification authority can be used in place of many public/private keys. See the CERTIFICATES section of ssh-keygen(1) for more information.
</quote>

What you are discussing is public key authentication.

 

[_al]

As for PKI, there certificates are issued not not for a computer, but for a person. That is, each user has his own certificate. The key pair is generated on a special workstation and stored in a key container in a token or on a smart card. The public key is sent to the CA, where it is signed, and the self-signed CA certificate is added to the signature, which is also stored in the key container. This is how the user's key pair and public key certificate is generated. After that, the user can enter the system from any computer by connecting (through a reader) his token/smart card. In systems where smart cards are not used, it is necessary to copy user's key containers to each client computer (or generate a new key pair for each user on each computer, which is expensive). This is done by the cryptoprovider software (copy containers to something like REGISTRY, for example).

Edit: An example of a simple case of using key pairs is gpg/pgp - in mail programs, for example, such as thunderbird - for sign/verify, encrypt/decrypt (but there is no on-line authentication here).

Edit2: Strictly speaking, public key certificates can be stored not in a cryptocontainer, but simply in the public domain. The requirements for storage in a cryptocontainer are imposed only on key pairs containing a private key.

 

[VladiBG]

What is ssh-keygen & How to Use It to Generate a New SSH Key?

Ssh-keygen is a tool for creating new authentication key pairs for SSH. Such key pairs are used for automating logins, single sign-on, and for authenticating hosts.

www.ssh.com

OpenSSH does not support X.509 certificates. Tectia SSH does support them. X.509 certificates are widely used in larger organizations for making it easy to change host keys on a period basis while avoiding unnecessary warnings from clients. They also allow using strict host key checking, which means that the clients will outright refuse a connection if the host key has changed.

 

[rhk]

OpenSSH does not support X.509 certificates.

I couldn't remember the X.509 designation, but that is what I was trying to say -- (open)ssh does not support ssl/tls (X.509, iiuc) certificates, but it does support certificates.

Andrey Lanin's answer is more on point, and after I read it a few more times, I may recognize that it answers at least some of my questions -- maybe all.

 

[rhk]

As for PKI, there certificates are issued not not for a computer, but for a person. That is, each user has his own certificate. The key pair is generated on a special workstation and stored in a key container in a token or on a smart card. The public key is sent to the CA, where it is signed, and the self-signed CA certificate is added to the signature, which is also stored in the key container. This is how the user's key pair and public key certificate is generated. After that, the user can enter the system from any computer by connecting (through a reader) his token/smart card. In systems where smart cards are not used, it is necessary to copy user's key containers to each client computer (or generate a new key pair for each user on each computer, which is expensive). This is done by the cryptoprovider software (copy containers to something like REGISTRY, for example).

Edit: An example of a simple case of using key pairs is gpg/pgp - in mail programs, for example, such as thunderbird - for sign/verify, encrypt/decrypt (but there is no on-line authentication here).

I haven't thoroughly absorbed this answer, but it doesn't sound directly applicable to ssh certificates.

IIUC, an ssh user certificate can be used by all users unless limited with the -n option.

Thus, your statement that "it is necessary to copy user's key containers to each client computer" makes me infer that although I might use one ssh user certificate for all users, if I copy the certificate and the "signature" (which I understand to mean the private user key) to each client computer, I should be able to use that one user certificate for all users.

It sure would be nice to get an answer from someone who has real experience with ssh certificates. ;-)

 

[_al]

... the "signature" (which I understand to mean the private user key) ...

A 'signature' is the result of applying a cryptographic algorithm to open data. As a rule, the data is hashed first, and then the transformation is performed using the private key. The public key (if it has the appropriate property specified) can be used to encrypt data.

 

[Jose]

1. I've read and/or received hints from a variety of sources that I can use one user certificate and one server certificate on such a LAN to authenticate ssh between any user on any client machine and any server on that LAN -- can someone confirm that?

This does appear to be the case, but I have not tried it myself.

(Aside -- reminding myself: user certificates are created by signing the public key of a user public keypair using the private key of the user CA keypair. Thus, with respect to user certificates, somewhere I must have at least one user keypair and one user CA keypair to create the user certificate.

I don't follow. You only need one CA. You can use it for both host and user certificates. At this level of abstraction, hosts and users are the same thing. They're both "principals".

2. To use one user certificate to allow any user on any client machine to access any server, I'm quite sure that I'd have to copy that user certificate to each client machine?

Yup. Certificates are meant to be published. They have no secrets in them by design.

3. Also, to do that (to use one user certificate to allow any user on any client machine to access any server), would I also have to copy the user private key from the client machine from / on which I created the user certificate to each of the other client machines?

Yes. The certificate is the public key part. You need to prove that you have the private key part by encrypting something (a nonce) that can only be decrypted with the public key in the certificate you present.

Note: I recognize that copying private keys to another machine is a security risk -- for the moment, for the purpose of learning, I don't want to consider that.

I don't see why this is a big deal. It is regularly done every time you use PKI for SSH authentication. You'll have to look at Kerberos if you want to never, ever send secrets across a network. It has other downsides.

OpenSSH does not support X.509 certificates.

So what? X.509 certs are riddled with X.500 legacy BS. The Openssh folks appear to have re-implemented all the good parts down to a Key Revocation List.

Tectia SSH does support them.

Neat-o! I wonder if they're selling something? Turns out they are! "Contact us for pricing." Sounds expensive.

To be fair, I can see the value in re-using an existing X.509 certificate management infrastructure. However, only large organizations are likely to have such an existing infra. rhk clearly defined his small network use case.