Ssh

De ArchwikiFR


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

Client

Le client se configure à l'aide du fichier /etc/ssh/ssh_config.

man ssh_config

Serveur

Configuration dans le fichier /etc/ssh/sshd_config.

man sshd_config

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)
Note : Si vous utilisez un pare-feu (iptables par exemple), il vous faudra autoriser l'accès au port 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).

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é [[1]]:

 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
Astuce : ssh-copy-id n'est qu'un script qui copie le contenu de la clé dans le bon fichier avec les bonnes permissions.

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
Note : sshfs utilise fuse, si besoin, vous pouvez le rajouter aux modules chargés au démarrage.
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
Note : La variable 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 :

Fichier: ~/.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).
 [...]