[ssh_x509] Have I understood how OpenSSH and X509 works?

ssh_x509 at roumenpetrov.info ssh_x509 at roumenpetrov.info
Sat Mar 21 12:15:18 EET 2020

Hi José,

ssh_x509 at roumenpetrov.info wrote:
> C2 - PSA Sensitive
> Hi,
> I am trying to test a connection with OpenSSH using pkixssh.
This should work . More interesting is test with commercial secsh clients or servers.

> I don't understand really how the full authentication works and specially how to create the certificates with X509 standards for public key certificates validation.
For instance X.509 standard is used browsers - https protocol. Validation is similar - based or chain for certificates: Root CA -> [Intermediate CA -> ...] client or server certificate.

> In this mail I will explain how I understand the full process I will follow to test a connection between a "client" and a "server" machine with PKIXSSH fork of OpenSSH, using X509 certificates. To make the test we will user a third machine, that we will call "control machine", machine that will act as a "Certification Authority"
> In a quick summary, and if I have correctly understood, this is how it works
> - X509 is a standard to sign this public keys. Signed public keys are considered valid if the Certification Authority is known.
Not only - process includes verification of signatures and validity of certificates in "chain".

> - We can sign public keys for hosts and users
Yes, but client or server may have different "attributes".

> - With X509 certificates we can sign in a OpenSSH server without using passwords and without using the traditional OpenSSH private-public key authentication. This means that no user public keys must be copied on destination servers.
OpenSSH does not support X.509 certificates for authentication. PKIX-SSH cleint will "down grade" automatically to "plain" keys.
The concept for public key authentication requires map between "public" part and user. Without map user with valid and acceptable X.509 certificate could login with any user account. This is not acceptable.

> - In we use X509 certificates for hosts then the client will trust the OpenSSH server without the need of manually add its public key in the known_host file.

Did you mean PKIX-SSH server and OpenSSH client. For X.509 host key PKIX-SSH will announce all supported algorithms filtered by configuration options.
Let there is no restriction on server or client side, i.e. default configuration.
Let host key is RSA with X.509 certificate.
PKIS-SSH server will announce host keys algorithms:
- x509v3-sign-rsa
- x509v3-ssh-rsa
- x509v3-rsa2048-sha256
- rsa-sha2-256
- rsa-sha2-512
- ssh-rsa
OpenSSH announce one of
- rsa-sha2-512
- rsa-sha2-256
- ssh-rsa
Algorithm rsa-sha2-512 will be accepted - first that match lists.
For simplification above sample assumes that both parties use only RSA keys and this is first connection.
In "know host" file client write record with base64 encoded public key.

In the similar case PKIX-SSH client announce one of
- x509v3-sign-rsa
- x509v3-ssh-rsa
- x509v3-rsa2048-sha256
- rsa-sha2-256
- rsa-sha2-512
- ssh-rsa
Algorithm x509v3-sign-rsa will be accepted - first that match lists.
In "know host" file client write record with certificate distinguished name.
Remark: in addition to "distinguished name" it could be based64 encoded certificate or public key.

> We are going to make two tests
> - Test the connection for an user from the client machine to the server using a X509 certificate
> - In a second step add authentication for the server host.
This is not clear - authentication is for client.

> I have arrived to the conclusion that the next steps must be followed
> - In the "control" machine:
> 	- Configure and create the keys for our test certification authority
> 	- Send the public certification authority key to the OpenSSH daemon of the "server" machine, so our CA is recognised
> - In the "client" machine:
> 	- create the private key and public key for the user
> 	- send the public key to the control machine to be signed by the c.a.
> 	- add the certificate to the private key file so it will be presented to the server

And next step is map "login(user) name <-> client certificate".

For instance in Tectia server configuration allows login name to be extracted from certificate. In this case there is no need data related to client certificate to be uploaded. Drawback is that you cannot login with different name.

PKIX-SSH server uses more traditional approach - use of "authorised keys" files and/or command. File is know and record could contain either "distinguished name" or "base64 encoded certificate" or "base64 encoded public key". With files certificate could be used to logon with different username.
Note AuthorizedKeysCommand support token %u (username) , i.e. it could be used to generate suitable "distinguished name" and to avoid data related to client certificate to be stored in "authorised keys" files.

> At this point everything should be in its place, so we could test the connection
> Have I correctly understood how it works?

My comments just precise some topics.

> Regards
> José Manuel Ciges Regueiro
> Unix Systems Administrator & LAMP developer

Roumen Petrov

More information about the ssh_x509 mailing list