Mettre en place des clés SSH

Ce site est optimisé pour être consulté depuis un navigateur moderne dans lequel JavaScript est activé.

Mettre en place des clés SSH

TMAX

Configurer et utiliser SSH

Créez le RSA Key Pair sur le poste client:

ssh-keygen -t rsa

*Le chemin où vous voulez que la clé soit stocker

Enter file in which to save the key (/home/user/.ssh/id_rsa):

Entrée votre passphrase.

Enter passphrase (empty for no passphrase):

Une fois ceci fait, il nous faut copier la clé publique.

cat ~/.ssh/id_rsa.pub | ssh user@123.45.56.78 "mkdir -p ~/.ssh && cat >>  ~/.ssh/authorized_keys"

Vous avez plus qu'à désactiver le mot de passe root

--------------------------------------
Désactivation du compte root:

- Ajout d’un nouvel utilisateur:
nous n’utiliserons pas le compte root pour les connexions à distance. C’est pourquoi nous allons créer un groupe contenant des utilisateurs qui seront autorisés à se connecter via SSH. (Dans cette exemple, je prend comme nom de compte "compte")

groupadd compte

- On créé ensuite un nouvel utilisateur puis on l’ajoute au groupe qui sera autorisé à se connecter via SSH. (Dans cette exemple, je prend comme nom d'user "user")

useradd -m user
passwd user
usermod -a -G compte user

Configuration de ssh:

nano /etc/ssh/sshd_config

On commence par changer le port par défaut :

Port 2222

Note : Vous pouvez utiliser n’importe quel port, pour peu que celui-ci ne soit pas réservé par un autre service. Avoir un port non standard vous permettra d’éviter une partie des attaques automatisées que l’on rencontre chez certains prestataires .

* Le compte root n’est pas autorisé à se connecter directement depuis SSH :

PermitRootLogin no

* Seul les utilisateurs appartenant au groupe sshusers sont autorisés à se connecter (il faut ajouter cette ligne) :

AllowGroups compte

*Pour cela éditer le fichier /etc/ssh/sshd_config et modifier les paramètres suivant : Décommenter ou ajouter la ligne suivante :

PubkeyAuthentication yes

* On redémarre le daemon SSH :

/etc/init.d/ssh restart

À ce stade, ne surtout pas fermer l’ancienne connexion, au risque de ne plus pouvoir se reconnecter par la suite. Ce que je vous conseille, c’est d’ouvrir un nouvel onglet dans votre terminal et de tester la connexion avec le port et l’utilisateur adéquat.

nami007

Vire l'ip peut-être.

Et merci.

TMAX

l'ip est fake

Hardware

ça mériterait plus d'explication tout de même, parce que là c'est un peu léger.

Tu peux expliquer les différents types de chiffrements disponibles avec OpenSSH : RSA, ECDSA, Ed25519.
La sécurisation du service côté serveur et le paramétrage du SSH agent côté client, comment bien organiser ses clés... etc

https://wiki.archlinux.org/index.php/SSH_keys
http://www.ssi.gouv.fr/uploads/IMG/pdf/NP_OpenSSH_NoteTech.pdf

Merci pour l’initiative en tout cas.

TMAX

Je suis tout à fait d'accord avec toi Hardware le poste manque cruellement d'explication, le but de mon poste était d'aller à l'essentiel.

N'hésite, surtout pas à mettre à jour se poste pour l'améliorer, il est fait pour

Wonderfall

Tu aurais aussi pu faire un petit aparté sur comment désactiver les mdp pour utiliser uniquement les clés SSH, bref un peu exploiter la configuration de SSH quoi.

zarev

Salut,

Merci pour le tuto.

Pour ma part j'obtiens ça quand j'essaye de me connecter:

Server refused our key

Je suis sous Windows pour générer la clef avec Putty Key Gnenerator.

EDIT: après un test à partir de Ubuntu en live CD, ça fonctionne du premier coup. Reste à voir avec la génération par Windows.

EDIT 2/ c'est bon sous Windows. J'ai tout simplement recopié la clef dans la fenêtre même de Putty KEYGEN après la génération dans le fichier authorized_keys sur le serveur distant.

Par contre la commande

ssh-add

ne fait rien. Elle ne demande pas la passphrase. Au début j'ai même cette erreur:

Could not open a connection to your authentication agent.

"résolue" par un:

exec ssh-agent bash

J'ai déjà repris les valeurs de:

echo $SSH_AUTH_SOCK
echo $SSH_AGENT_PID

pour les importer, respectivement, dans:

SSH_AUTH_SOCK=/tmp/ssh-uabcd/agent.1234; export SSH_AUTH_SOCK;
SSH_AGENT_PID=12345; export SSH_AGENT_PID;

Malgré tout la commande ssh-add ne fait rien.

Bonne nuit

Gravefield

Merci hardware pour le pdf

Je vais me forcer à lire la doc en anglais, j'ai un peu de mal mais bon si je veux m'améliorer ... ^^

Hardware

La doc sur le wiki d'archlinux est ultra complète sur le sujet ( comme d'hab avec le wiki d'arch 😛 ) et le pdf c'est un très bon complément pour sécuriser le service.

TMAX

J'ai un peu maj le topic

Gravefield

Perso cette doc ma bien aider pour mettre en place l'agent ssh sous windows : http://doc.fedora-fr.org/wiki/SSH_:_Authentification_par_cl%C3%A9
Et pareil pour git avec msysgit : https://help.github.com/articles/working-with-ssh-key-passphrases/

Ayenon

Juste pour savoir, il est intéressant de mettre l’accès root ouvert mais uniquement avec une clé SSH ?

Avec un petit :

PermitRootLogin without-password

zarev

Alors moi qui était sous Windows j'ai forcément du adapter.

Voici comment j'ai fait:

Prérequis

PuTTY (l'installation installe tout ce que l'on a besoin: http://the.earth.li/~sgtatham/putty/latest/x86/putty-0.64-installer.exe

Pour commencer il faut donc générer les clefs avec PuTTYgen:

* lancer PuTTYgen (démarrer, dans la fenêtre taper puttygen
* choisir SSH-2 RSA (2048 bits)

Maintenant cliquer sur Générer. La génération de la clef ne sera pas sans que vous bougiez votre souris dans la zone sous la barre de progression : entropie (capacité à générer des nombres aléatoires )

Une fois terminé, vous devez arriver à çà:

Maintenant connectez-vous à votre serveur à l'aide de Putty et rendez-vous dans:

cd /home/USER/.ssh

Ensuite:

nano authorized_keys

Dans ce fichier coller la clef publique qui a été générée dans PuttyGen comme l'exemple:
veillez à bien copier la clef complète!!!

Si tout s'est bien passé, dans votre fichier authorized_keys, vous devez avoir votre clef complète, sur UNE LIGNE, commençant par ssh-rsa

Sauvegarder votre fichier authorized_keys

Maintenant il faut votre clef privée AVEC son passphrase.

Retourner sur PuttyGen et entrer votre passphrase et confirmez-la. Ensuite cliquer sur Save private key et donnez-lui un nom du genre: privatek.ppk et mettez-le fichier dans C:\. Vous allez voir pourquoi après.

Maintenant allez sur votre bureau Windows et créer un raccourci et faire en sorte que Pageant démarre au démarrage de Windows.

Vous devez indiquer:

"C:\Program Files (x86)\PuTTY\pageant.exe" C:\privatek.ppk

Allez dans Démarrer et faites clic droit sur Tous les programmes et choisir Ouvrir tous les utilisateurs.
Allez dans Programmes -> Démarrage et coller dans ce dossier le raccourci que vous avez créé.

Il ne reste plus qu'a tester si tout fonctionne bien. Redémarrer Windows (une fois n'est pas coutume...)
Après le redémarrage, Pageant s'est donc lancé de manière automatique et vous aurez une fenêtre dans laquelle vous devez entrer votre passphrase. Valider ensuite.

Lancez Putty et connectez-vous au serveur. Après avoir rentré votre USER, l'authentification se fait automatiquement. Plus besoin d'entrer ni le mot de passe ni la passphrase.

Je n'ai pas inventé ce tutoriel, c'est une synthèse de ce que j'ai appris en cherchant sur le net et aussi grâce au conseil d'Hardware.

En espérant que cela puisse servir d'autres

Wonderfall

Ayenon wrote:Juste pour savoir, il est intéressant de mettre l’accès root ouvert mais uniquement avec une clé SSH ?

Avec un petit :
PermitRootLogin without-password

Je pense que c'est toujours mieux de désactiver l'accès root, ça fait systématiquement une protection en plus et c'est toujours ça de pris.

jean-luc

Wonderfall wrote:
Ayenon wrote:Juste pour savoir, il est intéressant de mettre l’accès root ouvert mais uniquement avec une clé SSH ?

Avec un petit :
PermitRootLogin without-password
Je pense que c'est toujours mieux de désactiver l'accès root, ça fait systématiquement une protection en plus et c'est toujours ça de pris.

Bonjour;

Déjà une clef 2048 est considérée comme inviolable : (car avant que la nsa veuille bien accorder un peu de temps de toute sa puissance pour la craquer...il faut vraiment que le poisson en vaille le coup) !!!

Alors pour les plus parano, ils peuvent même mettre une clef 4096 voir 8192..

A partir de là je ne vois pas ce que l'on risque de se connecter en SSH en root ,voir même sur le port 22 ☹bien sur connexion en clefs exclusif).

OCBSLiM-THC

*Agents SSH

Un agent SSH est un outil intégré à votre système d’exploitation qui vous permet de ne saisir la passphrase d’une clé qu’une seule fois (pendant la durée de vie de l’agent, généralement limitée à votre session, entre connexion et déconnexion).

Voir si vous avez un agent actif ou nan.

set | grep SSH_AUTH_SOCK

Si vous ne voyez rien s’afficher, vous n’avez pas d’agent actif ; si vous voyez quelque chose (probablement du genre /var/run/….sock), alors vous en avez un.

Si vous n’avez pas d’agent actif, vous pouvez en lancer un manuellement à l’aide de la bien-nommée commande ssh-agent. Celle-ci crée un processus résident (un daemon) et affiche la série de commandes à balancer dans l’environnement (ou dans chaque terminal) pour qu’il soit au courant que l’agent existe, et donc qu’il essaie de s’en servir. Ces commandes consistent généralement juste à définir les variables d’environnement SSH_AUTH_SOCK et SSH_AGENT_PID. Du coup quand on lance un agent à la main dans le shell courant, on récupère généralement son affichage pour l’exécuter aussi sec, comme ceci :

$ ssh-agent
Agent pid 23038

À partir de là, à vous de tester le comportement lors de la première utilisation d’une clé SSH : si vous voyez une interception globale vous demandant de saisir la passphrase et proposant de la stocker dans l’agent, tout baigne. Si ce n’est pas le cas, vous allez devoir ajouter la passphrase à l’agent manuellement, en utilisant la commande ssh-add. Dans ce cas, soit vous avez une seule clé, et vous n’avez pas besoin de la préciser, soit vous en avez plusieurs et il faut indiquer laquelle :

$ ssh-add ~/.ssh/id_rsa
Enter passphrase for /home/user/.ssh/id_rsa
Identity added: /Users/tdd/.ssh/id_rsa (/home/user/.ssh/id_rsa)

Après ça, la passphrase est automatiquement exploitée pendant toute la durée de vie de l’agent.

Ce type de manip’ est notamment utile quand on se connecte sur un serveur de production où on va faire une série de git pull, git submodule update, etc. et où on veut éviter de taper sa passphrase une tonne de fois. On commence par configurer l’agent, ajouter sa clé, et hop ! On est prêt à rouler.

Enfin, pour ce qui est de Windows, avec msysGit spécifiquement, vous trouverez quelques instructions pour lancer automatiquement ssh-agent sur cette documentation chez GitHub.

Comprendre et maîtriser les clés SSH

thib0169

Bonjour,

De mon côté je n'arrive pas à faire fonctionner la connexion par clef RSA. J'arrive bien à créer la clef grâce à la ligne de commande suivante:

ssh-keygen -t rsa

Ensuite, je n'utilise pas la commande fournie dans ce tutoriel:

cat ~/.ssh/id_rsa.pub | ssh user@123.45.56.78 "mkdir -p ~/.ssh && cat >>  ~/.ssh/authorized_keys"

Mais plutôt la commande suivante qui me permet de spécifier le port de mon NAS:

ssh-copy-id -i ~/.ssh/id_rsa.pub "<user_qui_se_connecte>@<ip_de_mon_nass> -p <port_de_mon_nas>"

La commande est alors extrêmement longue et fini par afficher l'erreur suivante:

/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed

/usr/bin/ssh-copy-id: ERROR: ssh: connect to host <ip_de_mon_nass> -p <port_de_mon_nas> port 22: Connection timed out

Pour information j'ai fait une redirection de port sur mon routeur pour ne pas que le port 22 soit exposé.

De plus, l'accès SSH fonctionne lorsque je me connecte depuis mon dédié avec mon mot de passe SSH:

ssh transfert@<ip_de_mon_nass> -p <port_de_mon_nas>

J'ai même changé les droits des dossiers suivants sur mon NAS:

chmod 755 /volume1/homes/<user_avec_lequel_je_me_connecte>
chmod 700 /volume1/homes/<user_avec_lequel_je_me_connecte>/.ssh
chmod 644 /volume1/homes/<user_avec_lequel_je_me_connecte>/.ssh/authorized_keys

Et j'ai même essayé de copier le contenu de ma clef dans le fichier authorized_keys de mon NAS, mais je suis à court d'idées.

thib0169

Pour info, voici les infos données lorsque je me connecte avec la commande ssh -v:

debug1: Connection established.
debug1: identity file /home/transfert/.ssh/id_rsa type 1
debug1: key_load_public: No such file or directory
debug1: identity file /home/transfert/.ssh/id_rsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/transfert/.ssh/id_dsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/transfert/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/transfert/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/transfert/.ssh/id_ecdsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/transfert/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/transfert/.ssh/id_ed25519-cert type -1
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.8p1-hpn14v6
debug1: match: OpenSSH_6.8p1-hpn14v6 pat OpenSSH* compat 0x04000000
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc umac-64-etm@openssh.com none
debug1: kex: client->server aes128-cbc 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
debug1: Host '[<ip_de_mon_nas>]:<por_de_mon_nas>' is known and matches the ECDSA host key.
debug1: Found key in /home/<user>/.ssh/known_hosts:2
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: Offering RSA public key: /home/<user>/.ssh/id_rsa
debug1: Authentications that can continue: publickey,password
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

Aerya

Salut,

Voici un autre tutoriel. Sait-on jamais...

xataz

thib0169 wrote: [...]
Mais plutôt la commande suivante qui me permet de spécifier le port de mon NAS:
ssh-copy-id -i ~/.ssh/id_rsa.pub "<user_qui_se_connecte>@<ip_de_mon_nass> -p <port_de_mon_nas>"
La commande est alors extrêmement longue et fini par afficher l'erreur suivante:
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed

/usr/bin/ssh-copy-id: ERROR: ssh: connect to host <ip_de_mon_nass> -p <port_de_mon_nas> port 22: Connection timed out
[...]

Salut,

Tu as un début de réponse dans le message d'erreur :

/usr/bin/ssh-copy-id: ERROR: ssh: connect to host <ip_de_mon_nass> -p <port_de_mon_nas> port 22: Connection timed out

Il te dit qu'il n'arrive pas à ce connecter a l'hôte "<ip_de_mon_nass> -p <port_de_mon_nas>" sur le port 22, la commande serais plutôt :

ssh-copy-id -i ~/.ssh/id_rsa.pub <user_qui_se_connecte>@<ip_de_mon_nass> -p <port_de_mon_nas>

sans les guillemets donc.

Page suivante »