Ssh
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
- (fr) Site Web d'OpenSSH
- (fr) Sécurisation de ssh
Lol 3 août 2011 à 03:01 (CDT)