Ssh
Un article de Wiki de la communauté Mandriva.
Si vous voulez contribuer, cliquez simplement sur l'onglet modifier. Consultez également les autres pages dont la forme est à réviser.
Sommaire |
[modifier] Installation
[modifier] Qu'est ce que SSH ?
Les services réseau usuels comme FTP, POP ou telnet sont pratiques mais intrinsèquement non sûrs puisqu'ils font tous transiter les données et les mots de passe en clair sur un réseau incroyablement peu sûr. Il est très facile d'intercepter les informations de ces services et de copier les données transférées. De plus, l'authentification du serveur est faible : les services sont à la merci d'attaques du type man-in-the-middle (un homme au milieu), où un intrus peut se faire passer pour le serveur et ainsi recevoir toutes les données que le client envoie.
Et voici SSH (Secure SHell). En utilisant SSH, le trafic est chiffré et vous rendez les attaques du type 'man-in-the-middle' presque impossibles. Cela vous protège aussi du DNS et de l'IP spoofing. En prime, il offre la possibilité de compresser le trafic et ainsi rendre les transferts plus rapides. SSH est un outil très souple : non seulement il remplace telnet, mais vous pouvez aussi créer un tunnel chiffré pour faire passer les services comme FTP, POP et même PPP.
Le SSH original a été développé par une société finlandaise. À cause de contraintes de copyright et des algorithmes brevetés, le monde du Logiciel Libre utilise maintenant OpenSSH, un système à la SSH.
Comme tout service, SSH s'appuie sur une architecture client-serveur. Tout administrateur système compétent utilise un serveur SSH. Si votre système hôte distant n'utilise pas SSH, vous devriez vraiment penser à changer pour un système qui l'utilise. Un site qui n'utilise pas un serveur SSH affiche un manque d'intérêt certain pour la sécurité.
SSH se présente en 2 versions partiellement incompatibles : 1.x et 2.x. Vous ne pourrez pas faire dialoguer un client SSH 2.x avec un serveur SSH 1.x. OpenSSH supporte les 2 versions.
Notez que la version 1 est dépréciée pour des raisons de sécurité.
[modifier] Comment l'authentification de SSH fonctionne-t-elle ?
Vu du côté du client, SSH fournit 2 niveaux d'authentification.
Le premier niveau vous permet de vous connecter à un serveur à partir de n'importe quelle machine si vous connaissez le mot de passe d'un compte sur le serveur. Tout le trafic envoyé via SSH est chiffré, mais un mécanisme d'authentification forte n'est pas utilisé pour identifier l'hôte qui reçoit votre connexion. Un autre hôte pourrait intercepter votre connexion en se faisant passer pour le serveur que vous voulez joindre (attaque du type man-in-the-middle).
Le deuxième niveau s'appuie sur le mécanisme des clés : vous créez votre paire de clés et déposez votre clé publique sur le serveur. Maintenant si vous vous connectez au serveur SSH, le client envoie une demande d'authentification au serveur en utilisant vos clés. Le serveur récupère votre clé publique qui se trouve dans votre répertoire d'accueil (remote home dir) et compare les deux clés. Ensuite il envoie un challenge chiffré au client. Ce challenge est déchiffré par le poste client en utilisant la clé privée et est renvoyé au serveur. En utilisant cette méthode, vous devez connaître le mot de passe de votre clé (si vous avez choisi d'en utiliser un). Par rapport au premier niveau, ce mot de passe ne sera pas envoyé sur le réseau. L'authentification de niveau 2 n'utilise aucun mot de passe. retrouvez plus de détails sur ce mécanisme de clés dans l'article Gpg Ce procédé non seulement chiffre tout ce qui transite via SSH mais rend aussi impossible une attaque du type man-in-the-middle. La phase de login prend environ une dizaine de secondes.
[modifier] Installer et tester OpenSSH
OpenSSH est désormais nativement installé sur Mandriva.
Cette section est vide ou n'est pas assez détaillée, vous pouvez l'améliorer en l'éditant !
> (note perso : import à poursuivre. Spip)
[modifier] Configuration des clés
[modifier] Générer sa paire de clés
Générer et distribuer ses propres clés a deux avantages : vous vous protégez des attaques du style man-in-the-middle (e.g. une machine qui falsifie l'empreinte d'un hôte distant) et vous pouvez utiliser un mot de passe pour tous les serveurs auxquels vous vous connectez.
Souvenez-vous qu'il existe deux versions principales de SSH, partiellement incompatibles : la version 1 et la version 2. Bien que les serveurs SSH version 2 peuvent être configurés pour accepter les clés créées avec la version 1, il est préférable de créer deux paires de clés : une pour la version 1, l'autre pour la version 2. Puisque les noms des clés générées sont différents, ils peuvent être stockés dans le même répertoire et vous pouvez laisser le serveur sélectionner les clés qu'il veut.
Pour la version 1, la clé est générée par la commande :
Pour la version 2, la clé est générée ainsi :
Des clés version 2 de type RSA, générées par cette commande, sont à préférer à des clés version 2 de type DSA.
La commande 'ssh-keygen' lance le dialogue suivant :
Generating public/private rsa key pair.
Enter file in which to save the key (/home/{user}/.ssh/id_rsa):
Appuyez simplement sur la touche ENTRÉE à moins que vous ayez déjà une autre clé avec ce nom, par exemple pour une version différente de SSH.
Enter passphrase (empty for no passphrase): Enter same passphrase again:
La passphrase ne sera pas affichée à l'écran.
La passphrase n'est pas récupérable. Si vous l'oubliez, vous devrez générer une nouvelle paire.
Your identification has been saved in /home/{user}/.ssh/id_rsa.
Your public key has been saved in /home/{user}/.ssh/id_rsa.pub.
ssh-keygen -t rsa réalise fondamentalement la même chose, mais sauvegarde la paire de clés dans les fichiers '/home/{user}/.ssh/id_rsa' (clé privée) et '/home/{user}/.ssh/id_rsa.pub' (clé publique). Vous pouvez utiliser la même _passphrase_ pour les deux paires.
Maintenant vous avez une paire de clés : une clé publique que vous pouvez distribuer à tout le monde (enfin, toute personne susceptible de se connecter en ssh sur votre serveur), et une clé privée qui est le coeur du processus d'authentification. Cela veut dire : personne ne doit jamais pouvoir accéder à votre clé privée 1.1
La commande
ou si utiliser la version 2 :
doit toujours afficher ces permissions :
-rw––-
Si vous pensez que votre clé privée a été compromise, n'hésitez pas à générer une nouvelle paire. Vous aurez alors à distribuer à nouveau votre clé publique évidemment.
[modifier] Distribuer sa clé
Sur chaque serveur où vous voulez vous connecter en SSH, créez un sous-répertoire .ssh sous le répertoire personnel (HOME) du compte utilisé. Ensuite, copiez le fichier /.ssh/identity.pub de votre poste client sous le répertoire .ssh précédemment créé sur le serveur en le nommant authorized_keys. De la même façon pour la version 2, copiez /.ssh/id_rsa.pub et renommez-le en authorized_keys2. Maintenant lancez la commande suivante sur le serveur :
N'oubliez pas cette étape, car SSH refusera de marcher si les fichiers authorized_keys(2) sont accessibles en écriture par un autre utilisateur que vous 1.1
Les fichiers authorized_keys(2) peuvent contenir plus d'une clé publique, dans le cas où vous voudriez vous connecter au serveur à partir de plusieurs postes client. Dans ce cas, vous devrez générer une nouvelle paire de clés sur votre autre poste client, copier le contenu du fichier identity.pub en le collant dans le fichier authorized_keys. Bien sûr, vous ne devriez faire ça que si le compte sur le poste client vous appartient personnellement et que la clé est protégée par un mot de passe. De plus, n'oubliez pas de supprimer la paire de clés lorsque vous n'en avez plus besoin. Règle de base : il vaut mieux de ne pas employer une authentification à base de clés sur des machines qui ne méritent pas votre confiance ;-)
[modifier] Conserver les clés dans la mémoire du système
Conserver les clés dans la mémoire du système Cette méthode est très pratique lorsque vous vous connectez régulièrement à plusieurs machines pendant une session. L'astuce est d'utiliser des applications à authentification automatique. Cela se fait grâce aux programmes ssh-add et ssh-agent
La commande
reads:
"L'agent d'authentification doit tourner et être parent du processus courant ssh-add pour fonctionner."
Heuh 1.1 ?
exécute plusieurs commandes, crée un fichier PID et positionne quelques variables d'environnement système. Pour que cela fonctionne, on a besoin d'utiliser la commande shell eval
Vous devriez voir un message du genre :
Agent pid {number}
Lancez la commande suivante :
Dans le même terminal et la clé sera chargée en mémoire, après que vous ayez fourni votre mot de passe si la clé est protégée. Maintenant vous pouvez démarrer des sessions SSH à partir de ce terminal sans avoir à donner de mot de passe, à condition que vous ayez configuré correctement le fichier de configuration de SSH, tel que nous allons le voir un peu plus loin. La commande ssh-add ne charge que les clés de la version 1 de SSH par défaut. Pour charger les clés de la version 2, vous devez spécifier son fichier :
Pour charger les clés des deux versions d'un seul coup, vous devez spécifier les deux fichiers :
Si vous voulez que ssh-agent soit parent de tous les terminaux virtuels d'une session, ajoutez la commande eval $(ssh-agent) à vos fichiers personnels de démarrage du serveur X, c'est à dire soit le fichier /.xinitrc si vous démarrez X à partir d'une console, soit le fichier /.xsession si vous démarrez directement sous X. Ensuite exécutez la commande
et tous les terminaux que vous ouvrirez pendant la session seront authentifiés. Notez que cela n'est pas nécessaire pour les versions de Mandrakelinux 7.1 et ultérieures si vous démarrez directement sous X : le fichier /etc/X11/Xsession lance automatiquement l'agent si une clé SSH se trouve dans le répertoire ~/.ssh de l'utilisateur. D'autres options utiles sont :
liste les clés déjà en mémoire
supprime une identité chargée en mémoire
[modifier] Configuration
[modifier] Configurer le client
OpenSSH dispose de 3 niveaux de configuration : les options sur la ligne de commande, le fichier de configuration de l'utilisateur et le fichier de configuration global à tout le système (/etc/ssh/ssh_config). Les options fournies sur la ligne de commande prévalent sur les options des fichiers de configuration, les options du fichier de configuration de l'utilisateur prévalent sur celles du fichier de configuration globale. Toutes les options de la ligne de commande ont un équivalent dans les options du fichier de configuration. Puisqu'il n'y a pas de fichier de configuration utilisateur installé par défaut, copiez le fichier /etc/ssh/ssh_config en le renommant ~~/.ssh/config via la commande
(ou éditez directement le fichier /etc/ssh/ssh_config sous root).
Le fichier de configuration standard ressemble à :
{De nombreuses explications et les options possibles sont fournies au début du fichier de configuration} ~# Soyons parano par défaut 1.1 Host * ~ForwardAgent no ~ForwardX11 no ~FallBackToRsh no
{La commande man ssh
fournit des explications sur les options disponibles dans le chapitre CONFIGURATION FILES}.
Le fichier de configuration est lu séquentiellement, i.e. la première règle valide 'gagne'. Supposons que vous ayez un compte sur www.foobar.com et que votre compte soit 'bilbo'. De plus vous souhaitez utiliser la combinaison 'ssh-agent' - 'ssh-add' ainsi que la compression de données pour accélérer les transferts. Et puisque vous êtes trop fainéant pour saisir le nom complet du serveur à chaque fois, vous voulez utiliser la chaîne 'fbc' à la place de 'www.foobar.com'. Votre fichier de configuration pourrait ressembler à :
Host fbc ~HostName www.foobar.com User bilbo ~ForwardAgent yes Compression yes ~# Soyons parano par défaut 1.1 Host * ~ForwardAgent no ~ForwardX11 no ~FallBackToRsh no
La prochaine fois que vous utiliserez la commande
SSH ira rechercher dans le fichier de configuration le nom complet de l'hôte et le nom de l'utilisateur ('bilbo') pour se connecter, et l'authentification utilisera la clé gérée par 'ssh-agent'. Ça ne peut pas être plus simple que ça, n'est-ce pas ? ;-)
Les connexions SSH vers les autres hôtes utiliseront toujours les options 'paranoïaques' par défaut. De même les autres comptes utiliseront les choix 'paranoïaques' si ils n'ont pas été explicitement désactivés dans leur fichier de configuration ou sur la ligne de commandes. Dans l'exemple précédent, une connexion SSH vers www.foobar.com aura les options suivantes activées : '~ForwardAgent' et 'Compression'. Les options '~ForwardX11' et '~FallBackToRsh' seront cependant désactivées à moins qu'elles ne soient surchargées par les arguments de la commande ssh.
D'autres options intéressantes sont :
~CheckHostIP yes
Cette option permet un contrôle supplémentaire sur l'adresse IP par le serveur distant pour empêcher l'usurpation d'identité (DNS spoofing).
~CompressionLevel
Le taux de compression varie de '1' (compression rapide) à '9' (meilleure réduction de volume). La valeur par défaut est '6'.
~ForwardX11 yes
Vous aurez besoin de cette option pour exécuter localement des applications X distantes.
~LogLevel DEBUG
Cette option est pratique lorsque vous avez des soucis avec la connexion SSH. Par défaut, le niveau est INFO.
[modifier] Configurer le serveur
La configuration du serveur SSH est faite via le fichier /etc/ssh/sshd_config. Des explications sur les options sont fournies dans le fichier. La commande man sshd peut aussi être utilisée. Remarquez que OpenSSH utilise le même fichier de configuration pour SSH 1.x et 2.x.
Le tutorial d'instalation, de configuration et de test d'un serveur sshd est disponible sur la page sshd
