SSH2
1 Introduction
Beaucoup d’utilisateurs de telnet, rlogin, ftp et d’autres programmes de la même sorte ne se rendent pas compte que leurs mots de passes sont transmis sans être cryptés. Mais c’est le cas. SSH fait ce cryptage pour éliminer le vol de mot de passe, le détournement de connections et les autres attaques faites au niveau réseau. De plus, SSH permet de faire du tunnelling sécurisé.
2 Logiciel
Il existe plusieurs implémentation de SSH et notamment de SSH2 qui est la dernière norme en date.
Tout d’abord, on trouve une version commerciale de SSH2 qui tourne sous Unix avec un client Windows disponible. Cette version peut se trouver sur le site : www.ssh.com. Actuellement, on a put tester avec succès la version Unix sous OSF mais avec échec sous AIX (bien que l’on ne se soit pas trop acharné). Le client sous Windows fonctionne très bien aussi.
Pour ce qui est de la version libre de SSH2, il semble que ce soit OpenSSH qui soit la version la plus au point. Cette version fonctionne sous Unix et a été testée avec succès sous OSF et sous AIX et Linux. Le site web de OpenSSH se trouve à l’adresse : www.openssh.com.
Maintenant, il existe aussi plusieurs clients libres sous Windows. Un des plus facile et complet sous licence MIT (Open Source certified): Putty. Il est simple et très facile à installer.
Pour accéder a un volume en SFTP une extension de SSH vous pouvez utilisez WinSCP ou Filezilla.
3 Installation
Sous linux Openssh est inclus dans les distributions, utilisé le gestionnaire de paquet pour procéder à l’installation, si tout c’est bien passé, SSH est installé. Le démon SSH s’appelle sshd et doit être disponible dans le répertoire /usr/sbin. Les différents outils SSH sont disponibles dans le répertoire /usr/bin. On trouve notamment scp, ssh, ssh-add, ssh-agent et ssh-keygen. Toutes ces commandes sont documentées dans les manpages. Les fichiers de configuration sont disponibles dans le répertoire /usr/etc et chaque utilisateur de SSH possède un répertoire ~/.ssh.
Pour démarrer le service sur la plus par des distributions utiliser avec les droits d’administrateur: /etc/init.d/ssh start et /etc/init.d/ssh restart pour recharger les paramètres.
4 Configuration
Pour configurer OpenSSH sur les serveurs Unix, Il faut commencer par éditer les fichiers de configuration qui correspondent à ceux qui sont donnés en exemple. Je ne peux pas garantir la syntaxe et que les options ne changent pas, mais cela donne une idée.
Fichier /usr/etc/ssh_config :
# This is ssh client systemwide configuration file. This file provides
# defaults for users, and the values can be changed in per-user configuration
# files or on the command line.
# Configuration data is parsed as follows:
# 1. command line options
# 2. user-specific file
# 3. system-wide file
# Any configuration value is only changed the first time it is set.
# Thus, host-specific definitions should be at the beginning of the
# configuration file, and defaults at the end.
# Site-wide defaults for various options
Host *
ForwardAgent yes
ForwardX11 yes
RhostsAuthentication yes
RhostsRSAAuthentication yes
RSAAuthentication yes
PasswordAuthentication yes
FallBackToRsh no
UseRsh no
BatchMode no
CheckHostIP yes
StrictHostKeyChecking yes
IdentityFile ~/.ssh/identity
Port 22
Protocol 2,1
Cipher 3des
EscapeChar ~
# Be paranoid by default
# Host *
# ForwardAgent no
# ForwardX11 no
# FallBackToRsh no
Fichier /usr/etc/sshd_config :
# This is ssh server systemwide configuration file. Port 22 #Protocol 2,1 ListenAddress 0.0.0.0 #ListenAddress :: HostKey /usr/local/etc/ssh_host_key ServerKeyBits 768 LoginGraceTime 600 KeyRegenerationInterval 3600 PermitRootLogin yes # # Don't read ~/.rhosts and ~/.shosts files IgnoreRhosts yes # Uncomment if you don't trust ~/.ssh/known_hosts for RhostsRSAAuthentication #IgnoreUserKnownHosts yes StrictModes yes X11Forwarding yes X11DisplayOffset 10 PrintMotd yes KeepAlive yes XAuthLocation /usr/bin/X11/xauth # Logging SyslogFacility AUTH LogLevel INFO #obsoletes QuietMode and FascistLogging RhostsAuthentication no # # For this to work you will also need host keys in /etc/ssh_known_hosts RhostsRSAAuthentication no # RSAAuthentication yes # To disable tunneled clear text passwords, change to no here! PasswordAuthentication yes PermitEmptyPasswords no # Uncomment to disable s/key passwords #SkeyAuthentication no # To change Kerberos options #KerberosAuthentication no #KerberosOrLocalPasswd yes #AFSTokenPassing no #KerberosTicketCleanup no # Kerberos TGT Passing does only work with the AFS kaserver #KerberosTgtPassing yes CheckMail no UseLogin no #Subsystem sftp /usr/local/sbin/sftpd
Dans le fichier /usr/etc/ssh_known_hosts2 doivent être placé les clés publiques de tous les machines avec lesquelles, un client sur notre machine pourra dialoguer. Chaque machine conserve sa clé publique dans /usr/etc/ssh_host_dsa_key.pub. Le fichier /usr/etc/ssh_known_hosts2 contient une clé publique par ligne. C’est l’option StrictHostKeyChecking yes qui nous oblige à faire cela.
5 Utilisation
Maintenant, vous pouvez utiliser ssh cette commande vous permet de vous connecter ou d’exécuter une commande sur un serveur distant ou sshd est lancé. Si vous avez installé les outils ssh sur comp1 et comp2. Vous pouvez sur comp1 utiliser la commande :
ssh -l root comp2
Ce qui vous permet de vous connecter en root sur comp2. Il vous sera demandé le mot de passe de ce compte.
Lorsque vous êtes connecté sur la machine comp2, vous pouvez utiliser les applications XWindows qui seront cryptées. Cela ne fonctionne que si vous aviez la variable d’environnement DISPLAY correctement configurée sur la machine comp1. Surtout, NE TOUCHEZ PAS à la variable d’environnement DISPLAY lorsque vous êtes connecté avec ssh à moins que vous ne souhaitiez plus utiliser le cryptage pour XWindows pour des raisons de performance par exemple. Dans ce cas, définissez cette variable comme vous avez l’habitude de le faire.
Vous pouvez aussi utiliser la commande scp pour copier le fichier /etc/hosts de la machine comp1 vers la machine comp2 dans le répertoire /tmp en tapant à partir de comp1 :
scp /etc/hosts root@comp2:/tmp
Là aussi le mot de passe du root sur la machine comp2 vous sera demandé.
5.1 gestion des clefs
Tout cela est très bien et on utilise le système des mots de passe en place sur le serveur Unix. Si vous voulez vous passer de mot de passe, il est possible d’utiliser le fichier .shosts qui doit être placé dans le répertoire home de l’utilisateur. Ce fichier suit la même syntaxe et le même principe que le fichier .rhosts sauf que l’identité de la machine qui veut ce connecter est vérifié avec sa signature électronique. En d’autres termes, chaque serveur possède une clé publique est une clé privée. Les clés publiques des serveurs sont connues des autres serveurs avec qui le dialogue doit être possible. Les clés privées sont l’exclusivité des serveurs auxquelles elles appartiennent. Ainsi, les serveurs peuvent vérifier l’identité de l’interlocuteur. Ce qui explique que lorsque l’on se connecte pour la première fois sur un serveur, ssh demande si l’on accepte la clé publique de celui-ci. On doit être sur que la clé publique du serveur est bien la bonne (lorsque c’est la première fois, on présume que c’est bon). Si la clé vient à changer, il faut d’abord vérifier que c’est normal (contacter les personnes) avant d’accepter d’apprendre une nouvelle clé publique.
Chaque machine conserve ses clés publiques et privées dans le répertoire /usr/etc. Les clés publiques étant les fichiers terminés par l’extension .pub.
Chaque utilisateur stocke les clés publiques des serveurs avec lesquels il dialogue dans le fichier ~/.ssh/known_hosts2. Chaque ligne correspondant à la clé d’un serveur.
Il existe une méthode pour autoriser les connections de n’importe qui s’il vient d’une certaine machine. On ne s’intéressera pas à cela.
Chaque utilisateur peut s’identifier autrement qu’en utilisant son login et son mot de passe sur la machine destination. Un utilisateur peut se générer une clé publique est une clé privée et se servir de ce mécanisme pour s’identifier de la même manière que les machines le font entre-elles.
Pour qu’un utilisateur possède ce mécanisme, il faut lui générer ses clés. Pour cela, il faut être connecté sur le compte de cet utilisateur et taper la commande :
ssh-keygen -b 2048 -t dsa
-b pour 2048 bits et -t dsa pour générer une clefs a la norme 2 du protocole d’authentification.
Conservez les noms des fichiers par défaut soit le fichier id_dsa pour la clé privée et id_dsa.pub pour la clé publique. Ces deux fichiers sont placés dans le répertoire ~/.ssh de chaque utilisateur. Une Passphrase est demandé. Il s’agit en fait d’une clé pour crypter la clé privée. Elle fera office de mot de passe. Elle ne sert que pour le cas où une personne réussirait à voler la clé privée d’un utilisateur qui NE DOIT ETRE ACCESSIBLE QUE PAR CELUI-CI. Cette valeur doit être laissée vide pour les comptes qui seront utilisés par des scripts. On ne peut dans ce cas que faire confiance aux droits d’accès des fichiers.
Si vous voulez vous connecter de comp1 à partir du compte user1 vers comp2 sur le compte root en utilisant ce principe et sans mot de passe. Vous généré une paire de clé sur comp1 pour le compte user1 sans Passphrase. Ensuite, vous rajouter le contenue de la clé publique (fichier ~/.ssh/id_dsa.pub) de l’utilisateur user1 disponible sur la machine comp1 dans le fichier ~/.ssh/authorized_keys2 de l’utilisateur root sur la machine comp2. Si ce fichier n’existe pas, créez-le. Il contient les clés publiques de tous les utilisateurs qui peuvent ce connecter sur ce compte. Une clé par ligne. Il suffit donc d’éditer ce fichier et de rajouter la ligne du fichier id_dsa.pub (utilisateur source) dans le fichier authorized_keys2 (utilisateur cible).
Dès lors, si vous êtes sur le compte user1 sur comp1 et que vous faites la commande :
ssh -l root comp2
Aucun mot de passe ne vous sera demandé. Sauf si vous avez crypté votre clé privée avec une Passphrase. Dans ce cas, c’est votre Passphrase qui vous sera demandée.
5.2 Utilisation
Imaginons maintenant, que vous utilisateur, vous voulez vous connecter depuis d’autres machines, d’autres comptes toujours sur le compte root de comp2. Vous pouvez vous générer une paire clé pour chaque compte et les rajouter dans le fichier authorized_keys2. Vous pouvez aussi recopier vos clés générées sur comp1 (clé publique et clé privé) pour les placer dans le répertoire ~/.ssh des autres machines. Voilà, vous avez accès au compte root de comp2 depuis une machine autre de comp1 et cela sans avoir besoin d’embêter l’administrateur de comp2.