Secure Shell (Français)
Le SSH (Secure SHell) est un protocole qui permet d’établir une connexion sécurisée avec un autre ordinateur.
Installation
Le client/serveur le plus populaire sous GNU/Linux est OpenSSH, ça tombe bien, c'est ce qui est proposé par Arch Linux:
pacman -S openssh
Configuration
Le client se configure à l'aide du fichier /etc/ssh/ssh_config
documenté à la page ssh_config(5).
Le serveur se configure via le fichier /etc/ssh/sshd_config
documenté par sshd_config(5).
Brièvement, quelques exemples:
Option | Valeur | Description |
---|---|---|
PermitRootLogin | no | évite la connexion root |
PasswordAuthentication | no | désactive la connexion par mot de passe |
PermitEmptyPasswords | no | désactive les mots de passe vide |
UsePAM | no | désactive la connexion par le biais du module PAM |
AllowUsers | votre_login second_login | restreint l'accès aux utilisateurs indiqués uniquement |
AllowGroups | votre_groupe | restreint l'accès aux groupes indiqués uniquement |
DenyUsers | test guest admin root snort apache nobody | interdire l'accès à certains users, pour les paranos... |
DenyGroups | test guest admin root snort apache nobody | interdire l'accès à certains groupes, pour les paranos... |
MaxStartups | 1 | Limite le nombre de tentatives de connections concurrentes à 1 (10 par défaut) |
ssh
(22 par défaut).Utilisation
Basique
Il existe deux possibilités selon votre usage:
- avec
sshd.service
, le serveur tournera en permanence. - avec
sshd.socket
, le serveur ne démarre qu'à la première connexion entrante (pratique pour un usage occasionnel).
- avec
Ainsi, pour lancer le service au démarrage:
systemctl enable sshd.service
ou
systemctl enable sshd.socket
Connexion au serveur:
ssh utilisateur@serveur
Connexion avec possibilité de lancer des applications graphique:
ssh -Y utilisateur@serveur
Clé publique/privée
Vous pouvez éventuellement vous passer du mot en passe en créant une clé, exemple avec une clé ED25519:
ssh-keygen -t ed25519
Votre clé sera générée dans le dossier $HOME/.ssh/
, pour la mettre en place, il vous suffit de l’exporter sur le serveur SSH:
ssh-copy-id -i ~/.ssh/id_ed25519.pub utilisateur@serveur
Par contre la commande ne prend pas les paramètres habituels de ssh tels que le port par exemple; pour contourner, il suffit d'entourer par des ':
ssh-copy-id -i ~/.ssh/id_dsa.pub '-p port utilisateur@serveur'
On peut aussi la transférer sur un support amovible ou avec un autre moyen de copie:
< emplacement_du_fichier >> ~/.ssh/authorized_keys chmod 600 ~/.ssh/authorized_keys
Votre clé est maintenant en place, une connexion ne devrait plus demander de mot de passe.
Informations de connexion
Il est possible de sauvegarder les informations qu'on tape à chaque fois si on se connecte souvent au même serveur dans le fichier $HOME/.ssh/config
, exemple:
Host serveur_perso HostName x.x.x.x Port port_particulier User moimeme
Ainsi, un:
ssh -p port_particulier moimeme@x.x.x.x
pourra être remplacé par:
ssh serveur_perso
Système de fichier distant
SSH à l'aide de sshfs permet de monter un dossier distant:
pacman -S sshfs modprobe fuse
mkdir ~/dossier_distant sshfs utilisateur@serveur:dossier_sur_serveur ~/dossier_distant
Pour démonter le dossier, lancez la commande suivante:
fusermount -u ~/dossier_distant
Problèmes de connexion
L'utilisation d'une clé pour s'identifier ne fonctionne pas avec l'option -i comme avec la commande ssh. Il faut écrire -o IdentityFile=<cle-privée> à la place. Sinon un message "Connection reset by peer" apparaît. Attention, la documentation anglophone cite d'autres problèmes qui mènent à ce message d'erreur.
Si la connexion se perd, ce message peut arriver : "fuse: bad mount point - Transport endpoint is not connected". Pour forcer le démontage sshfs :
- Tuer le processus sshfs
- Démonter le système de fichiers avec umount -l <rép-local>
- Remonter le système de fichiers
Si ce problème se produit souvent, les options suivantes pourraient être utiles : reconnect et workaround=all :
sshfs -o reconnect,workaround=all,IdentityFile=cle_privee utilisateur@serveur:rep_local rep_distant
Tunnel Socks
Vous pouvez utiliser ssh pour faire transiter votre trafic réseau par un tunnel. Prenons par exemple le cas où vous avez un serveur ssh accessible depuis l'extérieur et que vous êtes connecté à un réseau wifi non sûr:
ssh -ND 8888 utilisateur@serveur
Une fois la commande lancée, il faut soit configurer les applications pour passer par ce tunnel, soit utiliser un programme tel que tsocks.
Modifier le fichier $HOME/.tsocks.conf
comme suit:
server = localhost server_port = 8888
puis lancez par exemple midori comme ceci:
TSOCKS_CONF_FILE=$HOME/.tsocks.conf tsocks midori
TSOCKS_CONF_FILE
peut bien sûr être exportée dans le .bashrc
par exemple.
Par défaut tsocks
utilise le fichier de configuration /etc/tsocks.conf
.Accès à un serveur local
SSH permet de faire suivre un service local au réseau du serveur vers le client, un exemple concret serait par exemple de pouvoir accéder en VNC à une machine sur le réseau local du serveur:
ssh -L 5901:ip_machine:5900 utilisateur@serveur
Il suffit ensuite de taper:
vncviewer localhost:5901
Dans le cas contraire où on voudrait que ça soit le serveur qui accède à un service du réseau local du client, il suffit de taper:
ssh -R 5900:ip_machine:5901 utilisateur@serveur
Bonnes pratiques
Utiliser des clefs le plus possible
Les clefs sont basées sur la cryptographie asymétrique et sont nettement moins sujettes au cassage qu'un mot de passe. On prendra bien garde à toujours protéger ses clefs SSH par une passphrase.
Utiliser une clef par serveur par client
La syntaxe de ssh_config
est détaillée dans man 5 ssh_config
et permet de facilement paramétrer SSH à cette fin. Par exemple, cet extrait ferra que SSH cherchera une clef du nom du serveur contacté afin de tenter une connexion par clef publique :
~/.ssh/config
IdentityFile ~/.ssh/%h
% ssh -v git@ssh.github.com OpenSSH_7.0p1, OpenSSL 1.0.2d 9 Jul 2015 debug1: Reading configuration data /home/moviuro/.ssh/config debug1: Reading configuration data /etc/ssh/ssh_config [...] debug1: Connecting to ssh.github.com [192.30.252.148] port 22. debug1: Connection established. debug1: identity file /home/moviuro/.ssh/ssh.github.com type 4 debug1: key_load_public: No such file or directory debug1: identity file /home/moviuro/.ssh/ssh.github.com-cert type -1 debug1: Enabling compatibility mode for protocol 2.0 [...] debug1: Host 'ssh.github.com' is known and matches the RSA host key. debug1: Found key in /home/moviuro/.ssh/known_hosts:138 [...] debug1: Authentications that can continue: publickey debug1: Next authentication method: publickey debug1: Offering ED25519 public key: /home/moviuro/.ssh/ssh.github.com debug1: Server accepts key: pkalg ssh-ed25519 blen 51 debug1: Authentication succeeded (publickey). Authenticated to ssh.github.com ([192.30.252.148]:22). [...]