Documentations -- Système & réseau
Copyright © 2001,2005 Debianworld.org
Ce document est publié sous la licence GNU FDL
| Historique des versions | ||
|---|---|---|
| Version 0.1 | 16 Juin 2005 | ES |
| Première version | ||
Table des matières
De nos jours, il n'est plus rare de disposer de plusieurs accès à différents ordinateurs (accès au web depuis chez soi, accès à différentes machines sur le réseau de l'entreprise, ...). Si vous disposez de plusieurs comptes, il est naturel de vouloir se connecter d'une machine à l'autre. Par exemple pour copier des fichiers à travers le réseau de l'entreprise ou encore depuis chez soi pour envoyer des fichiers vers l'ordinateur d'un ami. De nombreux programmes existent afin de réaliser ces diverses tâches tels rcp et ftp pour le transfert de fichiers, telnet et rlogin pour se connecter à distance et rsh pour l'exécution de commandes à distance.
Malheureusement, tous ces programmes présentent de nombreux problèmes au niveau de la sécurité. Si vous envoyez un fichier sensible sur internet, un éventuel pirate pourrait l'intercepter et en tirer profit. Pire encore, si vous vous connectez à distance avec telnet par exemple, votre identifiant et mot de passe peuvent être interceptés, à l'aide d'outils comme tcpdump par exemple, et permettre à un pirate de se connecter sur cette machine distante.
Comment lutter contre ceci ? Vous pouvez utiliser un programme qui encode vos données, que vous seul pourrez lire, avant de les envoyer sur le réseau. Vous pouvez utiliser un pare-feu pour prévenir de certains pirates sur un réseau local. Ou vous pouvez utiliser un nombre considérable de solutions avec une complexité et un coût indéniable.
Voici une petite introduction sur SSH qui va vous permettre de crypter vos communications lors de l'envoi de fichiers sur le Net ou lors de vos connexions distantes.
ssh (Secure Shell) est un programme permettant de se connecter sur un autre ordinateur à travers un réseau, d'exécuter des commandes sur ce hôte distant et de copier des fichiers entre machines. Il est livré avec une authentification très forte et une sécurisation des communications en milieu hostile via le cryptage des données transitant entre la machine sur laquelle vous êtes et le hôte distant. C'est un remplaçant des commandes BSD rlogin, rsh et rcp qui sont vulnérables à différents types d'attaques.
Vous pouvez également utiliser SSH comme un outil additionnel à rsync lors de sauvegardes réseaux.
Le serveur X Window était confronté et l'est toujours aux problèmes de sécurité. Avec ssh, vos connexions distantes à un serveur X seront sécurisées et ceci est complètement transparent pour l'utilisateur. De plus, les connexions X pour les utilisateurs sont plus conviviales que les connexions standards en console.
Deux versions de ssh sont disponibles: SSH1 et SSH2. J'encourage toutes les personnes à utiliser la version 2 du protocole SSH car la première version inclus des failles de sécurité.
Pour le cryptage des données :
Cipher SSH1 SSH2 DES yes no 3DES yes yes IDEA yes no Blowfish yes yes Twofish no yes Arcfour no yes Cast128-cbc no yesPour l'authentification :
Cipher SSH1 SSH2 RSA yes no DSA no yes
ssh utilise une des méthodes suivantes pour authentifier les utilisateurs :
Mot de passe --> /etc/passwd ou /etc/shadow
Clé publique utilisateur (RSA ou DSA, en fonction du protocole)
Kerberos pour SSH1
En fonction de l'hôte (.rhosts ou /etc/hosts.equiv en SSH1 ou les clés publiques en SSH2)
SSH utilise une clé publique pour crypter les données et une clé privée pour les décrypter. Le nom clé publique vient du fait que vous pouvez mettre à disposition la clé au public sans risque de compromission des données ou de la clé de décryptage.
Ceci signifie que vous pouvez communiquer votre clé publique via mail ou tout autre moyen sans risquer de compromettre les données. Pour les décrypter il faudra impérativement disposer de la clé privée correspondante.
Pour sécuriser davantage votre clé privée, vous devriez utiliser un mot de passe sous forme de phrase pour crypter la clé lorsqu'elle est stockée sur votre disque dur. Ceci permet de la prévenir même si quelqu'un s'en emparait.
Nous allons installer OpenSSH qui prend en compte les deux protocoles aussi bien SSH1 que SSH2. OpenSSH inclus différents programmes :
* ssh -- client de connexion distant * sshd -- serveur de connexion distant * scp -- copie de fichier sécurisé * sftp -- transfert de fichier sécurisé
Le paquet ssh contient le client et le serveur sshd. Procédons à l'installation à l'aide de apt :
# apt-get install sshLors de l'installation vous devrez répondre à différentes questions :
Allow SSH protocol 2 only ? Oui
Do you want /usr/bin/ssh-keysign to be installed SUID root ? Oui
Do you want to run the sshd server ? Oui
Le fichier de configuration du serveur sshd est le fichier /etc/ssh/sshd_config. Nous allons détailler certains paramètres du fichier de configuration :
Port 22 ListenAddress 192.168.1.1 HostKey /etc/ssh/ssh_host_key ServerKeyBits 1024 LoginGraceTime 600 KeyRegenerationInterval 3600 PermitRootLogin no IgnoreRhosts yes IgnoreUserKnownHosts yes StrictModes yes X11Forwarding no PrintMotd yes SyslogFacility AUTH LogLevel INFO RhostsAuthentication no RhostsRSAAuthentication no RSAAuthentication yes PasswordAuthentication yes PermitEmptyPasswords no AllowUsers me you toto
Port 22 indique sur quel numéro de port le démon ssh doit écouter. Le port 22 est utilisé par défaut.
ListenAddress 192.168.1.1 spécifie l'adresse ip de l'interface réseau sur laquelle le socket du démon ssh est rattaché. Par défaut, c'est 0.0.0.0 mais pour des raisons de sécurité il peut être utile de spécifier uniquement celles requises pour limiter les adresses possibles.
HostKey /etc/ssh/ssh_host_key indique le fichier contenant la clé privée de l'hôte.
ServerKeyBits 1024 indique le nombre de bits à utiliser pour la clé du serveur. Ceci est utilisé lorsque le daemon démarre pour générer sa clé RSA.
LoginGraceTime 600 indique la durée en secondes avant que le serveur déconnecte l'utilisateur si celui-ci n'arrive pas à se connecter.
KeyRegenerationInterval 3600 spécifie la durée d'attente en secondes du serveur avant qu'il ne regénère automatiquement sa clé. Ceci permet de prévenir le décryptage des sessions capturées.
PermitRootLogin no indique si root peut se connecter en utilisant ssh. Ne jamais mettre yes à cette option.
IgnoreRhosts yes indique si l'utilisation des fichiers rhosts et shosts est possible. Pour des raisons de sécurité, il est recommandé de ne pas les utiliser.
IgnoreUserKnownHosts yes indique si le démon ssh doit ignorer le fichier utilisateur $HOME/.ssh/known_hosts lors des connexions utilisant l'option RhostsRSAAuthentication.
StrictModes yes spécifie si ssh doit vérifier les permissions des utilisateurs dans leur répertoire et du fichier rhosts avant d'accepter une connexion. Cette option doit toujours être mise à yes car parfois des utilisateurs peuvent laisser accidentellement leurs répertoires et fichiers en écriture pour tout le monde.
X11Forwarding no indique si le "déport" de X11 doit être activé sur le serveur.
PrintMotd yes indique si le démon ssh doit afficher le contenu du fichier /etc/motd lors de la connexion d'un utilisateur. Ce fichier est connu également comme le "message du jour".
LogLevel INFO indique le niveau qui est utilisé pour les logs de sshd. L'option INFO est un bon choix. Réferrez-vous à la page de manuel pour plus d'informations sur les autres possibilitées.
RhostsAuthentication no spécifie si ssh doit utiliser l'authentification basée sur le fichier rhosts. Vous ne devriez pas utiliser cette option.
RhostsRSAAuthentication no indique d'essayer l'authentification rhosts avec celle de RSA.
RSAAuthentication yes spécifie si une authentification RSA doit être faite. Cette option doit être mise à yes pour une meilleure sécurité de vos sessions. La RSA utilise les clés publiques et privées créées à l'aide de l'utilitaire ssh-keygen.
PasswordAuthentication yes indique si l'authentification doit se baser sur les mots de passe. Pour une bonne sécurité, cette option doit toujours être mise à yes.
PermitEmptyPasswords no spécifie si le serveur autorise les connexions à des comptes avec des mots "vide".
AlowUsers me you toto spécifie et contrôle quels utilisateurs peuvent accéder aux services ssh. Plusieurs utilisateurs peuvent être indiqués en les séparant avec des espaces.
Le fichier de configuration du client ssh est le fichier /etc/ssh/ssh_config. Nous allons détailler certains paramètres du fichier de configuration :
Host * ForwardAgent no ForwardX11 no RhostsAuthentication no RhostsRSAAuthentication no RSAAuthentication yes PasswordAuthentication yes FallBackToRsh no UseRsh no CheckHostIP yes StrictHostKeyChecking no IdentityFile ~/.ssh/identity Port 22 Cipher blowfish EscapeChar ~Détaillons un peu ce fichier de configuration :
Host * The option Host restricts all forwarded declarations and options in the configuration file to be only for those hosts that match one of the patterns given after the keyword. The pattern * means for all hosts up to the next Host keyword. With this option you can set different declarations for different hosts in the same ssh_config file.
ForwardAgent no spécifie quel agent d'authentification de connexion devrait être routé vers la machine distante.
ForwardX11 no cette option est pour les personnes qui utilisent les GUI Xwindow et qui veulent rediriger automatiquement leurs sessions X11 sur la machine distante.
RhostsAuthentication noThe option RhostsAuthentication specifies whether we can try to use rhosts based authentication. Because rhosts authentication is insecure you shouldn't use this option.
RhostsRSAAuthentication noThe option RhostsRSAAuthentication specifies whether or not to try rhosts authentication in concert with RSA host authentication.
RSAAuthentication yesThe option RSAAuthentication specifies whether to try RSA authentication. This option must be set to yes for better security on your sessions. RSA uses public and private keys pair created with the ssh-keygen1utility for authentication purposes.
PasswordAuthentication yes Cette option indique si une authentification basée sur les mots de passe doit être utilisée. Pour accroître la sécurité, laisser toujours cette option à yes.
FallBackToRsh no spécifie que si une connexion avec le démon ssh échoue rsh sera utilisé automatiquement à la place. Encore une fois, rsh n'étant pas sécurisé, cette option devrait toujours être mise à no.
UseRsh no indique que les services rlogin/rlogin devrait être utilisé à la place. Pour la même raison que l'option FallBackToRsh, cette option doit être mise à no.
CheckHostIP yes spécifie si oui ou non, le serveur sshd va vérifier l'adresse IP de l'hôte qui essaye de se connecter au serveur afin de déterminer si une usurpation d'identité n'a pas été faite via le DNS spoofing. Il est recommandé de mettre cette option à yes.
StrictHostKeyChecking no indique si oui ou non ssh va inclure directement les nouvelles clés dans le fichier $HOME/.ssh/known_hosts. Lorsque cette option est mise à yes, elle fournie une protection maximale contre les attaques de type chevaux de Troie. Une bonne façon de faire est de mettre cette option à no au début autorisant ainsi ssh à inclure les nouveaux hôtes dans le fichier puis une fois toutes les machines qui ont besoin d'avoir un accès ajoutées au fichier, on remet l'option à yes.
IdentityFile ~/.ssh/identity indique un fichier d'authentification RSA différent à utiliser. On peut également avoir différents fichiers d'identité de spécifiés dans le fichier de configuration ssh_config
Port 22 indique sur quel port ssh doit se connecter. Par défaut, le port 22 est utilisé.
Cipher blowfish spécifie quelle algorithme doit être utilisé pour les sessions cryptées. Bowfish utilise des blocks de 64-bit et des clés allant jusqu'à 448 bits.
EscapeChar ~ indique le caractère de suspension de session.
La première étape est la création d'une clé d'authentification pour vous-même en utilisant la commande ssh-keygen. Les paramètres par défaut conviennent dans la plupart des cas donc vous pouvez les laisser tels quels.
Concernant le mot de passe, rappelez-vous que vous devez en fournir un qui soit relativement difficile à trouver. Cela peut-être plusieurs mots avec ou sans espaces, des phrases avec des fautes d'orthographes ou basées sur la phonétique.
Voici un exemple de session :
$ ssh-keygen -t rsa Generating public/private rsa key pair. Enter file in which to save the key (/home/me/.ssh/id_rsa): [RETURN] Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /home/me/.ssh/id_rsa. Your public key has been saved in /home/me/.ssh/id_rsa.pub. The key fingerprint is: b7:18:db:4c:05:1f:gc:h5:54:2d:6s:3b:1j:82:94:c5 me@localhostSi vous disposez de plusieurs comptes, vous pouvez séparer chaque clé pour chacun des comptes. Par exemple :
environnement de votre travail
vos systèmes privés
vos systèmes chez votre FAI
votre compte à votre université
La modification du mot de passe peut se faire à n'importe quel moment en utilisant l'option -p de ssh-keygen.
$ ssh-keygen -p Enter file in which the key is (/home/me/.ssh/id_rsa): [RETURN] Enter old passphrase: Key has comment '/home/me/.ssh/id_rsa' Enter new passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved with the new passphrase.
![[Astuce]](images/tip.png) | Astuce |
|---|---|
Les mots de passe ne sont pas affichés lorsque vous les tapez ! | |
Comme vous vous en doutez la machine distante doit avoir sshd qui tourne pour pouvoir vous connecter. Voici le message que vous risquez de voir si la machine en face n'est pas accessible :
$>ssh warthawg@192.168.0.101 $>ssh: connect to host 192.168.0.101 port 22: Connection refusedSi sshd tourne de l'autre côté mais c'est la première fois que vous vous connectez, le message suivant devrait apparaître :
The authenticity of host '192.168.0.101 (192.168.0.101)' can't be established. RSA key fingerprint is f0:68:f0:af:3c:75:cd:2a:7f:ae:61:af:a3:fb:7d:79. Are you sure you want to continue connecting (yes/no)?si vous répondez "oui" à cette question, le message suivant apparaîtra :
"Warning: Permanently added '192.168.0.101' (RSA) to the list of known hosts."Cela signifie que le serveur vous a enregistré en tant que contact et a ajouté votre machine à sa liste d'hôtes connus.
Ceci est la première étape d'authentification. Pour se connecter, il est nécessaire d'avoir un compte et un mot de passe sur la machine distante. Lors de la connexion, si vous vous êtes déjà connecté, un message vous indique la date, l'heure et l'adresse IP lors de votre dernière connexion.
Une fois connecté, un prompt vous permet d'exécuter n'importe quelle commande dans la limite des permissions qui vous sont accordées par l'administrateur système de la machine sur laquelle vous vous connectez. Si vous disposez du mot de passe root, vous pouvez utiliser la commande su pour obtenir tous les privilèges sur la machine. Pour mettre fin à une connexion, tapez la commande exit.
Nous allons voir un petit exemple qui va nous permettre de copier des fichiers via le réseau en toute sécurité.
Admettons que vous disposiez d'un certain nombre de photos prises avec votre tout nouveau appareil photo numérique et que vous êtes connecté sur le web depuis votre machine Linux. Un pote, qui lui aussi à Linux chez lui, voudrait voir également les photos. Comment faire pour lui envoyer vos photos avec ssh ? Il suffit d'utiliser scp (Secure Copy) pour copier directement vos photos sur sa machine. Voyons voir la syntaxe complète de la commande à utiliser :
$ scp photos.zip pote@195.234.18.165:/home/pote/Ici le fichier à copier est "photos.zip", le nom d'utilisateur sur la machine distante avec l'adresse ip 195.234.18.165 est pote et le répertoire /home/pote sera le répertoire de destination du fichier copié. La copie de fichier ressemble beaucoup à la commande cp. En effet, on peut également plusieurs fichiers avec une seul commande en faisant comme ceci :
$ scp fichier1 fichier2 ... fichierN pote@195.234.18.165:/home/poteOn peut également copier un répertoire complet avec la commande :
$scp -r repertoire pote@195.234.18.165:/home/pote
N'oublions pas également sftp, le client FTP sécurisé. En fait, sftp n'est rien d'autre qu'un autre client FTP mais qui a l'avantage de crypter toutes les communications mais qui nécessite que sshd tourne sur la machine distante comme pour scp. Pour plus d'informations sur son utilisation et ses options veuillez consulter la page de manuel de sftp.
L'authentification permet de vérifier que la connexion établie est faite depuis un hôte "connu" et non depuis un hôte qui aurait la même adresse que vous ou qui se substiturait à votre identité. SSH vous indique directement si la clé RSA de l'hôte distant ne correspond pas à celle qu'il connaît pour l'adresse ip qui se connecte. Le message qui apparaît est le suivant :
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! Someone could be eavesdropping on you right now (man-in-the-middle attack)! It is also possible that the RSA host key has just been changed. The fingerprint for the RSA key sent by the remote host is 19:76:59:5a:7a:2e:85:95:07:76:dc:32:37:c6:92:0b. Please contact your system administrator. Add correct host key in /home/warthawg/.ssh/known_hosts to get rid of this message. Offending key in /home/warthawg/.ssh/known_hosts:8 RSA host key for 192.168.0.101 has changed and you have requested strict checking. Host key verification failed.Bien sûr ceci ne signifie pas toujours que quelqu'un est en train d'essayer de pirater votre compte. Il se peut qu'une modification de l'adresse IP est été opérée ...
Rsync est un outil permettant de faire des sauvegardes incrémentales.
L'utilisation de SSH avec rsync va nous permettre de faire des sauvegardes via le réseau. Un exemple valant plus qu'un long discours, voila comment procéder :
$ rsync -avz -e ssh utilisateur1@hotedistant:/repertoire_distant /sauvegarde/utilisateur1/Cette commande me permet de sauvegarder le répertoire "répertoire_distant" dans le répertoire "/sauvegarde/utilisateur1/" en utilisant ssh pour crypter les communications entre les deux machines. Il est nécessaire que sshd tourne sur la machine distante pour permettre la connexion et la copie des fichiers. Pour plus d'informations concernant rsync voir la page de manuel.
Commentaires
#1 intéressant.
Sympa à lire.
Ca m'aidera surement pour m'essayer à ce ssh.
J'ai repéré des petites fautes de frappes et ça deborde un chouillat du cadre blanc à droite.
la critique est facile, l'art ...
Bonne continuation. :)
rtm.
#2 PasswordAuthentication yes
PasswordAuthentication yes indique si l'authentification doit se baser sur les mots de passe. Pour une bonne sécurité, cette option doit toujours être mise à yes.
Dans le fichier par défaut de debian c'est marqué le contraire (mot de passe en claire) :
# Change to yes to enable tunnelled clear text passwords
PasswordAuthentication no
#3 Rien sur les tunnels ?
Dommage. C'est une utilisation de SSH qui présente beaucoup d'intérêts. D'accord, ce n'est pas aussi protique qu'un VPN mais ça dépanne.
D'autre part, je ne suis pas du tout d'accord avec le commentaire concernant les mots de passe en clair. Ce qui fait l'intérêt de SSH c'est l'utilisation des clés et non des passwds.
Dans mon sshd_config, j'ai entre autre :
PermitRootLogin no
PasswordAuthentication no
Pour moi, ce sont les deux directives les plus importantes. Ceci force l'utilisation d'une clé. Il faut savoir que lors de l'utilisation des passwords la liaison est cryptée sauf pour l'envoi du mot de passe, contrairemant à SSL qui crypte tout de suite.