Forum Programmation.shell [résolu] Problème avec SSH/rsync... incompréhensible

Posté par  (Mastodon) . Licence CC By‑SA.
Étiquettes :
3
19
juil.
2021

J'espère ne pas poster au mauvais endroit, mais j'ai pas trouvé de rubrique plus adaptée.

Donc, hello ;)

Je vous explique mon problème. D’abord ce qui marche. Sur un 1er serveur, pour directement me connecter en SSH au dossier dont j'ai besoin et le mettre à jour avec du contenu local, j'utilise une commande qui ressemble a ceci :

rsync -a --delete -e ssh /local/path/* user@serveur1.truc:/path/to/folder

Aucun souci.

Ce qui ne marche pas. Sur un autre serveur (disons serveur2, qui est hosté par le même hébergeur d’ailleurs), si je tape :

rsync -a --delete -e ssh /local/path/* user@serveur2.truc:/path/to/folder

Il me retourne un laconique "ssh: Could not resolve hostname".

Même souci quand j’utilise l’adresse IP à la place du nom de domaine.

Pourtant, et c’est là où je commence a perdre pied, si je fais un ssh user@serveur2.truc, il se connecte sans souci pour ensuite gentiment me laisser cd dans /path/to/folder. Le truc que je ne parviens pas à faire, c’est de me connecter a ce dossier du 1er coup.

Par curiosité, j'ai tenté de créer un raccourci dans ma ssh config qui, lui aussi, se connecterait directement au bon dossier. Genre :

Host MonRaccourci
  Hostname serveur2.truc
  Port XX
  User user
  RequestTTY yes
  RemoteCommand cd /path/to/folder;  exec $SHELL

Ca marche. Yeah. Sauf que… j’ai besoin de cette connexion pour mettre à jour le dossier via un script. Mais je ne trouve pas comment utiliser le raccourci de ma ssh config dans un script shell. Et puis, j'aimerais aussi piger où est le souci avec la connexion SSH, si c'est possible.

Si c’était pas déjà évident, je suis tout sauf un pro des serveurs et là je sèche. Je suis preneur de toute suggestion/greffe de neurones :

  1. Pourquoi taper la connexion rsync/SSH avec accès au sous-dossier marche sur le serveur 1, mais pas sur le serveur 2—alors que ça marche si je le fais en deux étapes (connexion et puis cd dans le dossier), et que ça marche aussi via un raccourci dans mon ssh config. WTF ? comme aurait dit ma grand-mère ?
  2. Est-il possible d’utiliser dans un script shell un raccourci défini dans le ssh config ? Si oui, komankonfè ? Vu comment ce problème commence à me sortir par les yeux, il est n’est pas totalement à exclure que je sois passé à côté de l’info mais, vraiment, je ne trouve pas.

Help, quelqu’un(e)? (et merci d'avoir lu, je me sens symboliquement déjà moins seul ;))

  • # authorized_keys + command

    Posté par  . Évalué à 2. Dernière modification le 19 juillet 2021 à 21:49.

    Pour ta dernière question (Est-il possible d’utiliser dans un script shell un raccourci défini dans le ssh config), peut-être que le mécanisme qui associe une clé à une commande peut t'aider. L'idée est que quand on se connecte avec une clé particulière, une commande spécifique est lancée. Les paramètres d'origine de la commande ssh dans la variable SSH_ORIGINAL_COMMAND.

    Je m'en sers en général en envoyant des données en base64 qui se retrouvent dans $SSH_ORIGINAL_COMMAND, et décodées et traitées par la commande spécifiée dans le authorized_keys.

    Voir dans le man de sshd la section AUTHORIZED_KEYS FILE FORMAT.

    En tout cas, chez moi ssh user@serveur1.truc:/path/to/folder ne fonctionne pas (Name or service not known), et le man de ssh n'indique en rien que ça devrait fonctionner ;).

    • [^] # Re: authorized_keys + command

      Posté par  (Mastodon) . Évalué à 1. Dernière modification le 19 juillet 2021 à 22:04.

      Merci et toutes mes excuses pour les imprécisions dans mon post.

      J'ai édité les commandes de mon exemple et le titre du post, vu que j'avais transcrit a peu près n'importe quoi (pour comprendre pourquoi, sans doute il faut se référer à la partie où je confesse ne plus avoir les yeux en face des trous et être tout sauf un pro ;)). Ce qui ne marche pas, c'est donc quand je tente de faire un rsync sur le dossier en question. Le souci reste a peu près le même je pense : la commande rsync + ssh au serveur 1 fonctionne et pas pas sur le serveur 2, et je ne parviens pas à piger pourquoi.

      Edit: je vais lire la section dont tu parles, merci encore ;)

      • [^] # Re: authorized_keys + command

        Posté par  . Évalué à 2.

        Ah oui c'est plus clair… et plus étrange :D.

        essaye voir avec rsync -vv -a --delete -e ssh ..., comme ça tu verras la commande ssh qu'il essaye de lancer pour de vrai :

        /tmp/a$ rsync --dry-run -avv --delete -e ssh /tmp/a/* localhost:/tmp/b/
opening connection using: ssh localhost rsync --server -vvnlogDtpre.iLsfxCIvu --delete . /tmp/b/  (8 args)
charles@localhost's password:
sending incremental file list
delta-transmission enabled
hello
la rache
total: matches=0  hash_hits=0  false_alarms=0 data=0

sent 99 bytes  received 53 bytes  60.80 bytes/sec
total size is 12  speedup is 0.08 (DRY RUN)

        (et à priori depuis quelques années, ssh est la commande par défaut, donc le -e serait superflu)

        • [^] # Re: authorized_keys + command

          Posté par  . Évalué à 2.

          rsync -a --delete -e ssh /local/path/* user@serveur2.truc:/path/to/folder
          Il me retourne un laconique "ssh: Could not resolve hostname".

          Plus précisément, est-ce que dans la suite du message d'erreur "Could not resolve hostname", ssh mentionne bien "serveur2.truc", ou autre chose ? 

          ~$ rsync -a /tmp/ bidon.hellothere.com:
ssh: Could not resolve hostname bidon.hellothere.com: Name or service not known
rsync: connection unexpectedly closed (0 bytes received so far) [sender]
rsync error: unexplained error (code 255) at io.c(228) [sender=v3.2.3]

    • [^] # Re: authorized_keys + command

      Posté par  (site web personnel, Mastodon) . Évalué à 2. Dernière modification le 20 juillet 2021 à 01:26.

      Normal, la partie derrière le @ correspond au serveur auquel il ne sait pas se connecter. Mais comme le message indique bien la machine, je soupçonne que soit le message coupe au : ou alors la connexion est tentée avec le port /path/to/folder ?
      En fait il y a confusion avec la syntaxe de scp ; en ssh on lance une commande et non un chemin, et si la commande est un shell interactif c'est dans celui-ci qu'on va se positionner dans le répertoire ensuite.

      “It is seldom that liberty of any kind is lost all at once.” ― David Hume

  • # Raccourci

    Posté par  . Évalué à 2.

    Mais je ne trouve pas comment utiliser le raccourci de ma ssh config dans un script shell

    ssh MonRaccourci ?

  • # ~/.ssh/config

    Posté par  . Évalué à 2.

    De mémoire, pendant le p'tit déj, sans vérifier, est-ce que Host MonRaccourci ne devrait pas se trouver dans un fichier ~/.ssh/config (nom à vérifier) ?

  • # Logs détaillés?

    Posté par  (site web personnel) . Évalué à 3. Dernière modification le 20 juillet 2021 à 08:49.

    Il me retourne un laconique "ssh: Could not resolve hostname".

    Même souci quand j’utilise l’adresse IP à la place du nom de domaine.

    C'est peu probable que ssh ait un problème à résoudre … une adresse IP. Le mieux serait que tu partages les logs en entiers – en remplaçant les informations que tu veux protéger par des arguments génériques comme tu l'as fait.

    Pour la présentation tu peux faire comme ça (triple tilde, regarde la syntaxe markdown dans les liens au bas de la page).

    ➜  ~ rsync -a -e ssh ./. user@192.168.0.1:/path/to/folder
ssh: connect to host 192.168.0.1 port 22: Connection refused
rsync: connection unexpectedly closed (0 bytes received so far) [sender]
rsync error: error in rsync protocol data stream (code 12) at …

    Pour utiliser ton .ssh/config dans les scripts il n'y a rien de spécial à faire. Tu peux utiliser ssh-add pour ajouter les clefs nécessaires au ssh-agent avant l'exécution du script. Tu peux aussi utiliser une configuration alternative (pour le script, différente de celle pour l'utilisateur).

  • # Caractère jocker dans rsync ?

    Posté par  (Mastodon) . Évalué à 3. Dernière modification le 20 juillet 2021 à 08:52.

    Il me semble que ton rsync path/* n'est pas bon à la base, il me semble que rsync ne s'attendant que à un seul paramètre pour la source.

    Il considère donc le 2e répertoire de ta liste comme la cible : et là il ne peut évidemment pas résoudre le nom.

    Il te faut préciser le répertoire parent et éventuellement la récursivité (j'utilise peu rsync, mais -avr est mon grand classique).

    En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

    • [^] # Re: Caractère jocker dans rsync ?

      Posté par  (site web personnel) . Évalué à 5.

      Il me semble que ton rsync path/* n'est pas bon à la base, il me semble que rsync ne s'attendant que à un seul paramètre pour la source.

      Je viens de vérifier, rsync 3.2.3 ne semble avoir aucun souci à avoir des sources multiples dans une seule commande. Du style rsync source1 source2 destination.

  • # Wow + merci + auto-baffage

    Posté par  (Mastodon) . Évalué à 4. Dernière modification le 20 juillet 2021 à 10:31.

    Wow, tant de conseils et de suggestions. Un très grand merci à chacun(e). Pour éviter le bruit, je ne vais pas répondre à chaque message directement. Si vous avez des questions, je reste dispo bien entendu— les éventuels (et mérités) sarcasmes seront acceptés avec sérénité, aussi ;)

    En dehors du fait que j'étais réellement HS, hier, et que je mélangeais tout. Grâce à vos remarques j'ai trouvé la motivation pour tout reprendre à zéro, au lieu de râler devant mon écran en maudissant l’informatique. Je suis reparti de la commande qui marchait sur le 1er serveur, en la comparant et en réécrivant (sans copier-coller) instruction par instruction pour réaliser que, depuis le début, depuis le tout premier essai foireux sur le serveur 2, je recopiais une coquille dans l'adresse.

    Le souci était donc bien que le path indiqué était foireux — partez pas je reviens dans une petite minute, je retourne me baffer la tronche ;)

    La commande fonctionne donc de la même façon sur les serveurs 1 et 2:

    rsync -a --delete -e ssh /local/path/* user@serveur1(ou2).truc:/path/to/folder

    Sinon, pour info :

    • oui, le raccourci 'Host MonRaccourci" est enregistré dans le ~/.ssh/conf avec les autres raccourcis que j’utilise.
    • oui, appeler le raccourci de ce host via un ssh MonRaccourci fonctionne, my bad.

    Conclusion et morale*s* de cette histoire :

    1. Encore une fois, merci beaucoup. Sans vos commentaires/suggestions, j'aurais jamais fait l'effort de reprendre à zéro et j'aurais sans doute jamais trouvé mon erreur.
    2. Il ne faut jamais, jamais forcer les choses. Quand un truc marche pas, faire un break pour se donner le droit de penser à tout autre chose (par exemple, à la pénible séance d'auto-baffage à laquelle on va échapper simplement parce qu'on aura pris le temps de penser à autre chose et de réfléchir).
    3. (re)lire les docs. On en sait jamais assez.
    4. Toujours écouter les gens qui savent :p

    • [^] # Re: Wow + merci + auto-baffage

      Posté par  (site web personnel) . Évalué à 4. Dernière modification le 20 juillet 2021 à 11:06.

      Bravo à toi! J'ajouterai une petit 5.:

      1. Vérifier méthodiquement et humblement que toutes les hypothèses qu'on croit vraies le sont.

      L'idée est d'avoir une démarche aussi scientifique que possible en construisant un énoncé de type “Étant donné que ceci, je fais cela, et m'attends à ça. Mais je vois autre chose.” et de procéder méthodiquement pour circonscrire de plus en plus l'incertitude pour finalement trouver ce qu'on croit et qui n'est pas vrai.

      Ici les hypothèses sont, par ordre de complexité de vérification croissante:

      • J'ai construit une ligne de commande valide. (Vérifier bout à bout chaque argument.)
      • J'ai accès au réseau.
      • Mon système peut résoudre les noms de domaines (cf. le message d'erreur que tu as mentionné).
      • J'utilise bien le programme rsync que je crois (si plusieurs versions sont installées).
      • J'utilise bien le programme ssh que je crois (idem).
      • Je n'utilise pas une version de rsync qui a une bogue bien connue.

      etc.

      L'auto-baffage ne semble pas utile, toutes les erreurs sont évidentes lorsqu'on les a découvertes!

      • [^] # Re: Wow + merci + auto-baffage

        Posté par  . Évalué à 2. Dernière modification le 20 juillet 2021 à 11:21.

        Hors sujet (humour):

        L'auto-baffage ne semble pas utile

        How to irritate people indian restaurant

      • [^] # Re: Wow + merci + auto-baffage

        Posté par  (Mastodon) . Évalué à 2.

        Vérifier méthodiquement et humblement que toutes les hypothèses qu'on croit vraies le sont.

        Yep. C'est exactement ça et c'est, très exactement aussi, ce que j'ai persisté à ne pas faire hier—je reviens tout de suite, je vais m'auto-b…

        L'auto-baffage ne semble pas utile,

        Bon, ok, je veux bien te croire. N'empêche, s'auto-baffer (comme s'auto-botter les fesses, sauf que ça demande déjà un peu plus de motivation) ça aide à évacuer la frustration ;)

    • [^] # Re: Wow + merci + auto-baffage

      Posté par  (site web personnel) . Évalué à 4.

      Quand un truc marche pas, faire un break pour se donner le droit de penser à tout autre chose

      De mon expérience, c’est très difficile quand on a le nez dans le problème ;)

      Probablement une histoire d’escalade d’engagement ou autre processus dans ce style…

      • [^] # Re: Wow + merci + auto-baffage

        Posté par  . Évalué à 4.

        je plussois, le nombre de fois ou madame me sort de ma boucle de 'ca marche pas', en me forçant à prendre une pause, un repas, une douche, ou meme essayer de lui expliquer le "çà marche juste pas"…

        et que du coup, ben je trouve le pourquoi …

        • [^] # Re: Wow + merci + auto-baffage

          Posté par  (site web personnel) . Évalué à 2. Dernière modification le 22 juillet 2021 à 03:49.

          ah, moi je parle à mon canard, je lui explique jusqu'à ce qu'il comprenne :-) et c'est là où je vois que j'ai merdé

          J'ai la même avec les démonstrations, genre ça marchait lors des répétitions :/

    • [^] # Re: Wow + merci + auto-baffage

      Posté par  (Mastodon) . Évalué à 1.

      Ça pourra faire une entrée dans pebkac-ng.fr ;)

      (Mais que celui qui n'a jamais fait ce genre de bourde me jette le premier clavier)

    • [^] # Re: Wow + merci + auto-baffage

      Posté par  (site web personnel) . Évalué à 3. Dernière modification le 21 juillet 2021 à 15:58.

      Ca me rappelle la fois où j'ai cherché comme un con pendant un quart d'heure pourquoi un script PHP indiquait une erreur de syntaxe alors que la ligne concernée me paraissait tout à fait valide.
      Comme c'était un bon gros IF avec une condition multiple, une ligne assez balaise, j'ai bien lu le truc au mois 20 fois, fait quelques modifs, simplifié la condition, … toujours pareil.
      En désespoir de cause, je dérange le collègue pour qu'il vienne jeter un oeil, il regarde, ne comprend pas non plus pourquoi ça merde, et là on se regarde comme des cons, on se croit passés dans la 4ème dimension.
      En désespoir de cause, je commente la ligne et la réécrit entièrement en dessous, à l'identique … et ça marche. WTF !?
      Finalement j'ai trouvé le pourquoi du comment : en tapant vite sur un clavier français (à l'époque), l'espace avant l'accolade avec aussi bénéficié du AltGr. Donc à l'écran j'avais un bel espace qui n'en était pas un, c'était en réalité un AltGr+espace que l'interpréteur PHP ne considère pas comme un espace (à tort ou à raison, en fait je ne vois pas bien l'utilité qu'un caractère AltGr+espace pourrait avoir, mais il y en a peut-être une).
      Bref, depuis je ne fais plus 100% confiance à ce que je vois.

      • [^] # Re: Wow + merci + auto-baffage

        Posté par  . Évalué à 2.

        AltGr+espace permet de créer un espace insécable. Cest très utile pour de l'affichage en frontend, si tu veux éviter un retour à la ligne malencontreux en responsive par exemple (le retour à la ligne ne doit pas être fait avant la ponctuation)

        Genre :
        ~~~
        Voulez-vous quitter ?
        ~~~
        Qui serait affiché
        ~~~
        Voulez-vous quitter
        ?
        ~~~

        En édition dans vim ou autre, on ne vois pas la diff, mais dans un éditeur style Pycharm, on vois une diff.

        Ma faible expérience ma fait découvrir cette subtilité au boulot ;)

        • [^] # Re: Wow + merci + auto-baffage

          Posté par  (site web personnel) . Évalué à 1. Dernière modification le 22 juillet 2021 à 06:01.

          Merci, j'en étais resté au bon vieux   en HTML, on ne peut pas le louper, celui là.
          L'interpréteur PHP pourrait donc considérer ce AltGr+espace comme un espace si en dehors d'une chaine de caractères, mais c'est peut-être plus difficile à faire qu'à dire.
          Et puis je n'utilise plus de clavier français depuis des années, du coup je n'ai plus ce problème.

    • [^] # Re: Wow + merci + auto-baffage

      Posté par  . Évalué à 1.

      Btw rsync -e ssh … est redondant (par défault, rsh = ssh).
      Par contre pour te passer d'un /.ssh/config, tu peux faire rsync -e "ssh -o Host=un.hote -o port=22 -o … " src dst.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.