+++
author = "Yann Verry"
categories = ["security"]
date = 2019-03-21T21:09:11Z
description = ""
draft = false
image = "__GHOST_URL__/content/images/2019/03/1188551383_fbd414077a_o.jpg"
slug = "vault-ssh"
tags = ["security"]
title = "Vault SSH"

+++


Nous allons explorer une fonctionnalité de [vault](https://www.vaultproject.io/) trop peu utilisé qui pourtant résous enfin le problème de déploiement et révocation des clés SSH sur les serveurs.

Tout d'abord cela commence par la génération d'une CA SSH qu'on pousse sur chaque serveurs, on ajoute la ligne magique dans sshd_config :

> TrustedUserCAKeys <path certificate>

Pour réaliser cela l'authentification SSH s'éffectue avec un certificat et vault sign la clé publique pour une durée réduite, de 30minutes à disons 12heures.

Exemple:

> ➜  ~ ssh ns2.verry.orgReceived disconnect from 2a0b:cbc0:110d:1::1e port 22:2: Too many authentication failuresDisconnected from 2a0b:cbc0:110d:1::1e port 22

Il est donc impossible de se connecter au serveur, je demande donc à vault de signer à nouveau ma clé ed25519:

> ➜  ~ vault write -field=signed_key ssh-client-signer/sign/ssh-yverry public_key=@$HOME/.ssh/id_ed25519.pub > $HOME/.ssh/id_ed25519-cert.pub

Vault sign donc ma clé public fourni dans public_key, le serveur sshd vérifie que la signature est conforme et valide dans le temp. Je peux donc me connecter sur le serveur:

> ➜  ~ ssh ns2.verry.orgWelcome to Ubuntu 18.04.2 LTS (GNU/Linux 4.15.0-46-generic x86_64)

## Conclusion

Grâce à vault plus de besoin particulier pour déployer la clé de chaque personne sur chaque serveur dès son arrivé dans vos équipes de sysadmin, il suffit juste d'une policies vault et le tour est joué !

Une personne quitte votre équipe ? Aucun problème avec des signatures courte et la révocation de son accès à vault plus aucun accès n'est possible.

J'ai volontairement passé beaucoup d'étape car le but n'est pas de réinventer la documentation déjà [fourni](https://www.vaultproject.io/docs/secrets/ssh/signed-ssh-certificates.html)

