Multiple authentications from SSH keys

When you start to have a lot of servers to administer, SSH keys multiply. Indeed even if, as a general rule, the same key is used to authenticate on different machines, it is sometimes necessary to use other keys. Either connect with a different user account on the same device physically because we use several types of keys or because we want to avoid a single key allowing access to several machines.

You will tell me that you can choose which key to use using ssh -i option, that's true, but like any good developer I'm a bit lazy, and if the machine can do it at my place, why bother me?

It is, therefore possible, to use the file, ~/.ssh/config to indicate to the SSH Keys client which key it should use to connect and to which machine.

This way our SSH client will always use the key attached to a particular host. The directive allows you to specify

an alternative name, it also accepts an IP.

It is quite possible to specify multiple hostnames for the "Host" directive; these, in this case, must be separated

by spaces. Likewise, a wildcard can be entered in the event that several machines share the same domain.

Very practical when you have a complete fleet to manage. There are a number of pretty impressive directives

out there, so for more information, I recommend doing a little man ssh_config.

Example of a host configured with a wildcard:

1) Host *.domain.tld

2) HostName mon-alias

3) User guewen

4) IdentityFile ~/.ssh/ma-clé-ssh

First impressions

This operating mode also has advantages:

1) It does not require any exchange between our server and Vault, only between the bastion and Vault.

Which reduces the attack surface on the latter.

2) It allows controlling rather finely what the user can do or not do once connected thanks to the system of

critical options and extensions.

It uses the already existing OpenSSH functionalities on the client and on the server. On the other hand,

despite its elegance, this solution has some drawbacks, during the validity period of the certificate,

it can be used on an arbitrary number of servers that trust the Vault SSH CA as many times as the user does wish.

And these connections do not give rise to any log apart from the logs of the system itself, which therefore

becomes important to keep and centralize outside the servers.

To mitigate the very large number of machines that can be accessed with a certificate, it will be necessary

to put in place mitigations, we can mention two:

1) Set up different CAs for different sets of servers. This is done by activating the SSH keys Secret

Engine several times on different paths which will therefore have separate CA keys.

2) Set up separate user names for each machine or group of machines. So if a role only allows connection

with the “web.webserver” user who only exists on web servers, then he will only have access to web servers.