SSH

Partagez ici vos Trucs et vos Astuces.
Répondre
Avatar du membre
vohu
Membre
Membre
Messages : 455
Enregistré le : 16 avr. 2016, 12:02
Localisation : Strasbourg
Status : Hors ligne

24 avr. 2016, 21:41

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
Avatar du membre
filoha
Membre
Membre
Messages : 148
Enregistré le : 04 avr. 2016, 14:48
Localisation : Moitié Sud Métropole
Contact :
Status : Hors ligne

25 avr. 2016, 00:47

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
L'oubli est chose facile, mais la mémoire reste.
Avatar du membre
lol
Site Admin
Site Admin
Messages : 3317
Enregistré le : 04 avr. 2016, 12:11
Localisation : Madagascar
Contact :
Status : Hors ligne

25 avr. 2016, 08:09

Salut,
vohu a écrit :dsa #les autres méthodes méthodes de chiffrage : ecdsa, ed25519, rsa, rsa1
Ce serait sympa un mot sur chaque méthode.
filoha a écrit :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 ?
Debian stable. XFCE.
C'est curieux chez les marins ce besoin de faire des phrases (Les tontons flingueurs).
Avatar du membre
piratebab
Site Admin
Site Admin
Messages : 3544
Enregistré le : 24 avr. 2016, 18:41
Localisation : sud ouest
Status : Hors ligne

25 avr. 2016, 08:36

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
Avatar du membre
vohu
Membre
Membre
Messages : 455
Enregistré le : 16 avr. 2016, 12:02
Localisation : Strasbourg
Status : Hors ligne

25 avr. 2016, 10:00

filoha a écrit :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.
filoha a écrit :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.
piratebab a écrit :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.
lol a écrit :Salut,
vohu a écrit :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...
lol a écrit :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...
Avatar du membre
piratebab
Site Admin
Site Admin
Messages : 3544
Enregistré le : 24 avr. 2016, 18:41
Localisation : sud ouest
Status : Hors ligne

25 avr. 2016, 14:51

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 ..
Avatar du membre
filoha
Membre
Membre
Messages : 148
Enregistré le : 04 avr. 2016, 14:48
Localisation : Moitié Sud Métropole
Contact :
Status : Hors ligne

25 avr. 2016, 15:09

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 ?
L'oubli est chose facile, mais la mémoire reste.
Avatar du membre
vohu
Membre
Membre
Messages : 455
Enregistré le : 16 avr. 2016, 12:02
Localisation : Strasbourg
Status : Hors ligne

25 avr. 2016, 15:13

Je viens de regarder ce tuto. Il explique comment on utilise et configure sudo, mais est très peu explicite concernant les risques.
Avatar du membre
lol
Site Admin
Site Admin
Messages : 3317
Enregistré le : 04 avr. 2016, 12:11
Localisation : Madagascar
Contact :
Status : Hors ligne

25 avr. 2016, 15:38

Salut,
vohu a écrit :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! :003:
Debian stable. XFCE.
C'est curieux chez les marins ce besoin de faire des phrases (Les tontons flingueurs).
Avatar du membre
vohu
Membre
Membre
Messages : 455
Enregistré le : 16 avr. 2016, 12:02
Localisation : Strasbourg
Status : Hors ligne

25 avr. 2016, 15:46

Je plussoie :023:
Avatar du membre
PengouinPdt
Contributeur
Contributeur
Messages : 1327
Enregistré le : 23 avr. 2016, 23:37
Localisation : 47/FR
Diaspora* : https://framasphere.org/u/hucste
Contact :
Status : Hors ligne

25 avr. 2016, 16:34

vohu a écrit :
lol a écrit :Salut,
vohu a écrit :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...
lol a écrit :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) ...
PengouinPdt { le seul, le vrai } ~ " Libre as a Pengouin "
- DIY - [barre]Debian Sid[/barre]|Devuan Ceres
----
Ne réponds pas aux PM d'assistance
Répondre