« Installation et configuration de OpenSSH » : différence entre les versions

Aller à la navigation Aller à la recherche
aucun résumé des modifications
(Page créée avec « Ce howto a été écrit au départ pour debian etch puis a été adapté pour debian lenny. Il reste cependant valable la plupart du temps pour ces deux versions de debian. O... »)
 
Aucun résumé des modifications
Ligne 80 : Ligne 80 :
* <code>/etc/nologin</code> : Lorsque ce fichier existe, personne ne peut se connecter en ssh à l'exception de root. Le contenu de ce fichier est renvoyé aux personnes essayant de se connecter. Généralement, ce fichier est créé pendant que la machine boot pour éviter que des utilisateurs ne se connectent trop tôt. Si vous avez interdit le login root, ce système peut poser de sérieux problème. Pour le désactiver, il faut commenter la ligne <code>account required pam_nologin.so</code> du fichier <code>/etc/pam.d/ssh</code>.
* <code>/etc/nologin</code> : Lorsque ce fichier existe, personne ne peut se connecter en ssh à l'exception de root. Le contenu de ce fichier est renvoyé aux personnes essayant de se connecter. Généralement, ce fichier est créé pendant que la machine boot pour éviter que des utilisateurs ne se connectent trop tôt. Si vous avez interdit le login root, ce système peut poser de sérieux problème. Pour le désactiver, il faut commenter la ligne <code>account required pam_nologin.so</code> du fichier <code>/etc/pam.d/ssh</code>.
* <code>/etc/hosts.allow</code>, <code>/etc/hosts.deny</code> : La liste des hosts ayant le droit/n'ayant pas le droit de se connecter. Ces fichiers ne concernent pas uniquement ssh, mais toutes les connexions ip.
* <code>/etc/hosts.allow</code>, <code>/etc/hosts.deny</code> : La liste des hosts ayant le droit/n'ayant pas le droit de se connecter. Ces fichiers ne concernent pas uniquement ssh, mais toutes les connexions ip.
=Le fichier AUTHORIZED_KEYS=
Comme nous l'avons dit précédemment, <code>$HOME/.ssh/authorized_keys</code> est le fichier listant les clefs publiques autorisées lors d'une authentification par clé publique.
Chaque ligne de ce fichier est formé de manière à contenir jusqu'à cinq champs séparés par des espaces : options, type de clef, clef (encodée en base64), commentaire.
La version 2 du protocole ssh impose une clé d'au moins 768 bits.
Voici les différentes options que vous pouvez spécifier :
* from= : spécifie le nom canonique de la machine distante. L'opérateur "!" peut être utilisé pour empêcher la connexion si le mot précédé d'un "!" est trouvé. Si un hostname est spécifié, toutes les ips associées à cette hostname seront autorisés.
* command= : spécifie la commande qui doit être exécuté lorsqu'un connexion utilisé cette clé. Celà implique que la commande fournie par le client se connectant sera ignoré.
* no-port-forwarding : interdit les redirections (forwarding) tcp/ip.
* no-X11-forwarding : interdit les redirections (forwarding) X11.
* no-agent-forwarding : interdit les redirections (forwarding) de l'agent d'authentification.
* no-pty : interdit l'allocation d'un terminal.
* permitopen=host:port : limite les redirections de port de manière à ce qu'il ne soit possible de se connecter qu'à l'host:port spécifié.
=Installation d'une clé privé pour se connecter plus facilement au serveur=
==Génération des clés==
Si vous utilisez linux, il vous est possible d'installer une clé ssh sur le serveur afin de ne plus avoir à entrer votre mot de passe à chaque fois que vous souhaitez vous connecter au serveur.
Pour commencer, il faut installer le client OpenSSH sur VOTRE ordinateur. Si vous utilisez debian ou ubuntu :
<pre>aptitude install openssh-client</pre>
Il faut ensuite générer vos clés publique et privée :
<pre>ssh-keygen -t dsa -b 2048</pre>
Ici je génère une clé dsa de 2048 bits. L'algorithme rsa est lui aussi disponible.
Il vous sera posé deux questions. La première vous demandera d'indiquer le chemin où les clés doivent être installés. Vous pouvez laisser le chemin proposé par défaut si vous ne souhaitez utiliser qu'un seul couple de clé. La seconde question vous demande d'entrer la passphrase qui servira à protéger la clé privé. Vous pouvez entrer une passphrase ou non, mais il est recommandé d'en entrer une par mesure de sécurité.
Une fois les clés générées, il va falloir ajouter la clé publique à la liste des clés autorisées par votre serveur. Pour cela, on utilise la commande ssh-copy-id
<pre>
$ ssh-copy-id -i ~/.ssh/id_dsa.pub plouf@hostname
Password:
</pre>
Entrez le mot de passe de l'utilisateur plouf de votre serveur. Si l'opération se passe bien, vous devriez voir le message suivant apparaitre:
<pre>
Now try logging into the machine, with "ssh 'plouf@hostname'", and check in:
.ssh/authorized_keys
to make sure we haven't added extra keys that you weren't expecting.
</pre>
Désormais, si vous tapez ssh plouf@hostname, vous devrez entrer votre passphrase et non plus votre mot-de-passe.
Si vous avez décidé de ne pas préciser de passphrase lors de la création de la clé, vous pourrez vous connecter à votre serveur sans avoir à préciser votre mot de passe ou votre passphrase. Vous pouvez sauter l'étape suivante.
==Automatisation du login==
Si vous avez décidé de chiffrer votre clé avec une passphrase vous avez du remarquer que, pour l'instant, vous n'avez fait que troquer votre mot de passe pour un autre. Mais il est possible de faciliter réellement la connexion à votre serveur en utilisant ssh-agent. ssh-agent va vous permettre de ne plus avoir à ré-entrer votre passphrase à chaque fois que vous voudrez vous reloguez sur votre serveur.
<pre>
ssh-agent bash
ssh-add .ssh/id_dsa
</pre>
La passphrase vous sera redemandé ici. Ensuite, tant que vous ne fermerez pas votre terminal, vous pourrez vous reconnecter à votre serveur en tapant ssh login@host sans avoir à entrer votre mot de passe ou votre passphrase.
Notez que certains environnement graphique (Gnome, kde notamment) gèrent eux-même automatiquement le déblocage des clés privées. Vous n'aurez alors pas besoin de lancer ssh-agent vous même.
=Directives intéressantes du fichiers sshd_config=
La directive <code>Match</code> permet de définir des actions qui ne s'appliqueront qu'à un groupe d'utilisateur. Si vous voulez par exemple forcer un groupe d'utilisateur à se connecter en sftp uniquement (les utilisateurs de ce groupe ne pourront donc plus se connecter en ssh) vous pouvez ajouter les lignes suivantes à la fin du fichier de configuration de sshd :
<pre>
Match Group sftponly
      ChrootDirectory %h
      ForceCommand internal-sftp
      AllowTcpForwarding no
</pre>
Ainsi, tous les membres du groupe sftponly seront obligés de se connecter en sftp. Notez que pour que cela fonctionne il faut que les utilisateurs :
* aient pour groupe primaire sftponly
* que leurs répertoires home appartiennent à root et ne puissent être écrit par aucun autre utilisateur ou groupe.
Vous pouvez aussi changer le shell de ces utilisateurs à /bin/false.
4 206

modifications

Menu de navigation