Forum Programmation.shell SCP: sans password et surtout sans clé

Posté par  .
Étiquettes : aucune
0
22
nov.
2006
Bonjour a tous,

Mon probleme est assez clair.

La commande scp avec le systeme de clés permet a chaque appel de scp dans mon script de ne me pas me demander le password.

Mais comment peut-on faire si on ne veut pas instaurer le systeme de clés? Dans mon script j'ai 5 scp a faire mais je veux pouvoir moi-meme demander le password, ensuite le mettre dans une variable et ensuite faire un scp avec la variable que j'ai recuperee, c'est-a-dire quelque chose comme:
#!/bin/sh -f

echo taper password
read $mon_passwd1

scp fichier1 user1@hote:/home/tmp<<$mon_passwd1

Quelqu'un a-t-il une solution?
Merci d'avance,
Phil.
  • # Change de langage

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

    En shell (bash, ksh, zsh, ...) à ma connaissance tu ne peux pas passer ton mdp à scp.

    Ta seule solution est d'utiliser soit un langage type expect qui va permettre de détecter/attendre un retour texte d'une commande et de renvoyer un argument. soit utiliser expect dans des langages permettant de l'utiliser au travers d'un API : perl, tcl, ...

    Enfin tu peux utiliser un langage ayant un API SSH comme perl ou ruby avec Net::SSH.
  • # expect

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

    Regarde du côté d'expect ( man: http://www.tcl.tk/man/expect5.31/index.html s'il n'est pas -encore- installé sur ta machine).

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

    • [^] # Re: expect

      Posté par  . Évalué à 2.

      Je vais jeter un coup d'oeil meme si je prefere rester dans une solution du genre scp fichier user1@hote:/home/tmp < $mon_password.

      Merci,
      Phil.
  • # mot de passe: Pas dans la ligne de commande

    Posté par  . Évalué à 2.

    si tu mets ton mot de passe dans la ligne de commande, il apapraîtra dans la liste des processus (commandes: top, ps)
    C'est peut-être pour ça que tu n'y arrives pas d'ailleurs.

    par contre si tu place ce mode passe dans un fichier (avec les bons droits pour pas se le faire piquer) et que tu l'envoies dans le scp, ça marche

    scp fichier1 user1@hote:/home/tmp < mon_fichier_passwd

    ps: j'ai vu une obscure option -B à scp, sans plus d'info...
    • [^] # Re: mot de passe: Pas dans la ligne de commande

      Posté par  . Évalué à 2.

      Merci mais je viens d'essayer ce que tu m'as dit et il continue a me demander le password:

      # scp fichier1 user1@hote:/home/tmp < mon_fichier_passwd
      user1@hote:/home/tmp

      Je ne crois pas que ca change quelque chose mais je travaille sous AIX.

      Phil.
    • [^] # Re: mot de passe: Pas dans la ligne de commande

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

      L'option -B ne marche que si le mot de passe est vide (par exemple, dans le cas ou tu fais une connexion avec des clés et une passpharse vide).

      Benjamin
  • # ssh-agent

    Posté par  . Évalué à 5.

    man ssh-agent

    ssh-agent garde en memoire les cles utilisees pour te logger sur tes diverses machines et les fournit tout seul a chaque fois que tu en as besoin. Si tu penses a mettre un mot de passe pour proteger tes cles, d'un point de vue utilisation ca revient exactement au cas que tu decris:

    La session demarre, tu tapes ton mot de passe pour debloquer ton jeu de cles. A chaque login (ssh/scp), ssh-agent fournit la cle pour toi. En passant: pour scp, pense a enlever les bannieres et autres affichages de texte dans le .bash_login ou .bashrc, il n'aime pas ca du tout et plante avec une erreur incomprehensible.
    • [^] # Re: ssh-agent

      Posté par  . Évalué à 1.

      Bonjour,

      Non, je ne veux pas mettre un mot de passe pour proteger mes cles, je veux tout simplement ne pas utiliser de cles, c'est-a-dire que je cherche une solution pour pouvoir copier des fichiers d'une machine a une autre sans que me soit demande le mot de passe ou alors qu'il me soit demande une fois, je le recupere et ensuite a tous les scp que je fais dans mon script, je l'introduis d'une maniere ou d'une autre et voila le tour est joue...

      A+
      Phil.
      • [^] # Re: ssh-agent

        Posté par  . Évalué à 4.

        Comprends pas tes raisons pour ne pas vouloir utiliser de cles. Un login par mot de passe ca se craque de plein de facons (dictionnaire, timing des paquets, shoulder-surfing, rien d'evident mais autant de vecteurs d'attaque possibles) alors qu'une cle a 1024 ou 2048 bits prendrait l'age de l'univers a craquer. Si tu proteges ton fichier cles avec un mot de passe bien choisi tu limites considerablement les attaques, et le resultat est le meme: tu ne peux pas utiliser la connection tant que tu ne connais pas le mot de passe. La seule difference est que dans un cas il est echange sur le reseau, dans l'autre il est utilise par un process en local pour debloquer des informations, et il reste disponible apres l'avoir tape une fois sans avoir a pondre un script maison.

        ssh propose le login par cles precisement pour contourner les problemes de securite causes par le login via mot de passe, et ssh-agent est la pour te faciliter la vie dans cette voie. Le probleme du stockage du fichier de cles en local est egalement partiellement resolu si tu transportes ton fichier de cles dans... une cle USB.

        Si tu connais Python, tu peux eventuellement regarder aussi 'paramiko', qui encapsule des liaisons ssh (donc scp) de facon relativement elegante, ce qui permet de scripter assez facilement des operations de transfert repetitives. On pourrait imaginer un script qui refuse de se declencher pour les copies tant qu'une cle USB n'a pas ete inseree sur le poste local, contenant un fichier de cles adequats pour le login sur tes machines distantes.

        Bon enfin ce que j'en dis... Peut-etre que tu as d'autres contraintes sur les cles/mots de passe que tu voudrais exposer? Si ton souci principal est un souci de securite, fais attention par exemple au process expect que tu lances (un trojan est si vite installe...).
        • [^] # Re: ssh-agent

          Posté par  . Évalué à 1.

          Je suis d'accord avec toi que question securite, y'a pas mieux que le systeme de cles doublé d'un mot de passe sur le fichier de cles mais le probleme, c'est que je ne suis pas l'administrateur de la machine et chaque fois qu'on doit demander quelque chose, c'est par courrier ou par telephone, ..., d'autant plus que le but est de faire des copies de fichiers d'une machine a 4 autres.
          Alors pour n'embeter personne pour le moment, j'ai voulu cree mon petit script qui m'automatise tout ca.
          Cela dit, j'enverrai mon script aux administrateurs en leur demandant ce qu'ils en pensent et sinon qu'ils nous creent le systeme de cles...

          Merci,
          Phil.
  • # Script shell + expect

    Posté par  . Évalué à 2.

    Finalement, j'ai trouve une solution avec expect comme me l'a ete suggere par l'un d'entre vous. En fait, j'ai 2 scripts (test.sh et script.exp). Dans test.sh, je demande le mot de passe, je le recupere et ensuite je l'envoie comme argument a mon script exp et ca donne quelque chose comme ca:
    SCRIPT test.sh
    --------------------
    #!/bin/sh -f

    echo password du user:
    read p1
    echo OK
    ./script.exp $p1 fichier user@hote:/home/user/tmp"
    echo FIN
    exit 0

    SCRIPT script.exp
    ------------------------
    #!/usr/bin/expect -f

    set force_conservative 0 ;# set to 1 to force conservative mode even if
    ;# script wasn't run conservatively originally
    if {$force_conservative} {
    set send_slow {1 .1}
    proc send {ignore arg} {
    sleep .1
    exp_send -s -- $arg
    }
    }
    set fic [lindex $argv 1]
    set dir [lindex $argv 2]
    spawn scp -r $fic $dir
    set pp [lindex $argv 0]
    send -- "PROCEDURE EN COURS...\r"
    expect -exact "\ruser@hote's password: "
    send -- "$pp\r"
    expect eof


    Voila, voila. J'ai genere mon script expect avec autoexpect et ensuite je l'ai modifie a mon gout.
    Merci a tous,
    Phil.

Suivre le flux des commentaires

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