Forum Linux.général Script ssh sans mot de passe

Posté par  . Licence CC By‑SA.
2
11
mai
2017

Hello,

J'ai besoin d'automatiser l'envoie de données en ssh (rsync) et je cherche un moyen simple de ne pas ecrire le mot de passe en clair dans le script.
J'ai fourni ma clé publique au propriétaire du serveur mais à chaque tour de boucle rsync me demande de ressaisir à nouveau la passphrase que j'ai utilisé pour créer la paire de clés.

Avez vous une solution simple?

Merci de votre aide

  • # Clé sans passphrase

    Posté par  (site web personnel, Mastodon) . Évalué à 2.

    Oui, fais une clé avec une passphrase vide.

    La gelée de coings est une chose à ne pas avaler de travers.

  • # clé sans mot de passe

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

    Tu n'as qu'à créer et utiliser une clé sans mot passe (tu appuyes sur entrée quand il te demande le mot de passe à utiliser).

    Being a sysadmin is easy. As easy as riding a bicycle. Except the bicycle is on fire, you’re on fire and you’re in Hell.

  • # Utilises un agent ssh

    Posté par  . Évalué à 10. Dernière modification le 11 mai 2017 à 23:10.

    Un agent ssh te permet d'enregistrer ta passphrase pour la session en cours (ou pour une certaine durée configurable).
    La plupart de distribution linux on un agent lancé par défaut avec l'environnement de bureau (ex : Gnome)
    ssh-add
    pour ajouter ta clé à l'agent, les commandes ssh / rsync qui suivent ne te redemanderont pas le mot de passe de la clé.
    man ssh-add pour plus d'infos

  • # rsync en mode serveur

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

    Tu peux utiliser rsync en mode serveur (man rsyncd.conf)

    Ou effectivement une clé ssh sans passphrase, en limitant son utilisation (compte limité, restriction de commande)

    mes 2¢

  • # ssh-agent

    Posté par  . Évalué à 2.

    Hello,

    Merci pour vos réponses.

    Je vais utiliser ssh-agent

  • # Avec expect

    Posté par  . Évalué à 1.

    Je suis bien évidemment d'accord avec les posts précédents mais au cas où il faut passer par un mot de passe, j'utilise ceci pour choper les logs d'un portier/sonnette IP (linux embarqué!) à des fins de débuggage (dans un script bash cronné):

    expect -c "
      set timeout 5
      spawn -noecho scp -p -4C user@host:/var/log/machin.log /destination/
      sleep 2
      expect password: { send lemotdepasse\r }
      sleep 10
      exit
    "
    
    • [^] # Re: Avec expect

      Posté par  . Évalué à 4.

      Tu lui proposes de mettre le mot de passe en clair dans un script expect plutôt que directement dans le script shell ? C’est juste déplacer le problème, non ?

  • # ssh-agent bien sûr, mais pas que

    Posté par  . Évalué à 2.

    ssh-agent est la solution qui semble la plus évidente. Attention il faudra que ton script ait connaissance de la variable d'environnement SSH_AGENT_PID. Pas trop difficile si tu lance ton script dans un shell interactif, un peu plus sioux si tu passe par cron.

    Mais j'utilise une autre solution dans le cas particulier où le besoin est de répéter de multiples connexions ssh dans un temps assez court. On peut en effet faire en sorte que la première connexion soit "réutilisée" par les suivantes en utilisant les options ControlMaster et ControlPersist de ssh (man ssh_config).
    Ça permet de ne faire qu'une authentification, réutilisable pendant n secondes (n fixé par ControlPersist) après la fermeture de la connexion. En plus c'est plus rapide puisqu'on ne repasse pas par la phase d'authentification et ça marche aussi pour plusieurs connexions en parallèle.

    • [^] # Re: ssh-agent bien sûr, mais pas que

      Posté par  . Évalué à 3.

      Avec keychain (mais c'est relativement facile à faire manuellement, keychain est lui-même un script shell) les informations sont stockées dans des fichiers ~/.keychain/-{csh,fish,sh} et il suffit, dans ton script, de sourcer celui qui convient pour utiliser l'agent qui aura été démarré par keychain à la connexion.

Suivre le flux des commentaires

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