SSH

[vohu]

je compléterai cette page au fur et à mesure

Utilisation basique de ssh
Pour se connecter à une machine distante de façon sécurisée, on utilise habituellement le protocole ssh.

Ssh est souvent installé par défaut pour la plupart des distributions. Le cas échéant, on installe openssh ainsi sur le client :

Code : Tout sélectionner

$ sudo apt-get update
$ sudo apt-get install openssh-client

Sur le serveur :

Code : Tout sélectionner

$ sudo apt-get update
$ sudo apt-get install openssh-server

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 :

Code : Tout sélectionner

$ 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 :

Code : Tout sélectionner

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

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 :

Code : Tout sélectionner

$ ssh-keygen -t dsa
Generating public/private dsa key pair.
Enter file in which to save the key (/home/user/.ssh/id_dsa : /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 :

Code : Tout sélectionner

$ 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.

Code : Tout sélectionner

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, la cléf sera chargée jusqu'à fermeture de la console :

Code : Tout sélectionner

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

$ ssh utilisateur@ip_ou_nom_du_serveur ne demande plus de mot de passe

Vous pouvez alors désactiver la connexion par mot de passe (Voir section Divers paramétrages du serveur ssh)

Ca ne marche pas ?!
Ajoutez -v, vv ou -vvv (plus il y a de v, plus il y aura des détails dans la console). Cela devrait vous permettre de détecter la raison du problème rencontré.

Code : Tout sélectionner

$ 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: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.7p1 Debian-5+deb8u2
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.7p1 Debian-5+deb8u2
debug1: match: OpenSSH_6.7p1 Debian-5+deb8u2 pat OpenSSH* compat 0x04000000
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr umac-64-etm@openssh.com none
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: 
...

Divers paramétrages du serveur ssh
La configuration du serveur ssh se fait dans le fichier /etc/ssh/sshd_config
Pour prendre en compte les modifications, il faut redémarrer ssh : $ sudo /etc/init.d/ssh restart

Changer de port d'écoute : modifier la ligne Port 22

Désactiver le compte root : modifier la ligne PermitRootLogin no

Désactiver la connexion par mot de passe :
modifier ou ajouter les lignes suivantes
ChallengeResponseAuthentication no
PasswordAuthentication no
UsePAM no

Restreindre ou autoriser l'accès à certains identifiants seulement :
DenyUsers user1 user2 user5
AllowUsers user3 user4
Il est possible de travailler avec des groupes avec les paramètres DenyGroups et AllowGroups

[filoha]

Tu as oublié de préciser qu'au début de l'opération, tant que le test n'est pas confirmé, la connexion par MDP doit être à "yes", sinon, ton envoi de clef .pub ne pourra pas être effectué.
C'est seulement une fois cet envoi fait, que tu retournes dans sshd_config et que tu modifies la ligne MDP de yes à no. Se méfier de ça, surtout s'il s'agit d'un serveur distant sur lequel on n'a pas la main physiquement.
Il faudrait aussi que tu complètes ton tuto avec le cas de plusieurs identifiants rsa sur la même machine, tu es obligé de modifier le 'id_rsa' en 'id_rsaXXX' et dans ce cas, l'appel ordinaire ne fonctionnera pas. il faut ajouter à la ligne d'appel "-i ~/.ssh/id_rsaXXX".
Le mieux étant de créer un fichier 'config' dans ~/.ssh, du genre :

Code : Tout sélectionner

Host machin
HostName 192.168.0.X
User <user>
PasswordAuthentication no
port 123
IdentityFile ~/.ssh/id_rsaXXX

Ainsi, l'appel se réduit à
$ ssh machin

[lol]

Salut,

dsa #les autres méthodes méthodes de chiffrage : ecdsa, ed25519, rsa, rsa1

Ce serait sympa un mot sur chaque méthode.

Le mieux étant de créer un fichier 'config' dans ~/.ssh

Oui, le création d'un fichier ./ssh/config simplifie bien la vie et permet de s'y retrouver quand on a 50 cléfs dans la poche...

On a deux articles sur le Wiki qui traitent de ssh:
Ssh
Utilisation_de_clefs_et_raccourcis_ssh
C'est peut-être le bon moment pour repasser dedans et harmoniser tout ça ?

[piratebab]

Je ferai pour ma part une remarque de forme.
Chez debian, la commande sudo est à réserver à des usages bien particuliers, elle n'est pas là pour faire de l'administration générale.
Donc merci de faire précéder les commandes devant être réalisées par l'utilisateur root de

Code : Tout sélectionner

# XXX

et non

Code : Tout sélectionner

sudo XXX

[vohu]

Tu as oublié de préciser qu'au début de l'opération, tant que le test n'est pas confirmé, la connexion par MDP doit être à "yes", sinon, ton envoi de clef .pub ne pourra pas être effectué.
C'est seulement une fois cet envoi fait, que tu retournes dans sshd_config et que tu modifies la ligne MDP de yes à no. Se méfier de ça, surtout s'il s'agit d'un serveur distant sur lequel on n'a pas la main physiquement.

Je n'avais pas parlé de comment désactiver la connexion par mot de passe, car par défaut, la connexion par mot de passe n'est jamais désactivée.

Il faudrait aussi que tu complètes ton tuto avec le cas de plusieurs identifiants rsa sur la même machine, tu es obligé de modifier le 'id_rsa' en 'id_rsaXXX' et dans ce cas, l'appel ordinaire ne fonctionnera pas. il faut ajouter à la ligne d'appel "-i ~/.ssh/id_rsaXXX".

Avec la méthode que je propose il n'y a pas besoin de préciser le fichier clef, car elle est chargée avec ssh-add avant la connexion, ce qui résoud le problème du nom des clefs.

Je ferai pour ma part une remarque de forme.
Chez debian, la commande sudo est à réserver à des usages bien particuliers, elle n'est pas là pour faire de l'administration générale.
Donc merci de faire précéder les commandes devant être réalisées par l'utilisateur root de

Code : Tout sélectionner

# XXX

et non

Code : Tout sélectionner

sudo XXX

Je sais bien, mais au moins on évite de voir des gens poster avec des quand je tape vos ligne ça écrit 'commande introuvable'
J'ai bien ajouté les $ et les # mais je préfère laisser les sudo. Si quelqu'un fait un tuto expliquant les bases et les bonnes pratiques sous Debian, je corrigerai et mettrai un lien vers ce tuto tout en haut de celui-ci.

Salut,

dsa #les autres méthodes méthodes de chiffrage : ecdsa, ed25519, rsa, rsa1

Ce serait sympa un mot sur chaque méthode.

Il y a de gros débats sur lequel il faut utiliser, je sais que j'ai eu des problèmes avec dsa avec je ne sais plus quelle version du client ssh. Je vais voir ce que je peux trouver et synthétiser...

On a deux articles sur le Wiki qui traitent de ssh:
Ssh
Utilisation_de_clefs_et_raccourcis_ssh
C'est peut-être le bon moment pour repasser dedans et harmoniser tout ça ?

Je n'avais pas vu le second. Effectivement si on pouvait rassembler le tout...

[piratebab]

Le tuto sur su et sudo existe déja sur le wiki.
Si j'insiste, c'est justement pour que les débutants comprennent bien la différence entre root et les autres. Et c'est en faisant des erreurs qu'on apprend ..

[filoha]

Je ne connais pas ce tuto, il faudra que j'aille le lire mais j'ai tellement de choses en retard qu'il me faudrait deux vies.
Est-ce que ce tuto (lien direct, merci) ne dit que du mal de sudo ou est-ce qu'il en liste les possibilités d'utilisation sans crainte ?
Pour moi, comme je l'ai déjà dit, toute commande sensible c'est # ET alt/F2-6.
Mais, certaines commandes, qui pourtant nécessitent d'être root, sont sans conséquences au niveau de la sécu.
Est-ce que ce tuto donne les bonnes formules pour remplir sudoers sans placer la troisième entrée à ALL ?

[vohu]

Je viens de regarder ce tuto. Il explique comment on utilise et configure sudo, mais est très peu explicite concernant les risques.

[lol]

Salut,

Je viens de regarder ce tuto. Il explique comment on utilise et configure sudo, mais est très peu explicite concernant les risques.

C'est autant d'un point de vue "bonne administration", philosophie et risques (même s'ils existent) que la discussion se place.
Je propose qu'on ouvre un fil dans support sur ce sujet plutôt que de pourrir le T&A (Sur SSH) de Vohu!

[vohu]

Je plussoie

[PengouinPdt]

Salut,

dsa #les autres méthodes méthodes de chiffrage : ecdsa, ed25519, rsa, rsa1

Ce serait sympa un mot sur chaque méthode.

Il y a de gros débats sur lequel il faut utiliser, je sais que j'ai eu des problèmes avec dsa avec je ne sais plus quelle version du client ssh. Je vais voir ce que je peux trouver et synthétiser...

On a deux articles sur le Wiki qui traitent de ssh:

J'ai modestement restitué quelques informations à ce propos ... tu trouveras tout sur mon blog :p

Tout particulièrement cet article "SSH Configuration et clés plus sécurisées"
Ensuite, tu trouveras, au moins deux autres articles sur l'état des lieux d'OpenSSH, v6, puis v7 ... qui restituent aussi des points importants à mettre en place ou à vérifier !

Pour faire ces articles, je suis allé souvent à la source ... dans le cas contraire, j'ai "sourcé" !

Tu peux allégrement "piquer" pour construire t(on|es) futur(s) article(s) ...