SSH

Cette page présente les usages les plus courants de SSH et sa configuration de base.

Voir sur SSH Avancé pour les autres usages.

OpenSSH est une version libre de la suite de protocole de SSH, des outils de connectivité de réseau sur lesquels un nombre croissant de personnes sur l'Internet viennent s'appuyer. Beaucoup d'utilisateurs de Telnet, Rlogin, FTP, ou d'autres programmes de même acabit ne se rendent pas compte que leur mot de passe est transmis à travers les réseaux en clair ce qui constitue une faille évidente dans la sécurité de leur réseau. Avec ces anciens protocoles, les données sont également transmises en clair.

OpenSSH chiffre tout le trafic (mots de passe y compris), via une combinaison astucieuse de cryptage symétrique et asymétrique. OpenSSH fournit également d'autres méthodes d'authentifications alternatives au traditionnel mot de passe.
Comme son nom l'indique, OpenSSH est développé dans le cadre du projet OpenBSD

SSH remplace de manière sécurisée:

• Telnet: Vous pouvez exécuter des commandes depuis un Réseau Local ou Internet via SSH
• FTP: Si vous ne souhaitez qu'ajouter ou modifier des fichiers sur un serveur, SSH est bien plus adapté que FTP
• Et d'autres, via le tunneling: SSH permet d'accéder à un service réseau en le faisant circuler dans SSH pour profiter de toutes les protections qu'il apporte. Vous pouvez donc sécuriser n'importe quel protocole grâce à SSH, comme VNC par exemple.

SSH permet de faire, en usage de base :

• Accès à distance sur la console en ligne commande (shell), ce qui permet, entre autres, d'effectuer la totalité des opérations courantes et/ou d'administration sur la machine distante.
• Déporter l'affichage graphique de la machine distante.
• Transferts de fichiers en ligne de commande.
• Montage ponctuel de répertoire distants, soit en ligne de commande, soit via Nautilus, sous Gnome par exemple.
• Montage automatique de répertoires distants.

Si vous voulez accéder à un ordinateur (votre ordinateur personnel, votre serveur local, un serveur distant dont vous effectuez l'administration, etc.) vous devez installer openssh-server sur la machine à joindre en SSH, qui sera le "serveur". Il vous faudra installer sur la machine qui commande, le "client", openssh-client.

installez le paquet openssh-server sur votre poste.

Par défaut, il se lance au démarrage.

Pour l'activer après une fausse manipulation :

sudo service ssh start

Pour l'arrêter :

sudo service ssh stop

Sur le poste client (qui va prendre l'accès à distance) openssh-client, installé par défaut sous Ubuntu, doit être présent.

Clients pour machines qui ne sont pas sous Linux :

Si vous devez prendre le contrôle depuis un poste équipé de Windows vous pouvez installer PuTTY qui est disponible sous licence MIT (une licence libre comparable à la licence BSD).

Si vous voulez établir une connexion ssh depuis un smartphone Blackberry®, vous pouvez installer bbssh, qui est sous licence libre GPLv2, les sources sont fournies.

ufw status

Pour ouvrir une session sur un ordinateur distant ayant un serveur SSH, vous devez écrire quelque chose comme ceci :

ssh <nom_utilisateur>@<ipaddress> -p <num_port>

Exemple :

ssh phyrex@192.168.23.42 -p 12345

L'option -p xxx est facultative. Si rien n'est précisé, c'est le port 22 qui sera utilisé par défaut.

Pour se connecter avec ssh en ipv6 depuis un terminal, écrire sans crochet :

ssh -6 <nom_utilisateur>@<adresse ipv6> 

soit par exemple pour un lien Internet :

ssh -6 alfred@2a01:e35:2431::2e57   

ssh utilisateur@nom_machine

La commande ssh offre un joker inattendu : on peut exécuter des applications X-Windows à distance. Cela est bien pratique pour travailler loin de chez soi, partager une machine ou simplement faire de l'entretien.

ssh -X nomUtilisateur@Ipserver

L'option -X permet la déportation de l'application X-Window (affichage graphique à distance). Ceci est possible grâce aux fonctions de tunneling réseau dont dispose SSH. N'oubliez pas que Ubuntu (Unix en général) travaille en mode client/serveur et cela s'applique aussi à l'affichage géré par X-Window.

ssh -x nomUtilisateur@Ipserver

Pour copier un fichier à partir d'un ordinateur sur un autre avec SSH, vous devrez utiliser la commande scp. Cela ressemblera à ceci :

scp <fichier> <username>@<ipaddressDistant>:<DestinationDirectory>
scp -6 <élément> <nom>@[addresse ipv6]:<destination>  

Ou en termes profanes, si l'on désirait copier un fichier d'un ordinateur à un autre, il faudrait procéder de cette manière :

scp fichier.txt hornbeck@192.168.1.103:/home/hornbeck 
scp -6 fichier.txt albertine@[2a01:e35:2431::2a34]:/home/albertine 

Ou copier un répertoire vers un ordinateur :

scp -r répertoire hornbeck@192.168.1.103:/home/hornbeck/
scp -6r répertoire/ albertine@[2a01:e35:2431::2a34]:/home/albertine 

Vous pouvez aussi bien copier des fichiers à partir des ordinateurs à distance sur votre disque local :

scp hornbeck@192.168.1.103:/home/hornbeck/urls.txt .

Le point à la fin de commande indique de copier le fichier dans le répertoire courant. Vous pouvez aussi le renommer en le copiant (« mon.txt ») sur le disque local :

scp hornbeck@192.168.1.103:/home/hornbeck/urls.txt ./mon.txt

Vous pouvez très bien copier un fichier d'un ordinateur vers un autre tout en étant sur un troisième ordinateur :

scp nom@ordi1:chemin/fichier nom@ordi2:chemin/fichier

Dans le cas où le port SSH du serveur ne serait pas le port par défaut (22), il faut indiquer le port distant à utiliser :

scp -P port fichier.txt hornbeck@192.168.1.103:/home/hornbeck

SFTP est une autre méthode pour accéder à ses fichiers via SSH, au lieu de travailler fichier par fichier, il est possible via cette méthode de naviguer dans ses fichiers grâce à un client SFTP. Ce type d'accès est possible grâce aux outils suivants :

En utilisant le navigateur de fichier Nautilus, vous pouvez également accéder aux emplacements à distance par l'intermédiaire de SSH pour passer en revue, modifier et copier des fichiers. Ouvrez Nautilus, puis dans la fenêtre emplacement (Ctrl–L), entrez l'URL suivante (remplacez nom_utilisateur, hostname et port en conséquence) :

 ssh://nom_utilisateur@hostname:port

La copie de fichier se fait avec le glisser-déposer dans la fenêtre de Nautilus comme sur votre système de fichiers local.

Pour accéder directement à un répertoire donné (pratique avec l'utilisation des signets), il suffit de rajouter le chemin en fin d'URL :

 ssh://username@hostname:port/le/chemin/voulu/

Il est également possible d'y avoir accès dans Nautilus par : Fichier > Se connecter à un serveur… et choisir le Type de service « ssh ».

Le principe est similaire à celui utilisé par Nautilus, à l'exception du nom de protocole : fish. Dans la barre d'adresse, tapez :

fish://<nom_utilisateur>@<hostname>

Une boîte de dialogue apparaîtra et demandera le mot de passe.

Attention, si vous ne mentionnez pas le nom d'utilisateur, c'est l'utilisateur courant sur la machine locale qui aura la main.

Le nouveau navigateur de KDE permet de faire ça très simplement. Cliquez sur le raccourci Réseau, puis Ajoutez un dossier réseau. Remplissez ensuite les champs demandés (n'oubliez pas que votre adresse se trouve par ifconfig, à inet adr:xxx.xxx.x.xx dans eth1 en général), et pensez à mettre la racine (/) comme dossier d'accès pour pouvoir rentrer sur l'intégralité de l'ordinateur distant.

Il est également possible de rentrer l'adresse et d'enregistrer le lien dans ses emplacements favoris :

sftp://nom_utilisateur@hostname:port

Parce qu'il est parfois nécessaire de faire un transfert de fichier à partir d'une machine sous MS Windows, il existe un logiciel libre nommé WinSCP qui permet de faire du SFTP (transfert de fichier par SSH) avec une interface semblable à celle des clients FTP.

Site officiel du logiciel WinSCP

Sans avoir à chercher trop loin, FileZilla, le client FTP compatible Linux, Windows et Mac OS X, permet aussi la connexion à un serveur SFTP (SSH File Transfer Protocol) depuis la version 3.

SSHFS est un outil permettant d'utiliser le protocole ssh comme un système de fichier et ainsi monter un répertoire distant à travers le protocole ssh pour y accéder comme n'importe quel répertoire local à la manière d'un partage NFS : Network File System - le partage réseau sous Linux; mais sécurisé !
Voir la page SSH Filesystem.

L'authentification par mot de passe (transmis chiffré) est le mode d'identification par défaut.

Suite à l'installation du paquet openssh-server il peut parfois être nécessaire de modifier le fichier de configuration /etc/ssh/sshd_config notamment si vous rencontrez le problème suivant :

moi@maison:~$ ssh user@domain.com
Permission denied (publickey).

Dans ce cas, il faut très simplement modifier le fichier /etc/ssh/sshd_config de la manière suivante :

# Change to yes to enable tunnelled clear text passwords
PasswordAuthentication **yes**

Puis en cas de modifications, redémarrer le service avec la commande :

sudo /etc/init.d/ssh restart

Autrefois tout le monde employait l'authentification typique via identifiant-mot de passe. Cependant si quelqu'un connaît votre mot de passe, la sécurité est compromise.

Pour être débarrassé du problème, SSH offre l'Authentification par clé publique/privée au lieu des mots de passe « simples ». De cette manière, il faut être en possession de non plus une mais de deux informations pour se connecter (avoir la clé privée et connaître le mot de passe de cette clé).

Ceci peut permettre par exemple :

• à un administrateur de se connecter à des centaines de machines sans devoir connaître des centaines de mots de passe différents ;
• de ne pas avoir un mot de passe à saisir toutes les 2 minutes (en utilisant ssh-agent).

À moins que vous n'ayez déjà un couple de clés, vous devez d'abord en créer : exemple pour une clé utilisant le protocole de chiffrage RSA. Tapez chez le client :

ssh-keygen -t rsa

Il vous sera alors demandé où sauver la clé privée (acceptez juste l'endroit par défaut : ~/.ssh, et ne changez pas le nom) puis de choisir une passphrase (phrase de reconnaissance). Bien que non obligatoire, l'utilisation d'une passphrase est recommandée pour protéger votre clé privée. En effet toute personne qui obtiendrait l'accès à votre clé privée (non protégée) aurait alors vos permissions sur d'autres ordinateurs. Veuillez prendre un instant et choisissez une très bonne passphrase.

Votre clef publique a été créée avec la nouvelle clé privée. Elles sont habituellement localisées dans le dossier caché ~/.ssh/id_rsa.pub pour la clé publique et ~/.ssh/id_rsa pour la clé privée.

Il faut maintenant envoyer au serveur votre clé publique pour qu'il puisse vous chiffrer des messages.

L'utilisateur distant doit avoir cette clé (c'est une ligne de caractères en code ASCII) dans son fichier de clés d'autorisation situé à ~/.ssh/authorized_keys sur le système distant. Employez la commande ssh-copy-id.

ssh-copy-id est un script qui utilise ssh pour se connecter à une machine à distance en utilisant le mot de passe de l'utilisateur. L'authentification par mot de passe "PasswordAuthentication yes" doit donc être autorisée dans le fichier de configuration du serveur ssh (par défaut sur Ubuntu). Il change également les permissions des répertoires : ~/.ssh, et ~/.ssh/authorized keys de l'hôte distant pour enlever l'accès en écriture du groupe (qui vous empêcherait de vous connecter si le serveur distant ssh a "StrictModes yes" dans son fichier de configuration, ce qui est le cas par défaut sur Ubuntu).

ssh-copy-id -i ~/.ssh/id_rsa.pub <username>@<ipaddress>

ou si le port est différent du port standard 22 :

ssh-copy-id -i ~/.ssh/id_rsa.pub "<username>@<ipaddress> -p <num_port>"

Vous devrez alors donner le mot de passe utilisateur de cet ordinateur. Après que votre clé publique ait été ajoutée, vous devenez un hôte de confiance.

Si l'authentification par mot de passe est désactivée, alors vous aurez besoin de copier-coller votre clé suivant un autre moyen.

Voici une ligne à copier pour ajouter sa clé publique sur le serveur distant :

ssh login@serveur "echo $(cat ~/.ssh/id_rsa.pub) >> .ssh/authorized_keys"

Lancez :

ssh <username>@<ipaddress> -p <num_port>

Dorénavant n'utilisez plus votre mot de passe mais votre passphrase pour vous connecter. Cette-ci sert à déchiffrer votre clé privée de votre système local.

Si ça ne marche pas, c'est-à-dire que le mot de passe vous est quand même demandé, essayez sur votre serveur la commande :

tail -f /var/log/auth.log

tandis que vous essayez de vous connecter. Si on vous parle de "vulnkey", c'est que par malchance ssh-keygen a généré une clé vulnérable. Recommencez alors la manipulation à partir de ssh-keygen…

Pour reprendre, deux choses sont nécessaires pour obtenir un accès réellement sécurisant (et sécurisé ) par authentification à clé publique par rapport à l'authentification par mot de passe classique :

1. Votre clé privée, chiffrée ;
2. Votre passphrase, utilisée pour déchiffrer votre clé privée.

Si vous choisissez de ne pas avoir de mot de passe (ce qui est possible, voyez la prochaine section), vous aurez une sécurité moindre, ainsi que si vous utilisez une authentification uniquement par mot de passe, comparé à celle que vous pouvez avoir en combinant les deux.

sudo /etc/init.d/ssh restart

tail /var/log/auth.log

Authentication refused: bad ownership or modes for directory /home/votre_login

chmod 755 $HOME

server$ chmod go-w ~/
server$ chmod 700 ~/.ssh
server$ chmod 600 ~/.ssh/authorized_keys

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    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
xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx.
Please contact your system administrator.
Add correct host key in /home/<vous>/.ssh/known_hosts to get rid of this message.
Offending key in /home/<vous>/.ssh/known_hosts:4
RSA host key for <ip> has changed and you have requested strict checking.
Host key verification failed.

ssh-keygen -R <ip>

Lorsque l'on se connecte à plusieurs serveurs, certains avec clé cryptée, d'autres avec clé en clair, il faut pouvoir indiquer à ssh quelle clé on veut utiliser pour la connexion.

Pour indiquer au client ssh la clé qu'il doit utiliser pour chacun des serveurs il faut créer le fichier ~/.ssh/config (ou /etc/ssh/ssh_config pour tous les utilisateurs de la machine) dans lequel il faut spécifier pour chacun des serveurs la clé qui doit être utilisée :

Host adresse-serveur-sans-passphrase.com
User votreutilisateur
IdentityFile ~/.ssh/key-sans-passphrase

Host adresse-serveur-avec-passphrase.com
User votreutilisateur
IdentityFile ~/.ssh/key-avec-passphrase

l'astuce pour différencier les clefs avec passphrase de celles sans passphrase, serait de créer une clef de type ECDSA pour les identifications sans passphrase et DSA pour les identifications avec passphrase.

Ce qui donnerait : IdentityFile ~/.ssh/id_ecrsa.pub pour le premier, et: IdentityFile ~/.ssh/id_rsa.pub pour le second

Retrouver l'empreinte de notre clef ssh, pour la communiquer à une personne qui veut se connecter et va utiliser notre clef publique :

$ ssh-keygen -l

Ensuite la commande demande le fichier de la clef publique. Sur un serveur on spécifiera /etc/ssh/ssh_host_rsa_key.pub.

Par défaut, la configuration du serveur SSH (fichier « /etc/ssh/sshd_config », édition via sudo comme il se doit) d'Ubuntu est suffisante. Ci dessous le fichier par défaut, sans les lignes d'explications:

                               Fichier : /etc/ssh/sshd_config                         
Port 22
#ListenAddress ::
#ListenAddress 0.0.0.0
Protocol 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
UsePrivilegeSeparation yes
KeyRegenerationInterval 3600
ServerKeyBits 768
SyslogFacility AUTH
LogLevel INFO
LoginGraceTime 120
PermitRootLogin no
StrictModes yes
RSAAuthentication yes
PubkeyAuthentication no
#AuthorizedKeysFile     %h/.ssh/authorized_keys
IgnoreRhosts yes
RhostsRSAAuthentication no
HostbasedAuthentication no
#IgnoreUserKnownHosts yes
PermitEmptyPasswords no
ChallengeResponseAuthentication no
PasswordAuthentication yes
# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes
X11Forwarding no
X11DisplayOffset 10
PrintMotd no
PrintLastLog yes
TCPKeepAlive yes
#UseLogin no
#MaxStartups 10:30:60
#Banner /etc/issue.net
AcceptEnv LANG LC_*
Subsystem sftp /usr/lib/openssh/sftp-server
UsePAM yes

Tableau des directives à modifier le cas échéant :

Informations et éléments de configurations sécuritaires avancées, voir cyberciti