Ssh
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 |
Installation
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é.
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, voir Attaque de l'homme du milieu
).
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.
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)
Configuration des clés
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.
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 ;-)
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
Configuration
Configurer le client
OpenSSH dispose de 3 niveaux de configuration :
- les options sur la ligne de commande
- le fichier de configuration de l'utilisateur
- 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.
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 tutoriel d'installation, de configuration et de test d'un serveur sshd est disponible sur la page sshd
Parmi les options par défaut, vous devriez regarder de plus près :
~PermitRootLogin yes
Un choix préférable pourrait être
~PermitRootLogin without-password
ce qui désactive la possibilité de se connecter sous root à partir de machines sans clé connue. Mettre cette option à 'no' désactive totalement le possibilité de se connecter directement sous root. Vous devez alors utiliser la commande su à partir du compte d'un utilisateur pour vous connecter sous root.
X11Forwarding no
Mettez cette option à 'yes' pour permettre aux utilisateurs d'exécuter des applications X sur votre serveur. Notez que désactiver cette option n'améliore pas la sécurité de votre serveur puisque "les utilisateurs peuvent toujours installer leur propre 'forwarder'"(pour plus d'info, utilisez la commande man sshd
~PasswordAuthentication yes
Mettez cette option à 'no' pour forcer SSH à utiliser le mécanisme des clés lors du login. Cela pourrait géner les utilisateurs qui se connectent fréquemment à partir de machines différentes mais c'est une grosse amélioration de la sécurité puisque l'authentification basée sur les mots de passe est considérée faible.
# Subsystem sftp /usr/lib/ssh/sftp-server
Supprimez le caractère dièse (#) du début de la ligne pour permettre d'utiliser 'sftp', une version sécurisée du serveur FTP (utilisation d'un tunnel SSH). Connaissant l'habitude des utilisateurs envers FTP et la lourdeur de la commande 'scp', cela vaut la peine de fournir 'sftp'. De plus, l'interface graphique populaire gftp supporte les transferts par 'sftp' depuis la version 2.07 (ce qui cache les fonctionnalités manquantes de 'sftp').
Copier des fichiers
Copier des fichiers avec scp
SSH vous donne accès à un ensemble de commandes et à un shell sur une machine distante. SSH ne vous permet pas directement de copier des fichiers, mais il fournit la commande scp. Supposons que vous vouliez copier un fichier appelé dumb à partir du répertoire courant de votre poste client (machine locale) vers votre répertoire d'accueil (home) sur le serveur distant appelé www.foobar.com. Votre compte sur la machine distante est bilbo. La commande de copie de fichier sera :
Inversement, pour copier le fichier du serveur vers votre machine locale :
La commande scp appelle SSH pour réaliser le login, copie le fichier et appelle SSH à nouveau pour fermer la connexion.
Si votre fichier de configuration ~~/.ssh/config contient déjà les données sur votre compte www.foobar.com comme ceci :
Host *fbc ~HostName www.foobar.com User bilbo ~ForwardAgent yes
alors vous pouvez remplacer bilbo@www.foobar.com par fbc ainsi :
'scp' suppose que votre répertoire d'accueil sur le serveur est votre répertoire de travail courant. Ainsi, si vous utilisez des chemins relatifs pour la machine distante, ils doivent être relatifs par rapport au répertoire d'accueil. En utilisant le commutateur
-r
de scp, vous pouvez copier récursivement des répertoires. 'scp' vous permet aussi de copier des fichiers entre machines distantes.
Maintenant vous êtes peut-être tenté d'essayer quelque chose comme ça : vous ouvrez une connexion SSH vers www.foobar.com, puis une fois connecté, vous lancez la commande
pour copier le fichier local dumb vers le serveur sur lequel vous êtes connecté. Très probablement vous obtiendrez le message suivant :
ssh: secure connection to {local machine} refused
Ce qui c'est passé est que vous avez exécuté la commande 'scp' à partir du serveur distant, et cette commande a essayé de se connecter à un serveur SSH sur votre machine … Souvenez-vous qu'il faut exécuter 'scp' à partir d'un terminal local à moins que votre machine ne fasse tourner aussi un serveur SSH 1.1
Copier des fichiers avec sftp
Si vous préférez une approche 'à-la-FTP', essayez sftp. La commande sftp établit une connexion FTP dans un tunnel SSH vers un serveur et vous donne accès à la plupart des commandes FTP standard. En cadeau bonux, 'sftp' vous permet d'exécuter des programmes à distance via la commande exec. Depuis la version 2.0.7, le client graphique gftp supporte les transferts sftp, ce qui comble quelques limitations de sftp.
Si le serveur distant ne propose pas de serveur sftp, copiez simplement l'exécutable '/usr/lib/ssh/sftp-server' sous votre répertoire d'accueil (ou sous un répertoire accessible et inclus dans votre $PATH), 'sftp' l'activera automatiquement lors de la connexion : vous n'avez besoin d'aucune permission spéciale sur le serveur distant.
Copier des fichiers avec rsync
rsync, l'outil immensément utile pour copier, mettre à jour et supprimer des fichiers locaux et distants, peut être aisément utilisé avec SSH en ajoutant l'option
-e ssh
Je ne l'utilise pas personnellement ;-). L'un des avantages de rsync est qu'il ne transfert que les différences entre les fichiers. Le fichier complet n'est transféré que si il n'existe pas sur le système cible. De plus il offre une méthode très efficace pour compresser les données et donc rendre les transferts plus rapides.
Copier des fichiers en utilisant un tunnel FTP
Si vous voulez vraiment utiliser votre client FTP traditionnel, attachez votre ceinture ;-) SSH permet à tous les protocoles d'utiliser un tunnel, FTP compris. Cependant FTP est un protocole un peu bizarre (il a besoin de 2 ports) et les résultats peuvent varier d'un serveur à un autre et d'un client à un autre. Si votre client FTP ne permet pas de se connecter à un port pré-défini, vous pouvez l'oublier tout de suite.
L'expression magique est port forwarding. Vous transmettez un numéro de port local non privilégié (i.e. un port > 1024) à un serveur distant, et puis vous vous connectez à la machine locale. Vous trouvez ça compliqué ? Et bien, ça l'est. Et je ne peux guère vous aider puisque je n'ai jamais réussi à le faire marcher. L'idée de base est de transmettre un numéro de port, forker SSH en arrière plan et l'occuper avec une commande sans intérêt pour maintenir le canal ouvert :
Maintenant démarrez un client FTP, et demandez-lui d'utiliser le numéro de port précédemment transmis :
Alors que les commandes comme cd fonctionnent, les commandes comme ls ou get se bloquent ou affichent de mystérieux messages d'erreur … ou les deux.
Il y a plusieurs programmes qui essaient de pallier ce problème : ftpsshd et hsftp. Mais soit ils ne marchent pas, soit ils sont trop compliqués à utiliser.
Pour transférer des fichiers, mieux vaut utiliser l'une des trois premières méthodes.
Tunneling
Tunneling Basics
L'utilisation d'un tunnel en SSH fonctionne en utilisant la méthode du transfert de port (port forwarding) : vous établissez une connexion entre un port local non priviligié (>1024) et le port qui est utilisé par le service à mettre dans le tunnel sur la machine distante (regardez le fichier '/etc/services' pour connaître la liste des ports standard). Ensuite vous vous connectez sur le port local. Toutes les requêtes à distination du port local sont alors transmises vers le port distant par SSH et donc sont cryptées. L'utilisation d'un tunnel ne fonctionne que si l'hôte distant fait tourner un serveur SSH évidemment. Pour savoir si un serveur distant propose SSH, utilisez la commande telnet sur le port 22 :
Vous devriez recevoir un message donnant la version du serveur SSH. Par contre, si vous obtenez un message comme celui-là :
telnet: Unable to connect to remote host: Connection refused
cela veut dire que l'hôte ne fait pas tourner de serveur SSH.
La syntaxe du transfert de port est :
Vous pouvez transférer plusieurs ports et vous pouvez configurer les ports fréquemment utilisés dans le fichier /.ssh/config
en utilisant l'option '~LocalForward'. Vous pouvez aussi transférer des
ports distants vers des ports locaux. Pour transférer des ports
priviligiés (<1024), vous devez être root.
Tunneling POP
Vous pouvez utiliser le protocole Post Office (POP) pour récupérer vos emails stockés chez votre fournisseur de services de messagerie électronique (e.g. votre ISP, votre université ou votre employeur si l'accès est autorisé). Faire passer ce protocole dans un tunnel SSH devrait essentiellement empêcher les renifleurs réseau ('network sniffers') de capter votre mot de passe POP. Et en prime, vous pouvez utiliser la compression de données proposée par SSH pour rendre la récupération des messages plus rapide.
Supposons que vous ayez un compte POP sur pop.foobar.com, que votre nom d'utilisateur est 'bilbo' et que votre mot de passe POP est 'topsecret'. La commande pour établir un tunnel SSH serait alors :
(Pour faire un test, vous pouvez augmenter la valeur du paramètre sleep à 500 - temps d'attente en secondes -).
Le message suivant vous invite à fournir votre mot de passe POP :
bilbo@pop.foobar.com's password:
Après avoir donné votre mot de passe, utilisez la commande 'telnet' pour vous connecter sur le port de transfert :
telnet localhost 1234
Vous devriez alors recevoir un message de type READY de la part de votre serveur de courriers.
Évidemment cette méthode vous oblige à fournir manuellement toutes les commandes POP, ce qui est un peu inconfortable ;-) Pour automatiser la chose, utilisez Fetchmail Via SSL/SSH?.
Notez que le protocole IMAP utilise des ports différents : IMAPv2 utilise le port 143, IMAPv3 le port 220.
Tunneling X
Si vous voulez faire tourner des applications X via SSH sur votre machine locale, connectez vous sur votre compte distant, créez le fichier /.ssh/environment et ajoutez cette ligne :
XAUTHORITY=/home/{nom de l'utilisateur distant}/.Xauthority
Si le fichier .Xauthority n'existe pas sur votre compte distant, il sera créé automatiquement par SSH lors de la phase de login.
Déconnectez-vous et démarrez une session SSH ainsi :
Cela ouvrira un terminal xterm distant sur votre machine locale. Vous pouvez faire la même chose avec n'importe quelle autre application X dont vous avez l'autorisation d'exécuter sur la machine distante.
