Afin d’effectuer la sauvegarde d’un serveur par un autre, il est courant d’utiliser un couple de clé SSH publique/privée sans mot de passe.

Tout commence par la génération du couple de clé :

fhh@mafalda ~ $ ssh-keygen -b4096 -C "Clé de sauvegarde" -f ~/.ssh/Saves
Generating public/private rsa key pair.
Enter passphrase (empty for no passphrase): # rien
Enter same passphrase again: # rien
Your identification has been saved in /home/fhh/.ssh/Saves.
Your public key has been saved in /home/fhh/.ssh/Saves.pub.
The key fingerprint is:
80:f8:8e:69:e3:95:6a:98:a7:d3:e4:89:53:be:dc:68 Clé de sauvegarde
The key's randomart image is:
+--[ RSA 4096]----+
...
+-----------------+
fhh@mafalda ~ $ ls .ssh/Saves*
.ssh/Saves  .ssh/Saves.pub

… et ce poursuit par la copie de la clé publique (.ssh/Saves.pub) dans le fichier « .ssh/authorized_keys » du serveur à sauvegarder :

fhh@mafalda ~ $ cat .ssh/Saves.pub | ssh srv.rez0.lan 'cat >> .ssh/authorized_keys'
Password:
fhh@mafalda ~ $ ssh -i .ssh/Saves srv.rez0.lan 'cat .ssh/authorized_keys'
...
ssh-rsa AAAAB...OA6s3H0c= Clé de sauvegarde

… pour finir par l’ajout de la clé associée au serveur dans « .ssh/config » :

fhh@mafalda ~ $ cat .ssh/config
...
Host=srvtobackup1
Hostname=srv.rez0.lan
User=fhh
Port=22
Compression=yes
IdentityFile=~/.ssh/Saves
...
fhh@mafalda ~ $ ssh srvtobackup1
fhh@srv ~ $

Le travail consiste ensuite à sécuriser cet accès au serveur à sauvegarder avec ce couple de clé :

• seul le serveur de sauvegarde devra être autorisé à ce connecter avec la clé privée.
• seul les commandes effectuant la sauvegarde devront être autorisée par cette connexion.

Toutes ces restrictions ce mettent en place sur le serveurs à sauvegarder directement dans le fichier « .ssh/authorized_keys ».

Limiter les machines autorisées à ce connecter avec la clé privée

Le champs « from=XXX » sur le serveur à sauvegarder restreint l’accès par cette clé aux machines spécifiées. »XXX » peu désigner :

• le FQDN d’une machine, ex : machine.rez0.lan (seul cette machine sera authorisée à ce connecter en utilisant cette clé) ;
• une adresse IP, ex : 10.0.2.2 (comme pour le FQDN mais avec l’IP) ;
• une plage IP, ex : 10.0.2.* (toutes les machines de cette plage pourront utiliser cette clé pour ce connecter) ;
• un domaine, ex : *.rez0.lan (comme pour la plage IP mais avec le domaine) ;
• une liste restrictive de machine, ex : « *.rez0.lan, !ns1.rez0.lan » ;
• des noms de machines utilisant les jokers habituels, ex : « ns?.rez0.lan ».

En reprenant notre exemple, seul la machine « mafalda.rez0.lan » doit être autorisée à ce connecter au serveur devant être sauvegardé :

fhh@mafalda ~ $ ssh srvtobackup1
fhh@srv ~ $ vi .ssh/authorized_keys
...
## Clé de sauvegarde depuis MAFALDA (mafalda.rez0.lan <10.0.2.2>)
from="mafalda.rez0.lan" ssh-rsa AAAAB...OA6s3H0c= Clé de sauvegarde
...
fhh@srv ~ $ exit
Connection to srv.rez0.lan closed.
fhh@mafalda ~ $ ssh srvtobackup1
fhh@srv ~ $

mais depuis une autre machine disposant également de la clé privée et des mêmes paramètres dans « .ssh/config », le mot de passe est demandé :

fhh@asus ~ $ ssh srvtobackup1
Password:

Limiter les fonctionnalités de la clé

La clé étant destinée uniquement à lancer une sauvegarde, les fonctionnalités tel que le X11 forwarding ou le port forwarding peuvent être suspendues. En fonction de l’utilisation faite de la clé, l’accès à un tty peut également être suspendu afin de ne plus offrir un shell interactif.

Avec une configuration du type :

fhh@srv ~ $ cat .ssh/authorized_keys
...
## Clé de sauvegarde depuis MAFALDA (mafalda.rez0.lan <10.0.2.2>)
from="mafalda.rez0.lan",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty  ssh-rsa AAAAB...OA6s3H0c= Clé de sauvegarde
...

Nous obtenons un comportement plutôt restrictif :

fhh@mafalda ~ $ ssh srvtobackup1
PTY allocation request failed on channel 0
Killed by signal 15.
fhh@mafalda ~ $ ssh srvtobackup1 'ls'
0493.pdf
fic1.txt
...

mais pas encore suffisamment :

fhh@mafalda ~ $ ssh srvtobackup1 '/bin/bash'
ls
0493.pdf
fic1.txt
...
cat /etc/passwd
root:x:0:0:Compte administrateur local:/root:/bin/bash
...

Limiter les commandes utilisable

Le couple de clé généré est, nous l’avons déjà dit, destiné à sauvegarder les données du serveur « SRV » au travers du réseau. La commande qui sera passée au serveur à sauvegardé sera donc toujours la même et, pour des raisons de sécurité, il est préférable de n’autoriser le lancement QUE de cette commande. Malheureusement, SSH ne dispose pas d’un système de restriction nous permettant de sélectionner les commandes lancées sur une connexion. En revanche, l’option command= »string » lance automatiquement UNE commande à chaque connexion utilisant le couple clés privée/publique auquel elle est appliquée.

Par exemple :

## Clé de sauvegarde depuis MAFALDA (mafalda.rez0.lan <10.0.2.2>)
from="mafalda.rez0.lan",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty,command="ls" ssh-rsa AAAAB...OA6s3H0c= Clé de sauvegarde

retourne le retour de « ls » quelque soit les paramètres passés lors de la connexion :

fhh@mafalda ~ $ ssh srvtobackup1 'cat /etc/passwd'
0493.pdf
fic1.txt
...
fhh@mafalda ~ $ ssh srvtobackup1 'cat /bin/bash'
0493.pdf
fic1.txt
...

Pour restreindre l’accès à une commande autorisées, nous lançons un script shell, dès l’établissement de la connexion, qui examine la chaîne de caractère passée en argument à SSH, la valide (afin d’éviter une attaque par injection, ex : si « ls* » est seul autorisé, la commande « ls ; /bin/bash » l’est aussi), et, si elle est valide l’exécute.

Voici une proposition de script :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

#!/bin/bash
 
# Commande autorisée :
AUTHORIZED_CMD="ls /tmp/"
 
# Validation de la commande :
case "$SSH_ORIGINAL_COMMAND" in
#       Si elle contient des caractère sensible, on la logue, on la rejette
# et on sort :
        *\&* | *\(* | *\{* | *\;* | *\<* | *\`* | *\|* )
                logger "BAD SSH SEQUENCE : \"$SSH_ORIGINAL_COMMAND\"." ;
                echo "Rejected" ;
                exit 1 ;
                ;;
#       Si la commande autorisée match, elle est exécutée et sort :
        ${AUTHORIZED_CMD})
                logger "SSH EXECUTING \"$SSH_ORIGINAL_COMMAND\"" ;
                $SSH_ORIGINAL_COMMAND ;
                exit $? ;
                ;;
        *)
#       Tout autre commande est rejetée et loguée :
                logger "BAD SSH SEQUENCE : \"$SSH_ORIGINAL_COMMAND\"." ;
                echo "Rejected" ;
                exit 1
                ;;
esac
# Si on en arrive là, il y a un problème :
logger "ERROR SSH : \"$SSH_ORIGINAL_COMMAND\"" ;
echo "Error"
exit 1 ;

Télécharger le script « ssh-validation ».

Qui donne à l’exécution :

fhh@mafalda ~ $ ssh srvtobackup1 'ls /tmp/'
conftest19483
test
fhh@mafalda ~ $ ssh srvtobackup1 'ls -al /tmp/'
Rejected

et dans les logs :

...
Sep 17 19:41:11 srv logger: SSH EXECUTING "ls /tmp/"
...
Sep 17 19:41:14 srv logger: BAD SSH SEQUENCE : "ls -al /tmp/".
...

Ce script n’est qu’une base, toute proposition d’amélioration est la bienvenue.