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

Posté par  . Licence CC By‑SA.
Étiquettes :
1
19
nov.
2013

Bonjour

Je rencontre un souci actuellement avec un serveur openssh sous windows.
J'ai un client ssh linux qui doit se connecter au serveur openssh sous windows, afin de récupérer un certain nombre d'info sur des logs.

Le client ssh-linux est un batch, il faut donc que je puisse m'authentifier sans avoir à rentrer un mot de passe, sous peine d'arrêter mon script en plein milieu.

J'ai suivi cette procédure :

http://www.linuxproblem.org/art_9.html

Mon utilisateur toto est déclaré sur mon serveur windows.
Pour clarifier je veux pouvoir faire et je veux pouvoir faire depuis ma bécane linux 

john@linux-host$ ssh toto@ssh-windows

sans donner mon mot de passe.

Mais rien à faire, j'ai tjrs le prompt qui me demande un mdp.

Mon doute se situe au niveau de la clé à exporter :
Est ce que je me suis trompé en exportant le fichier john/.ssh/id_rsa.pub vers c:\Users\toto\.ssh\authorized_keys ?
J'ai également généré mes clés avec ssh-keygen -t rsa sous utilisateur john sur la becane linux.

Merci par avance pr les coups de main.

  • # demande à ton admin windows

    Posté par  . Évalué à 1. Dernière modification le 19 novembre 2013 à 18:02.

    vu que c'est un probleme windows,
    ici tu es sur LINUXfr

    bon, treve de plaisanterie,

    sur mon windows7, le dossier de l'utilisateur se trouve dans c:\User s \monlogin

    dans ton post, tu dis que tu l'as mis dans c:\User\toto (sans le s à la fin de users)

  • # verbose

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

    essaies:

    ssh -vvv user@host

    Système - Réseau - Sécurité Open Source

  • # Configuration du serveur

    Posté par  . Évalué à 6. Dernière modification le 19 novembre 2013 à 18:45.

    Il faut que tu modifies la configuration du serveur (la machine à laquelle tu te connectes, c'est-à-dire la machine windows si j'ai bien compris) pour lui indiquer de ne plus demander de mot de passe. C'est bizarre que ça ne soit pas indiqué dans la procédure que tu cites. Sur mon serveur Debian, la configuration du serveur est dans /etc/ssh/sshd_config et j'ai mis les lignes suivantes :

    PermitRootLogin no
    PasswordAuthentication no
    AuthorizedKeyfile %h/.ssh/authorized_keys
    ChallengeResponseAuthentication no
    UsePAM yes

    • [^] # Re: Configuration du serveur

      Posté par  . Évalué à 2. Dernière modification le 20 novembre 2013 à 08:18.

      Ah ! Je ne sais pas si c'est mieux mais j'ai un Permission denied (publickey) maintenant.
      Je regarde un peu l'origine de cette erreur.
      Merci pr ta réponse.

      • [^] # Re: Configuration du serveur

        Posté par  . Évalué à 3. Dernière modification le 20 novembre 2013 à 11:53.

        Tu peux essayer de changer la ligne AuthorizedKeyfile. La chaine %h/.ssh/authorized_keys fonctionne avec un serveur linux, peut-être que pour Windows il faut utiliser la syntaxe locale (C:\Users...) ou peut-être avec \ \ à la place de \ .

        Comme explique la réponse de nono14 plus haut, passe l'option -vvv quand tu te connectes, tu auras plus de détails sur la source de l'erreur.

        Essaie aussi de jouer avec les différentes options en mettant yes ou no. Pour certaines combinaisons il va te redemander le mot de passe. Je me souviens avoir eu un peu de mal au début à trouver la combinaison d'options qui marchait pour moi. Tu peux regarder à man sshd_config sur la machine linux pour avoir l'explication des options.

  • # ssh-copy-id

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

    Extrait du man

    ssh-copy-id  -  install  your  public  key in a remote machine's autho‐rized_keys

    Après ça tu te conencte sans entrer de mot de passe et sans abaisser la sécurité du serveur

    • [^] # Re: ssh-copy-id

      Posté par  . Évalué à 4.

      il faut peut-etre preciser qu'il faut lancer le ssh-copy-idsur le poste client avec comme destination le serveur.
      ex :
      ssh-copy-id user@server

Suivre le flux des commentaires

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