Au fil du temps je me suis rendu compte que je gérais beaucoup de serveurs et surtout beaucoup de compte ssh. La bonne pratique étant de gérer l'authentification avec des clés, voici 4 astuces pour gérer ses clés qui me simplifient la vie au quotidien:

Utiliser ssh config ~/.ssh/config

créer ce fichier pour fixer une fois pour toute les user, les ip, et les clés à utiliser pour pour chaque connexion ssh

$ vi ~/.ssh/config

et ajouter pour chaque connexion un bloc de la forme

Host my.server.com
   User root
   Hostname 192.168.220.116
   IdentityFile ~/.ssh/ids/my.server.com/admin/id_rsa

vous pouvez ensuite vous connectez en tapant directement

$ ssh my.server.com

A noter qu'il existe beaucoup d'autres options ...

Utiliser les sauts ssh

Pour des besoins d'isolations de vms, certains serveurs ne peuvent pas être atteint "directement" en ssh depuis l'"extérieur". Imaginons un reverse proxy de type ngnix ou haproxy (rproxy.domain.com) sur une ip publique qui aurait également un patte dans un sous réseau non routable sur Internet (192.168.0.X).

le reverse proxy exposera les ports associés aux services présents sur chaque vm et uniquement ceux là.

Comment faire alors pour se connecter au vms en 192.168.0.X?

Une solution peu élégante consisterait à mapper le port 22 de chaque vm sur un port de l'ip publique via le reverse proxy: chaque vms aurait donc un port spécifique pour s'y connecter en ssh ...

Une solution plus élégante et plus sécuritaire consiste à se servir de l'hyperviseur comme rebond, en effet de par la patte qu'il possède sur le sous réseau non routable, on peut se connecter en ssh aux vms à partir de lui (l'hyperviseur)

$ ssh -i ~/.ssh/ids/rproxy.domain.com/admin/id_rsa rproxy.domain.com
admin@rproxy.domain.com$ ssh -i ~/.ssh/ids/192.168.0.42/admin/id_rsa 192.168.0.42

ssh possède une combinaison d'options (-A et -t) qui permet non seulement d'effectuer le rebond en une seule ligne de commande, mais qui permet également de garder les clés permettant d'accéder aux vms sur le poste du client, plutot que de devoir les copier sur l'hyperviseur comme c'était le cas précédemment.

ssh -A -t  -i ~/.ssh/ids/rproxy.domain.com/admin/id_rsa rproxy.domain.com ssh -i ~/.ssh/ids/192.168.0.42/admin/id_rsa 192.168.0.42

On peut gagner en concision en utilisant le fichier ssh config que l'on vient de voir à la section précédente

Host rproxy
    User admin
    Hostname rproxy.domain.com
    IdentityFile ~/.ssh/ids/rproxy.domain.com/admin/id_rsa

Host vm
    User admin
    Hostname 192.168.122.42
    IdentityFile ~/.ssh/ids/192.168.0.42/admin/id_rsa
    ProxyCommand ssh rproxy -W %h:%p

Il est désormais possible de se connecter à la vm via un simple

$ ssh vm

Une architecture plus sécuritaire serait d'avoir 2 IP publiques: l'une pour l'hyperviseur, l'autre pour le reverse proxy ...

Utiliser un pattern pour les identités gérées par clés

il est possible d'indiquer un pattern pour les identités gérées par clés dans /etc/ssh/sshd_config.

Voici celui que j'utilise

IdentityFile ~/.ssh/ids/%h/%r/id_rsa

le pattern est à comprendre comme suit

IdentityFile ~/.ssh/ids/[url du serveyur]/[username]/id_rsa

Si une clé est stockée dans ~/.ssh/ids/server.com/admin/id_rsa vous pouvez faire l'économie de l'option -i qui permet d'indiquer le pchemin de la clé à utiliser pour la connexion.

$ ssh admin@server.com

Il est possible d'utiliser ce mécanisme pour alléger le fichier ~/.ssh/config des lignes IdentityFile

Sauvegarder ~/.ssh de manière sécurisée

Avec vos clés bien rangées dans le répertoire ~/.ssh celui ci devient TRES sensibles et en même temps TRES pratiques. Voici une manière de le sauvegarder / restaurer avec PGP (un prérequis est donc d'avoir une paire de clé GPG et PGP installer sur sa machine)

Sauvegarder ~/.ssh

$ cd ~/.ssh && tar -czf /backups/ssh.tgz .
$ cd /backups/ && gpg  --batch --yes --encrypt --armor --output ssh.tgz.gpg --recipient mymailid4gpg@domain.com ssh.tgz
$ rm -rf /backups/ssh.tgz

Restaurer /backups/ssh.tgz

$ gpg  --output /backups/ssh.tgz --decrypt /backups/ssh.tgz.gpg
$ cd ~/.ssh && tar -xf /backups/ssh.tgz .
$ rm -rf /backups/ssh.tgz

Merci aux immenses @nomlambda & @themouette pour ces tuyaux!


Commentaires

comments powered by Disqus