SSH signifie Secure SHell. C'est un protocole qui permet de faire des connexions sécurisées (i.e. cryptées) entre un serveur et un client SSH.
On peut l'utiliser pour se connecter à une machine distante comme avec telnet, pour transférer des fichiers de
manière sécurisée ou pour créer des tunnels. Les tunnels permettent sécuriser des protocoles qui ne le sont pas en faisant passer les données par une connexion SSH.
Le système de clés de SSH
Cryptographie asymétrique
SSH utilise la cryptographie asymétrique RSA ou DSA. En cryptographie asymétrique, chaque personne dispose d'un couple de clé : une clé publique et une clé privée. La clé publique peut être librement publiée tandis que chacun doit garder sa clé privée secrète. La connaissance de la clé publique ne permet pas d'en déduire la clé privée.
Si la personne A veut envoyer un message confidentiel à la personne B, A crypte le message avec la clé publique de B et l'envoie à B sur un canal qui n'est pas forcément sécurisé. Seul B pourra décrypter le message en utilisant sa clé privée.
Cryptographie symétrique
SSH utilise également la cryptographie symétrique. Son principe est simple : si A veut envoyer un message
confidentiel à B, A et B doivent d'abord posséder une même clé secrète. A crypte le message avec la clé sécrète et l'envoie à B sur un canal qui n'est pas forcément sécurisé. B décrypte le message grâce à la clé secrète.
Toute autre personne en possession de la clé secrète peut décrypter le message.
La cryptographie symétrique est beaucoup moins gourmande en ressources processeur que la cryptographie
asymétrique, mais le gros problème est l'échange de la clé secrète entre A et B. Dans le protocole SSL, qui est utilisé
par les navigateurs Web et par SSH, la cryptographique asymétrique est utilisée au début de la communication pour
que A et B puissent s'échanger une clé secrète de manière sécurisée, puis la suite la communication est sécurisée
grâce à la cryptographie symétrique en utilisant la clé secrète échangée.
Configuration du serveur SSH
Pour manipuler le daemon (le lancer, l'arrêter, recharger la configuration...), on utilise la commande
/etc/init.d/ssh
Le fichier de configuration du serveur SSH est /etc/ssh/sshd_config. À ne pas confondre avec /etc/ssh/ssh_config qui
est le fichier de configuration du client SSH.
Parmi les multiples options, on peut noter :
• Port 22: Signifie que le serveur SSH écoute sur le port 22, qui est le port normal de SSH. Il est possible de le faire écouter sur un autre port en changeant cette ligne.
• Protocol 2: Signifie que le serveur SSH accepte uniquement la version 2 du protocole SSH. C'est une version plus sécurisée que la version 1 du protocole. Pour accepter les deux protocoles, change la ligne en : Protocol 2,1
• PermitRootLogin no: Signifie que l'on ne peux pas se logger en root par SSH. Pour logger en root, il suffit de se
logger en utilisateur normal et d'utiliser la commande su.
• X11Forwarding yes: Autorise le transfert par SSH de l'affichage graphique.
• LoginGraceTime 600: Temps de connexion maximum
• RSAAuthentication yes: Méthode d'authentification.
• AuthorizedKeysFile .ssh/authorized_keys fichier utilisé pour 'l'autologin'
• PermitEmptyPasswords no: permet ou non les mots de passe vide
Si le fichier de configuration du serveur a été modifié, il faut indiquer au démon sshd de relire son fichier de
configuration, avec la commande /etc/init.d/ssh restart.
Se logguer par SSH
Deux types d'authentification sont possibles : par mot de passe et par clé. Dans les deux cas on utilise une des commandes suivantes :
ssh -l <login> <adresse du serveur SSH>
ssh <login>@<adresse du serveur SSH>
Authentification par mot de passe
C'est la méthode la plus simple. Lors de la connexion, le client ssh demande le mot de passe du compte. Dans ce cas, ssh crypte le mot de passe ce qui évite de le voir circuler en clair sur le réseau.
Authentification par clé
Au lieu de s'authentifier par mot de passe, les utilisateurs peuvent s'authentifier grâce à la cryptographie asymétrique et son couple de clés privée/publique, comme le fait le serveur SSH auprès du client SSH. La clé publique est placée sur le serveur dans le home du compte sur lequel on souhaite se connecter. La clé privée reste sur le poste client.
Dans ce cas, aucun mot de passe ne circule sur le réseau.
Générer une clé
Pour générer un couple de clés, on utilise la commande :
ssh-keygen -t dsa
Deux clés vont être générées, une clé publique (par défaut ~/.ssh/id_dsa.pub) et une clé privée (par défaut
~/.ssh/id_dsa). C'est la clé publique qu'il faudra copier sur le serveur.
Les clés générées ont par défaut une longueur de 1024 bits, ce qui est aujourd'hui considéré comme suffisant pour une bonne protection.
La commande demande un nom de fichier pour sauvegarder la clé privée et un nom de fichier pour sauvegarder la clé publique. Par défaut, la clé privée est stockée dans le fichier $HOME/.ssh/id_dsa.
La clé privée est enregistrée avec les permissions 600. La clé publique porte le même nom de fichier suivi de ".pub", avec les permissions 644.
Lors de la création de la clé, l'utilitaire demande une pass phrase qui est un mot de passe pour protéger la clé privée (2eme protection). Cette pass phrase sert à crypter la clé privée. La pass phrase sera alors demandée à chaque utilisation de la clé privée, c'est à dire à chaque fois que vous vous connecterez en utilisant cette méthode d'authentification. Un mécanisme appelé ssh-agent permet de ne pas rentrer le mot de passe à chaque fois (voir les docs).
Il est possible de changer la pass phrase qui protège la clé privée avec la commande ssh-keygen -p.
Autoriser sa clé publique
Pour autoriser une clé à se connecter à un compte, il faut placer sa partie publique dans le fichier
$HOME/.ssh/authorized_keys du compte en question, sur le serveur SSH. Si vous souhaitez vous connecter au serveur sur le compte sasa, le fichier est /home/sasa/.ssh/authorized_keys.
Pour transférer la clé publique, on peut utiliser ftp, scp (copie de fichier par ssh), ou un simple copier/coller entre deux terminaux (c'est simplement une longue ligne de caractères ASCII).
Chaque ligne du fichier authorized_keys correspond à une clé publique autorisée à se connecter. Il faut vérifier que chaque clé est bien sur une seule ligne, sinon ça ne fonctionne pas.
Le répertoire $HOME/.ssh' devrait être protégé en écriture, avec les permissions 755 (ou 705). De la même manière, le fichier authorized_keys ne doit pas être lisible par tous (600 par exemple).
Ensuite, pour se logger, il suffit de procéder comme précédemment.
Si la clé privée a été enregistré dans un autre fichier que $HOME/.ssh/id_dsa, il faut le préciser au client ssh :
ssh -i <nom du fichier contenant la clé privée> <login>@<serveur>
Agent SSH
Un agent SSH est un programme qui garde en mémoire des clés privées. Le principe est le suivant :
• on lance un agent
• on lui ajoute des clés (si les clés sont cryptées, elles sont décryptées avec la passphrase avant d'être ajoutées)
• à chaque connexion ssh, les clé de l'agent sont utilisées en priorité
Les avantages principaux sont :
• que la passphrase n'est demandée qu'une seule fois au moment où elle est ajoutée à l'agent,
• et que l'agent est capable de faire suivre la clé sur plusieurs connexions.
Pour lancer un agent on utilise généralement une commande qui ressemble à :
ssh-agent /bin/bash
L'agent SSH lance un nouveau shell ("/bin/bash") dans lequel il sera actif. Il ne sera utilisable qu'à partir de ce shell et dans les programmes qui y seront lancés.
Pour ajouter une clé on utilise
ssh-add [<fichier>]
Si on ne précise aucun fichier, il utilisera la clé par défaut ("~/.ssh/id_dsa" pour SSH 2).
Si la clé est crypté, la passphrase sera demandée et la clé décryptée sera ajoutée à l'agent.
Toutes les connexions SSH (avec ssh, scp...) lancées à partir de ce shell utiliseront l'agent et ne demanderont donc plus la passphrase.
Créer un "tunnel" crypté entre deux stations
SSH est également capable de fournir un encryptage à d'autres services (ftp par exemple) par le biais du port forwarding.
On peut l'utiliser pour se connecter à une machine distante comme avec telnet, pour transférer des fichiers de
manière sécurisée ou pour créer des tunnels. Les tunnels permettent sécuriser des protocoles qui ne le sont pas en faisant passer les données par une connexion SSH.
Le système de clés de SSH
Cryptographie asymétrique
SSH utilise la cryptographie asymétrique RSA ou DSA. En cryptographie asymétrique, chaque personne dispose d'un couple de clé : une clé publique et une clé privée. La clé publique peut être librement publiée tandis que chacun doit garder sa clé privée secrète. La connaissance de la clé publique ne permet pas d'en déduire la clé privée.
Si la personne A veut envoyer un message confidentiel à la personne B, A crypte le message avec la clé publique de B et l'envoie à B sur un canal qui n'est pas forcément sécurisé. Seul B pourra décrypter le message en utilisant sa clé privée.
Cryptographie symétrique
SSH utilise également la cryptographie symétrique. Son principe est simple : si A veut envoyer un message
confidentiel à B, A et B doivent d'abord posséder une même clé secrète. A crypte le message avec la clé sécrète et l'envoie à B sur un canal qui n'est pas forcément sécurisé. B décrypte le message grâce à la clé secrète.
Toute autre personne en possession de la clé secrète peut décrypter le message.
La cryptographie symétrique est beaucoup moins gourmande en ressources processeur que la cryptographie
asymétrique, mais le gros problème est l'échange de la clé secrète entre A et B. Dans le protocole SSL, qui est utilisé
par les navigateurs Web et par SSH, la cryptographique asymétrique est utilisée au début de la communication pour
que A et B puissent s'échanger une clé secrète de manière sécurisée, puis la suite la communication est sécurisée
grâce à la cryptographie symétrique en utilisant la clé secrète échangée.
Configuration du serveur SSH
Pour manipuler le daemon (le lancer, l'arrêter, recharger la configuration...), on utilise la commande
/etc/init.d/ssh
Le fichier de configuration du serveur SSH est /etc/ssh/sshd_config. À ne pas confondre avec /etc/ssh/ssh_config qui
est le fichier de configuration du client SSH.
Parmi les multiples options, on peut noter :
• Port 22: Signifie que le serveur SSH écoute sur le port 22, qui est le port normal de SSH. Il est possible de le faire écouter sur un autre port en changeant cette ligne.
• Protocol 2: Signifie que le serveur SSH accepte uniquement la version 2 du protocole SSH. C'est une version plus sécurisée que la version 1 du protocole. Pour accepter les deux protocoles, change la ligne en : Protocol 2,1
• PermitRootLogin no: Signifie que l'on ne peux pas se logger en root par SSH. Pour logger en root, il suffit de se
logger en utilisateur normal et d'utiliser la commande su.
• X11Forwarding yes: Autorise le transfert par SSH de l'affichage graphique.
• LoginGraceTime 600: Temps de connexion maximum
• RSAAuthentication yes: Méthode d'authentification.
• AuthorizedKeysFile .ssh/authorized_keys fichier utilisé pour 'l'autologin'
• PermitEmptyPasswords no: permet ou non les mots de passe vide
Si le fichier de configuration du serveur a été modifié, il faut indiquer au démon sshd de relire son fichier de
configuration, avec la commande /etc/init.d/ssh restart.
Se logguer par SSH
Deux types d'authentification sont possibles : par mot de passe et par clé. Dans les deux cas on utilise une des commandes suivantes :
ssh -l <login> <adresse du serveur SSH>
ssh <login>@<adresse du serveur SSH>
Authentification par mot de passe
C'est la méthode la plus simple. Lors de la connexion, le client ssh demande le mot de passe du compte. Dans ce cas, ssh crypte le mot de passe ce qui évite de le voir circuler en clair sur le réseau.
Authentification par clé
Au lieu de s'authentifier par mot de passe, les utilisateurs peuvent s'authentifier grâce à la cryptographie asymétrique et son couple de clés privée/publique, comme le fait le serveur SSH auprès du client SSH. La clé publique est placée sur le serveur dans le home du compte sur lequel on souhaite se connecter. La clé privée reste sur le poste client.
Dans ce cas, aucun mot de passe ne circule sur le réseau.
Générer une clé
Pour générer un couple de clés, on utilise la commande :
ssh-keygen -t dsa
Deux clés vont être générées, une clé publique (par défaut ~/.ssh/id_dsa.pub) et une clé privée (par défaut
~/.ssh/id_dsa). C'est la clé publique qu'il faudra copier sur le serveur.
Les clés générées ont par défaut une longueur de 1024 bits, ce qui est aujourd'hui considéré comme suffisant pour une bonne protection.
La commande demande un nom de fichier pour sauvegarder la clé privée et un nom de fichier pour sauvegarder la clé publique. Par défaut, la clé privée est stockée dans le fichier $HOME/.ssh/id_dsa.
La clé privée est enregistrée avec les permissions 600. La clé publique porte le même nom de fichier suivi de ".pub", avec les permissions 644.
Lors de la création de la clé, l'utilitaire demande une pass phrase qui est un mot de passe pour protéger la clé privée (2eme protection). Cette pass phrase sert à crypter la clé privée. La pass phrase sera alors demandée à chaque utilisation de la clé privée, c'est à dire à chaque fois que vous vous connecterez en utilisant cette méthode d'authentification. Un mécanisme appelé ssh-agent permet de ne pas rentrer le mot de passe à chaque fois (voir les docs).
Il est possible de changer la pass phrase qui protège la clé privée avec la commande ssh-keygen -p.
Autoriser sa clé publique
Pour autoriser une clé à se connecter à un compte, il faut placer sa partie publique dans le fichier
$HOME/.ssh/authorized_keys du compte en question, sur le serveur SSH. Si vous souhaitez vous connecter au serveur sur le compte sasa, le fichier est /home/sasa/.ssh/authorized_keys.
Pour transférer la clé publique, on peut utiliser ftp, scp (copie de fichier par ssh), ou un simple copier/coller entre deux terminaux (c'est simplement une longue ligne de caractères ASCII).
Chaque ligne du fichier authorized_keys correspond à une clé publique autorisée à se connecter. Il faut vérifier que chaque clé est bien sur une seule ligne, sinon ça ne fonctionne pas.
Le répertoire $HOME/.ssh' devrait être protégé en écriture, avec les permissions 755 (ou 705). De la même manière, le fichier authorized_keys ne doit pas être lisible par tous (600 par exemple).
Ensuite, pour se logger, il suffit de procéder comme précédemment.
Si la clé privée a été enregistré dans un autre fichier que $HOME/.ssh/id_dsa, il faut le préciser au client ssh :
ssh -i <nom du fichier contenant la clé privée> <login>@<serveur>
Agent SSH
Un agent SSH est un programme qui garde en mémoire des clés privées. Le principe est le suivant :
• on lance un agent
• on lui ajoute des clés (si les clés sont cryptées, elles sont décryptées avec la passphrase avant d'être ajoutées)
• à chaque connexion ssh, les clé de l'agent sont utilisées en priorité
Les avantages principaux sont :
• que la passphrase n'est demandée qu'une seule fois au moment où elle est ajoutée à l'agent,
• et que l'agent est capable de faire suivre la clé sur plusieurs connexions.
Pour lancer un agent on utilise généralement une commande qui ressemble à :
ssh-agent /bin/bash
L'agent SSH lance un nouveau shell ("/bin/bash") dans lequel il sera actif. Il ne sera utilisable qu'à partir de ce shell et dans les programmes qui y seront lancés.
Pour ajouter une clé on utilise
ssh-add [<fichier>]
Si on ne précise aucun fichier, il utilisera la clé par défaut ("~/.ssh/id_dsa" pour SSH 2).
Si la clé est crypté, la passphrase sera demandée et la clé décryptée sera ajoutée à l'agent.
Toutes les connexions SSH (avec ssh, scp...) lancées à partir de ce shell utiliseront l'agent et ne demanderont donc plus la passphrase.
Créer un "tunnel" crypté entre deux stations
SSH est également capable de fournir un encryptage à d'autres services (ftp par exemple) par le biais du port forwarding.
(options -L et -R de la commande ssh), de la manière suivante:
Considérons deux stations HOST1 et HOST2. Supposons que sur la machine HOST1, vous utilisiez la commande :
ssh -L p1:HOST2:p2 HOST2
ou sur HOST2:
ssh -R p1:HOST2:p2 HOST1
alors vous obtenez un tunnel sécurisé dans lequel vous pouvez passer toute connexion, lesquelles seront
automatiquement cryptées.
Sur HOST1, ssh -L p1:HOST2:p2 HOST2 signifie, que lorsqu'on se connecte au port p1, les paquets sont retransmis vers le port p2 de la machine HOST2 via HOST2.
Considérons deux stations HOST1 et HOST2. Supposons que sur la machine HOST1, vous utilisiez la commande :
ssh -L p1:HOST2:p2 HOST2
ou sur HOST2:
ssh -R p1:HOST2:p2 HOST1
alors vous obtenez un tunnel sécurisé dans lequel vous pouvez passer toute connexion, lesquelles seront
automatiquement cryptées.
Sur HOST1, ssh -L p1:HOST2:p2 HOST2 signifie, que lorsqu'on se connecte au port p1, les paquets sont retransmis vers le port p2 de la machine HOST2 via HOST2.
Aucun commentaire:
Enregistrer un commentaire