Ssh

De Le Wiki de debian-fr.xyz
Aller à : navigation, rechercher
Cet article est une ébauche concernant ssh. N'hésitez pas à contribuer ou à en discuter.

Ssh (secure shell) est un programme et un protocole qui permet de se connecter à une machine distante.

Ssh impose un échange de clés de chiffrement en début de connexion; L'utilisation de ssh permet de crypter toutes les données échangées (avec l'algorythme RSA) entre le client et le serveur, rendant ainsi impossible tout "sniff" des paquets.

Avec Telnet et rlogin toutes les données qui transitent entre le client et le serveur sont en clair. N'utilisez donc pas Telnet et/ou rlogin et désinstallez les!

Il est préférable d'éviter de se connecter au système en utilisant ssh en tant que root et préférer l'utilisation de méthodes alternatives pour devenir root tel su ou sudo.

Installation

Installation du client Normalement, le client est installé par défaut, sinon il suffit de saisir en root

# aptitude update
# aptitude install openssh-client

Installation serveur La partie serveur permet à des hôtes distants de se connecter à votre système.

# aptitude update
# aptitude install openssh-server

utilisation

Pour établir une connexion sur un serveur il faut être en possession d'un identifiant et d'un mot de passe valide sur celui-ci. Ouvrez un terminal et tapez :

$ ssh utilisateur@ip_ou_nom_du_serveur

Si le serveur utilise un port différent que le 22, on ajoute -p num_du_port Le serveur demande un mot de passe, vous vous trouvez maintenant (si tout s'est bien passé) sur le serveur. exit permet de quitter la machine distante, la console revient sur la machine locale.

Connexion avec des clefs

Les clefs permettent de se connecter à un serveurs sans utiliser le mot de passe de la session distante. Ce procédé consiste à créer des jeux de clefs (une clef publique et une clef privée) pour chaque serveur à contrôler. La clef publique doit être envoyée à la machine distante, la privée ne doit jamais être divulguée.

Pour créer une paire de clefs :

$ ssh-keygen -t ed25519 #les autres méthodes méthodes de chiffrage : ecdsa, ed25519, rsa, rsa1

 AVERTISSEMENT : Les clés DSA sont considérées maintenant comme vulnérables et ne sont pas prises en compte par défaut par les dernières versions d'OpenSSH (à moins de le préciser dans le fichier de configuration), il faut donc utiliser des clés ECDSA ou ed25519, cette dernière étant considérée comme la plus performante.

Il vous est proposé de choisir la destination et le nom de vos clefs. Tapez [entrer] pour valider la proposition par défaut ou entrez le chemin complet et le nom de la clef. Saisissez ensuite une passphrase (différent de votre mot de passe habituel !) Si ce champ reste vide, la connexion au serveur ne nécessitera la saisie d'aucun mot de passe. (Il est conseillé de créer des paires de clefs différentes pour chacun de vos serveurs) Dans le cas où vos clefs ne sont pas protégées par passphrase, et que votre clef privée venait à être découverte, toutes les machines ayant la clef publique associée seront accessibles sans aucune protection à celui qui détient cette clef !

Exemple :

$ ssh-keygen -t ed25519
Generating public/private dsa key pair.
Enter file in which to save the key (/home/user/.ssh/id_ed25519 : /home/user/.ssh/serveur_test 

Enter passphrase (empty for no passphrase): (aucun caractère n'apparaît lors de la saisie !)
Enter same passphrase again:
Your identification has been saved in serveur_test.
Your public key has been saved in serveur_test.pub.
The key fingerprint is:
cf:95:21:75:ad:80:ed:5d:50:04:ff:c5:f2:4a:ca:45 utilisateur@ip_ou_nom_du_serveur
The key's randomart image is:
+---[DSA 1024]----+
|           o. +*o|
|          ..o. oo|
|          ...o.o+|
|           ..+ooo|
|        S  .. o o|
|         o o + . |
|          ... .  |
|                 |
|                 |
+-----------------+


Envoyer la clef publique sur le serveur :

$ ssh-copy-id -i ~/.ssh/serveur_test.pub utilisateur@ip_ou_nom_du_serveur

Le serveur demande de valider l’empreinte en tapant 'yes', puis le mot de passe de la session utilisateur.

The authenticity of host 'ip_ou_nom_du_serveur (::1)' can't be established.
ECDSA key fingerprint is d1:49:49:3c:e9:dc:d5:dc:dc:db:9e:dc:08:7b:48:d1.
Are you sure you want to continue connecting (yes/no)? yes
utilisateur@ip_ou_nom_du_serveur's password: ******

Number of key(s) added: 1

Now try logging into the machine, with:   "ssh 'ip_ou_nom_du_serveur'"
and check to make sure that only the key(s) you wanted were added.


Se connecter en utilisant les clefs : Avant de se connecter, il faut charger et déverrouiller la clef privée avec la passphrase :

$ ssh-add ~/.ssh/serveur_test
Enter passphrase for .ssh/serveur_test: (tapez la passphrase)
Identity added: .ssh/serveur_test (.ssh/serveur_test)

/!\ la cléf sera chargée jusqu'à fermeture de cette console

La connexion au serveur ne nécessite plus de mot de passe maintenant

comptelocal@user-pc:/home/comptelocal$ ssh utilisateur@ip_ou_nom_du_serveur

utilisateur@ip_ou_nom_du_serveur:/home/utilisateur$ 

Vous pouvez alors désactiver la connexion par mot de passe dans le fichier /etc/sshd_config sur le serveur

Ca ne marche pas ?!

Ajouter -v, vv ou -vvv (plus il y a de v, plus il y aura des détails dans la console). Cela devrait permettre de détecter la raison du problème rencontré.

$ ssh ip_ou_nom_du_serveur -v
OpenSSH_6.7p1 Debian-5+deb8u2, OpenSSL 1.0.1k 8 Jan 2015
debug1: Reading configuration data /home/user/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to localhost [::1] port 22.
debug1: Connection established.
...
debug1: kex: client->server aes128-ctr umac-64-etm@openssh.com none
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ECDSA c1:49:49:3c:e9:30:d5:b9:f8:db:9e:dc:08:7b:48:d1
debug1: Host 'localhost' is known and matches the ECDSA host key.
debug1: Found key in /home/user/.ssh/known_hosts:17
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Trying private key: /home/user/.ssh/id_rsa
debug1: Trying private key: /home/user/.ssh/id_dsa
debug1: Trying private key: /home/user/.ssh/id_ecdsa
debug1: Trying private key: /home/user/.ssh/id_ed25519
debug1: Next authentication method: password
user@ip_ou_nom_du_serveur's password:
...


fichier de configuration

Le fichier /etc/ssh/sshd_config doit être modifié comme suit pour accroître la sécurité.

Pour prendre en compte les modifications apportées à ce fichier, il faut redémarrer ssh :

$ sudo /etc/init.d/ssh restart
# ou pour systemd
$ sudo systemctl restart ssh

Ne faîtes écouter ssh que sur une interface donnée:

ListenAddress 192.168.0.1

Ne pas autoriser de connexion en tant que root. Si quelqu'un veut devenir root via ssh, deux logins sont maintenant nécessaires et le mot de passe root ne peut être attaqué par la force brute via SSH.

PermitRootLogin no

Changer le port d'écoute, ainsi l'intrus ne peut être complètement sûr de l'exécution d'un démon sshd (c'est de la sécurité par l'obscurité).

Port 666

ou

ListenAddress 192.168.0.1:666

Les mots de passe vides sont un affront au système de sécurité.

PermitEmptyPasswords no

N'autoriser que certains utilisateurs à avoir accès via ssh à cette machine. Pour encore plus de sécurité, user@host peut également être utilisé pour n'autoriser l'accès qu'à un utilisateur donné depuis un hôte donné.

AllowUsers lol laurent@sidlol

Autorise seulement certains membres de groupes à avoir accès via ssh à cette machine. AllowGroups et AllowUsers ont des directives équivalentes pour interdire l'accès à la machine. Sans surprise elles s'appellent « DenyUsers » et « DenyGroups ».

AllowGroups wheel admin

Sécurisation par clef Il vous appartient ici de décider ce que vous voulez faire.

Mais il est plus sûr de n'autoriser l'accès à la machine qu'aux utilisateurs en possession de cléfs ssh placées dans le fichier ~/.ssh/authorized_keys. Si c'est ce que vous voulez, positionnez cette option à "no".

PasswordAuthentication yes

Utilisation de clefs et raccourcis ssh

En général, désactiver toute forme d'autorisation dont vous n'avez pas réellement besoin (RhostsRSAAuthentication, HostbasedAuthentication, KerberosAuthentication, ...)

RhostsRSAAuthentication no
HostbasedAuthentication no
KerberosAuthentication no

Désactiver le protocole version 1, car il a des défauts de conception qui facilite le crack de mots de passe. Pour plus d'informations, lisez un article concernant les problèmes du protocole ssh ou le bulletin d'alerte Xforce.

Protocole 2

Ajoutez une bannière (elle sera récupérée du fichier) pour les utilisateurs se connectant au serveur ssh. Dans certains pays, envoyer un avertissement avant l'accès à un système est obligatoire pour avoir une protection légale.

La bannière par défaut se trouve dans /etc/modt

Vous pouvez aussi y mettre ce que vous voulez...


       _,met$$$$$gg.
     ,g$$$$$$$$$$$$$$$P.
   ,g$$P""       """Y$$.".
  ,$$P'              `$$$.
',$$P       ,ggs.     `$$b:
`d$$'     ,$P"'   .    $$$
 $$P      d$'     ,    $$P
 $$:      $$.   -    ,d$$'      
 $$;      Y$b._   _,d$P'             _,           _,      ,'`.
 Y$$.    `.`"Y$$$$P"'              `$$'         `$$'     `.  ,'
 `$$b      "-.__                    $$           $$        `'
  `Y$$b                             $$           $$         _,           _
   `Y$$.                      ,d$$$g$$  ,d$$$b.  $$,d$$$b.`$$' g$$$$$b.`$$,d$$b.
     `$$b.                   ,$P'  `$$ ,$P' `Y$. $$$'  `$$ $$  "'   `$$ $$$' `$$
       `Y$$b.                $$'    $$ $$'   `$$ $$'    $$ $$  ,ggggg$$ $$'   $$
         `"Y$b._             $$     $$ $$ggggg$$ $$     $$ $$ ,$P"   $$ $$    $$
             `""""           $$    ,$$ $$.       $$    ,$P $$ $$'   ,$$ $$    $$
                             `$g. ,$$$ `$$._ _., $$ _,g$P' $$ `$b. ,$$$ $$    $$
                              `Y$$P'$$. `Y$$$$P',$$$$P"'  ,$$. `Y$$P'$$.$$.  ,$$.


A des fins de simple contrôle il est fortement conseillé de laisser l’option suivante sur "yes"

Elle vous permet de vérifier très simplement le dernier "login"

PrintLastLog yes

Restriction par pam

Vous pouvez également restreindre l'accès au serveur ssh en utilisant pam_listfile ou pam_wheel dans le fichier de contrôle PAM.

Par exemple, vous pourriez bloquer tous les utilisateurs qui ne sont pas dans /etc/loginusers en ajoutant cette ligne à /etc/pam.d/ssh :

    auth       required     pam_listfile.so sense=allow onerr=fail item=user file=/etc/loginusers

Faire du déport d'affichage

Il s'agit ici d'activer l'option X11Forwarding qui permet d'éxecuter à distance des applications graphiques et de les afficher localement. Assurez-vous que l'option ci-dessous est bien activée:

X11Forwarding yes

Le déport d'affichage nécessite une bonne connexion réseau (en effet le serveur envoie des images du serveur vers le client).

Le client se connecte avec l'option -X

$ ssh -X utilisateur@serveur

Cette option est activée par défaut, si vous n'en avez pas besoin (et pour des raisons de sécurité) pensez à la désactiver

X11Forwarding no

Liens externes

Lol 3 août 2011 à 03:01 (CDT)