Clés SSH - 1and1 mutualisé

L'auteur de ce sujet a trouvé une solution à son problème.
Auteur du sujet

Bonjour à tous,

Suite à la mise à jour du firmware de mon NAS QNAP, il a bien évidement mise à jour OpenSSH en :

OpenSSH_7.0p1, OpenSSL 1.0.1q 3 Dec 2015

Mes clés fonctionnaient parfaitement jusque là et il semblerait que la nouvelle version d'OpenSSH n'accepte plus ssh-dss (voir OpenSSH Legacy).

Mon script me retourne donc maintenant une erreur :

1
2
Unable to negotiate with MON_SERV_DISTANT: no matching host key type found. Their offer: ssh-dss
rsync: connection unexpectedly closed

Je suis assez nocive sur le sujet des clés SSH etc… les invites de commandes, c'est pas trop ma tasse de thé mais bon.

J'ai tenté plusieurs manipulation suite à ce message comme celles du lien au dessus, ou d'autres forums comme stackoverflow… mais je crois que mon gros problème, c'est la vraie compréhension du stockage des clés SSH. J'ai un doute de où se fait la config pour y mettre la modif au dessus pour réactiver le ssh-dss, comment le serveur sait quelle clé il doit communiquer etc.

Actuellement, ma commande rsync inclus précisément le lien absolu vers ma clé privée :

rsync -a -e "ssh -i my-private-key" –delete-after –progress.....

Ce qui me plombe un peu, c'est que tout fonctionnait parfaitement, j'avais plus que le crontab a faire et j'ai fais cette put** de MAJ du NAS entre temps et j'ai foutu en l'air le peu que j'avais compris à faire fonctionner…

J'imagine qu'il y a bien quelques as pour me dire où mon problème se situe…

Par avance, merci ! Cordialement

+0 -0

Cette réponse a aidé l'auteur du sujet

Bonjour,

Je suis assez nocive sur le sujet des clés SSH etc… les invites de commandes, c'est pas trop ma tasse de thé mais bon.

Juste parce que ça m'a fait rire : je suppose que tu voulais dire "novice" et pas "nocive". :p

Ton lien fournit une solution :

The best resolution for these failures is to upgrade the software at the other end. OpenSSH only disables algorithms that we actively recommend against using because they are known to be weak. In some cases, this might not be immediately possible so you may need to temporarily re-enable the weak algorithms to retain access.

For the case of the above error message, OpenSSH can be configured to enable the diffie-hellman-group1-sha1 key exchange algorithm (or any other that is disabled by default) using the KexAlgorithm option - either on the command-line:

ssh -oKexAlgorithms=+diffie-hellman-group1-sha1 user@127.0.0.1

or in the ~/.ssh/config file:

Host somehost.example.org KexAlgorithms +diffie-hellman-group1-sha1

The '+' before the list instructs ssh to append the algorithm to the client's default set rather than replacing the default. By appending, you will automatically upgrade to the best supported algorithm when the server starts supporting it.

Another example, this time where the client and server fail to agree on a public key algorithm for host authentication:

Unable to negotiate with 127.0.0.1: no matching host key type found. Their offer: ssh-dss

OpenSSH 7.0 and greater similarly disables the ssh-dss (DSA) public key algorithm. It too is >weak and we recommend against its use. It can be re-enabled using the HostkeyAlgorithms >configuration option:

ssh -oHostKeyAlgorithms=+ssh-dss user@127.0.0.1

or in the ~/.ssh/config file:

Host somehost.example.org HostkeyAlgorithms ssh-dss

Du coup, première question : que se passe-t-il lorsque tu testes ta connexion à la main (pas par le script) depuis ton client avec cette option dans ta commande :

ssh -oHostKeyAlgorithms=+ssh-dss

Est-ce que ça se connecte ?

  • Si oui : mettre la configuration dans ~/.ssh/config et tester.
  • Si non : donne-nous la sortie de la commande.
+0 -0
Auteur du sujet

Vraiment… j'ai un peu la rage d'avoir tourné autour en ayant la réponse depuis + de 4 heures, ça vient juste de me faire "TILT" quand @Ezenku a simplement dit :

depuis ton client avec cette option dans ta commande

Je pensais franchement avoir tout testé avec cette commande : la rentrer directe dans l'invite de commande, la tester sur le serveur distant (inutile, j'en conviens…), tenter d'éditer des fichiers ssh config… et j'en passe.

J'ai pas fais le rapprochement entre la commande ssh en elle-même et le paramètre ssh du service rsync… Un peu trop nocive pour le coup :p Après plusieurs heures sur de la doc, j'aurais dû prendre une pause et ça m'aurait peut-être sauter aux yeux…

Mon script tourne donc très bien maintenant, pour toute personne dans la même bêtise que moi, voici ma commande finale :

rsync -a -e "ssh -oHostKeyAlgorithms=+ssh-dss -i $KEY" –delete-after....


Il me semblait avoir lu que dss était déprécié, quelqu'un a plus d'infos ?

C'est effectivement le cas, mais si je comprend bien le "Their offer: ssh-dss" à la fin du résultat, le problème vient des serveurs 1and1 un peu trop oldschool ? On a pas trop la main sur ça sur un mutualisé si ?

Mon sujet original est donc résolu, je le passerais comme tel après, mais si je peux profiter du topic pour vous soudoyer quelques précisions pour mon information et ma compréhension du truc…

On a donc une clé privée stockée sur le local et une publique sur le serveur distant. Pour les clés générées, je me pose quand même cette question, elles sont par défaut dans le dossier ~/.ssh, avec dedans id_rsa, id_rsa.pub, config, known_hosts.

  • Mais qu'arrive-t-il si, c'est justement mon cas, je déplace ma clé privée dans un autre répertoire et que dans ma commande ssh, je ne précise pas l'argument '-i PRIVATE_KEY' ?

  • Dois-je déclarer dans un certain fichier les nouvelles clées générées pour qu'elles soient recherchées ? Ou il cherche par rapport au nom ou quelque chose du genre ? Il parse peut-être toutes les clés privées du répertoire /.ssh ?

Je trouve que le sujet est assez floue, on trouve beaucoup de tutos pour savoir générés les clés, les utiliser mais c'est entièrement donner sur un plateau à chaque fois. La théorie de base sur système derrière est souvent bâclé, ou du moins j'ai mal cherché / compris. Vu ma demande initiale, je serais pas trop étonné.

Si les réponses aux questions sont d'une simplicité que nécessite qu'un peu de recherche, n'hésitez pas à me le dire, je veux pas non plus faire perdre du temps sur un sujet peut-être déjà réchauffé ailleurs.

Dans tous les cas, un énorme merci pour l'éclat de lumière dans mon petit cerveau :D

Et vu que je poste très rarement sur ZdS, je précise que vous avez tous fait un excellent travail avec ce site !

Bonne soirée

Édité par Apo

+0 -0

Cette réponse a aidé l'auteur du sujet

SPOILER ALERT : C'est long. Très long en fait !

Je pensais franchement avoir tout testé avec cette commande : la rentrer directe dans l'invite de commande, la tester sur le serveur distant (inutile, j'en conviens…), tenter d'éditer des fichiers ssh config… et j'en passe.

Autrement dit, tu as fait tellement d'essais que tu ne sais plus ce que tu as fait. Pour éviter cela, la méthode de base consiste à noter (dans un cahier, un bloc-notes, ou ce que tu veux) toutes les modifications ou tentatives. Il ne faut pas tenter de les retenir : qui se rappelle de son premier essai après cinquante tentatives ? Au besoin, on créé une sauvegarde du fichier à chaque modification.

C'est un peu extrême pour une utilisation personnelle, et pourtant, je garantis par expérience qu'on arrive bien plus vite à ce qu'on veut lorsqu'on note un maximum de choses et/ou que l'on sait où l'on va. Dit autrement, j'ai plus de chances d'arriver à destination avec une carte routière que sans aucun moyen de repère. :)

Maintenant, quelques éléments spécifiques à ton problème :

J'ai pas fais le rapprochement entre la commande ssh en elle-même et le paramètre ssh du service rsync

Pour le coup, moi non plus, je n'ai même pas fait attention à la commande rsync. Ce que je voulais que tu testes, c'était une commande ssh en ligne de commande, sans autre commande autour, pour voir si ton serveur réagissait à l'identique.

Lorsque j'automatise quelque chose, je fais d'abord toute la procédure à la main. Cela permet de vérifier que j'ai bien le résultat que je veux, commande par commande. Je combine le tout ensuite, en vérifiant à chaque fois qu'il n'y a pas de différence. En revanche, ça peut être long.

le problème vient des serveurs 1and1 un peu trop oldschool ?

Il semblerait oui.

On a pas trop la main sur ça sur un mutualisé si ?

Ca dépend de ton offre exacte. Il est possible d'être sur un serveur où tu n'a la main que sur ton serveur sans voir ceux des autres (VPS) ou de partager complètement une machine administrée par 1&1.

Mais qu'arrive-t-il si, c'est justement mon cas, je déplace ma clé privée dans un autre répertoire et que dans ma commande ssh, je ne précise pas l'argument '-i PRIVATE_KEY' ?

En toute logique il ne trouve pas la clé. Je pense que la suite dépend de la configuration du client et du serveur :
- il ne se connecte pas
- ou il demande un mot de passe

Dois-je déclarer dans un certain fichier les nouvelles clées générées pour qu'elles soient recherchées ? Ou il cherche par rapport au nom ou quelque chose du genre ? Il parse peut-être toutes les clés privées du répertoire /.ssh ?

Non.

Le serveur ssh se base sur le fichier sshd_config. Il est possible d'en spécifier un sur la ligne de commande, mais par défaut il est dans /etc/ssh/sshd_config.

Ce fichier contient toutes les options du serveur SSH, sa configuration est décrite ici. C'est dans ce fichier que l'on indique où se trouvent les autres fichiers, contenant les clés publiques ou privées, par exemple :

AuthorizedKeysFile Spécifie le fichier contenant les clefs publiques à utiliser pour l'authentification de l'utilisateur. AuthorizedKeysFile peut contenir des jetons de la forme %T qui sont substitués lors des réglages de la connexion. Les jetons suivant sont définis : %% est remplacé par le caractère « % », %h est remplacé par le répertoire de base (home directory) de l'utilisateur qui s'authentifie et %u est remplacé par le nom de cet utilisateur. Après substitution, AuthorizedKeysFile peut être un chemin absolu ou relatif au répertoire de base de l'utilisateur. Par défaut « .ssh/authorized_keys ».

(j'ai mis l'option à utiliser dans le fichier en gras).

Ensuite :

Je trouve que le sujet est assez floue, on trouve beaucoup de tutos pour savoir générés les clés, les utiliser mais c'est entièrement donner sur un plateau à chaque fois. La théorie de base sur système derrière est souvent bâclé, ou du moins j'ai mal cherché / compris. Vu ma demande initiale, je serais pas trop étonné.

Alors un peu de théorie rapide :

On reprend la base : SSH offre un accès à distance, principalement en ligne de commande à une autre machine. La machine que l'on utilise est appelée client et doit disposer d'un client SSH. La machine à laquelle on souhaite accéder est appelée serveur.

SSH est l'acronyme de "Secure SHell" soit "ligne de commande sécurisée" en bon français. Cela signifie que :
- la communication entre les deux machines en chiffrée
- les machines sont authentifiées
- les utilisateurs sont authentifiés

Pour cela, SSH a mis en place deux mécanismes principaux :
- l'authentification par mot de passe
- l'authentification asymétrique par paires de clés

Je passe sur la première méthode. La seconde fonctionne comme suit :
- On génère une paire de clés, c'est-à-dire des fichiers contenant une série de caractères calculée avec des maths complexes. L'une de ces clés est diffusable (on la dit publique), l'autre doit rester secrète (on la dit privée). Dans la phrase plus haut, "asymétrique" signifie que si j'utilise une clé pour chiffrer, je ne peux pas utiliser la même clé pour déchiffrer.

Du coup, si :
- je chiffre avec la clé publique, seule la clé privée peut déchiffrer. Comme je ne diffuse pas la clé privée, cela garantit que je serai le seul à pouvoir déchiffrer le message.
- je chiffre avec la clé privée : seuls les possesseurs de la clé publique pourront lire le message. Cela ne donne pas de confidentialité puisqu'en général on diffuse la clé publique, par contre, cela garantit que je suis l'émetteur du message puisque je suis le seul à utiliser la clé privée qui correspond à la clé publique. Ce sont ces particularités qu'une connexion SSH va utiliser.

Ca c'est la théorie.

En pratique, on génère une paire de clés. On exporte la publique sur le serveur. Lors d'une connexion SSH, le serveur va chiffrer un message aléatoire et conserver le message en clair de son côté. Le client qui dispose de la clé privée, va déchiffrer le message et présenter son résultat au serveur. Le serveur compare les deux résultats : si ils correspondent le client est bien celui qu'il prétend être.

On peut bien sûr, faire dans l'autre sens pour identifier le serveur. Cette fois c'est le client qui va chiffrer en utilisant la clé privée et demander au serveur de déchiffrer. De même, si ça correspond, le serveur a bien prouvé qu'il était le serveur.

Ensuite, il ne s'agit "que" de configuration. Tu as besoin de détails sur les fichiers ou autre ?

Si tu veux t'entraîner, un tutoriel qui correspond grosso-modo à ce que j'ai expliqué est .

+0 -0
Auteur du sujet

Ca c'est de la réponse constructive ! J'ai bien tout lu et te remercie pour toutes les informations détaillées ! Je prendrais le temps de répondre plus en détails demain, je ne voulais pas laisser ce message sans un bon gros MERCI pour ce soir :)

+0 -0
Auteur du sujet

Désolé pour le temps de réponse, c'est pas très respectueux de ma part vu le temps que ta réponse détaillée a dû te prendre !

Depuis mon sujet initial et tes explications, j'ai un peu planché le sujet pour être bien plus à l'aise avec tout ça et c'est vrai qu'on y voit plus clair quand les fondamentaux sont acquis. Les commandes tapées sont moins hésitantes, on s'attend à tel ou tel résultat !

Je vais tâcher de prendre ton conseil et détailler toutes les actions que je fais quand je bloque sur quelque chose, on le fait souvent pas par "flemme" alors qu'on y gagnerait au final du temps à l'arrivée ;)

Je vais pas reprendre tous les points de ta réponse car je pourrais y mettre un "Ok merci" à chaque vu que tout est clair et détaillé. Franchement bon boulot, tu as dégrossi plusieurs heures de lecture / recherche que j'avais tenté de faire…

Tu as également ôté cette question que j'avais au sujet des termes "privée/publique". Je ne pensais pas que l'identification par clés etait bidirectionnelle. Pour moi, une connexion était autorisée que dans un sens et dans ce sens uniquement. L'hôte a la privée et le client la publique. Mais en fait non, les deux parties s'identifient entre elles.

Ensuite, il ne s'agit "que" de configuration. Tu as besoin de détails sur les fichiers ou autre ?

Comme ça, non pas de réel besoin. Je tâcherais d'y penser si je bloque sur quelque chose à ce sujet :)

Je vais regarder au tuto, ça ne pourra que me faire du bien ^^

Encore merci

Édité par Apo

+0 -0
Vous devez être connecté pour pouvoir poster un message.
Connexion

Pas encore inscrit ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte