Ssh : connexion non réversible?

Support Debian
#1

bonjour,

ayant mis en service le protocole ssh entre mon portable ( le client ?) et un ssd externe ( le serveur ?) protégé par une clé d’autentification j’ai donc un fichier .ssh/id_rsa.pub qui est apparu dans mon /home . Tout fonctionne correctement .

Si je veux initier une connexion ssh à partir de ce ssd , qui change donc de statut et devient le client si j’ai bien compris , la connexion est refusée . Je suppose , sans en être sûr , que c’est parce que je n’ai pas défini de clef publique à partir de ce ssd et que le fichier .ssh/id_rsa.pub n’existe pas .

Question : faut-il générer une autre clef publique à partir de ce ssd ou bien faut-il copier celle qui existe sur mon portable ? Ou bien aucune de ces solutions n’est correcte et j’ai tout faux ?

#2

Un clé, une connexion, un sens c’est le mieux :wink:
Depuis ton serveur tu doit initier la génération d’une clé et l’exporter vers ton poste dans le fichiers .ssh/authorized_keys de l’utilisateur cible.

Il y a pléthore de guide pour gérer tous ça;

#3

problème réglé en utilisant une clé usb pour transférer la clé publique du ssd vers le portable, dans un fichier authorized_keys créé pour l’enregistrer , car je n’ai pas su corriger l’erreur ci-dessous

ssh-copy-id -i .ssh/id_rsa.pub mm@xxxxxxxxx/home/mm/.ssh/authorized_keys
/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: ".ssh/id_rsa.pub"
/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: Could not resolve hostname xxxxxxxx/home/mm/.ssh/authorized_keys: Name or service not known
#4

la commande ssh-copy-id n’a pas trouvé d’hôte qui serait nommé :
xxxxxxxx/home/mm/.ssh/authorized_keys

mais elle aurait sans doute pu trouver l’hôte nommé :
xxxxxxxx

Voir le manuel de la commande ssh-copy-id :

man ssh-copy-id

dont voici un extrait :

… By default it adds the keys by appending them to the remote user’s ~/.ssh/authorized_keys (creating the file, and directory, if necessary). …

Quoi qu’il en soit, ce n’est pas plus mal,
car en allant manuellement déposer ta clef publique au bon endroit,
tu auras évité à coup sûr le man in the middle

#5

je crois que j’ai compris l’erreur ( pas bien sûr quand même ) . J’ai fait un copié-collé d’une commande prise sur un tutoriel à Use ssh-keygen to create SSH key pairs and more . Peut-être qu’en la modifiant légèrement selon :
… xxxxx:~/home/mm/etc… l’hôte aurait pu être reconnu ( je prends exemple sur les commandes scp que j’utilise ) .

Je n’avais pas du tout pensé à cette histoire d’homme du milieu . Je vois qu’avant de me lancer dans l’utilisation de ssh non plus seulement localement mais à distance en passant par internet j’ai encore pas mal d’échauffement à faire .

merci pour ces précisions . Je vais regarder le manuel .

#6

plutôt sans le tilde :

… xxxxx:/home/mm/etc…

#7

exact ! ou bien xxxx:~/.ssh/…

#8

Attention quand même, car l’interpréteur de commandes bash, avant de lancer l’exécution de la ligne de commandes, remplacera ce tilde par le chemin absolu du répertoire personnel du compte utilisateur qui lancera la commande, mais ce chemin
ne sera peut-être pas le même chemin que celui du répertoire personnel du compte utilisateur distant auquel tu comptes accéder.

Dans une ligne de commande(s), avec les touches flèches
déplace le curseur sur le caractère tilde et appuie sur Échapet de suite après sur &

#9

je viens de renommer authorized_keys en authorized_keys_backup pour tester cette hypothèse
et effectivement cela résoud bien le Could not resolve hostname xxxxxxxx/home/mm… mais conduit à access denied . Ça me semble normal puisque je n’ai encore configuré aucun protocole ssh entre le ssd et mon portable .
The ssh-copy-id tool is included in the OpenSSH packages in many distributions… For this method to work, you must currently have password-based SSH access to your server.

Attention quand même, car l’interpréteur de commandes bash , avant de lancer l’exécution de la ligne de commandes, remplacera ce tilde par le chemin absolu du répertoire personnel du compte utilisateur qui lancera la commande,

je vais tester cette remarque en utilisant le protocole scp pour transférer un fichier .

mm@Xfce:~$ scp .profile1 mm-lvm@192.168.1.18:~

a bien transféré le fichier .profile1 de /home/mm à ~ interprété correctement comme étant /home/mm-lvm .
conclusion : je n’ai pas compris cette remarque

#10

là, tu as deux systèmes sur lesquels il y a le même nom de compte utilisateur qui a été créé,
donc le nom du chemin du répertoire personnel de ces deux comptes utilisateur est le même.

Mais si tu voulais, depuis le compte utilisateur mm-lvm d’une machine, envoyer une clef sur un autre système dans, par exemple, le fichier .ssh/authorized_keys du compte utilisateur d’une autre machine, le chemin du répertoire personnel du compte utilisateur zao ne serait pas :
/home/mm-lvm mais /home/zao et du coup, ça ne fonctionnerait pas.

Qu’est-ce que tu appelle ssd ?

ssh est utilisé pour permettre de communiquer entre deux systèmes,
alors que ssd est un type de support de données.

#11

il s’agit d’un ssd externe sur lequel j’ai un S.E debian 11 autonome que je peux transporter si besoin . Il m’a servi à tester la mise au point d’un 2ème protocole ssh entre ce debian 11 ( chez moi le ssd fonctionne avec un asus avec W10 ) et mon portable LDLC . Ceci juste pour voir si ssh était réversible ( j’ai un protocole ssh fonctionnel du portable vers ce ssd ) et aussi pour vérifier ceci :
The ssh known_hosts file is a file that stores the public key of all of the servers that you have connected using ssh.
Et donc :
1- ssh est à sens unique
2- mon fichier .ssh/known_hosts de mon portable reste désespérément vide .

#12

Si tu as réussi à établir une connexion vers un autre système en utilisant ssh
c’est parce qu’il existait sur cet autre système un serveur ssh (du paquetage openssh-server) qui attendait de recevoir une demande de connexion et qui y a répondu après avoir vérifié qu’elle était authentifiable.

Et bien sûr, logiquement, il sera impossible d’établir une connexion par ssh vers un système sur lequel il n’y aurait pas de serveur ssh installé et fonctionnel.

1 J'aime