Forum Astuces.divers [Terminal] Ne plus taper ses mots de passe avec ssh

Posté par  (site web personnel) .
Étiquettes : aucune
0
9
juin
2001
Pour vous loguer facilement et en toute sécurité sur une machine distante, deux étapes suffisent :
- Sur votre machine, faites ssh-keygen. Si vous avez confiance dans la machine (et dans root), vous pouvez laisser la passphrase vide.
- Copiez le contenu du fichier ~/.ssh/identity.pub dans un fichier nommé ~/.ssh/authorized_keys sur la machine distante.
Si vous avez opté pour une passphrase, il vous faudra lancer ssh-agent à chaque login (je vous recommande la lecture de la page de man). Sinon, ssh machine_distante marchera sans demander de mot de passe, mais sans altérer la sécurité comme le fait le .rhosts.

  • # ssh-copy-id : un petit script pour copier facilement ses clefs

    Posté par  . Évalué à 1.

    ssh-copy-id iouseure@machine_distante s'occupe de copier les clefs sur la machine distante.
    On peut lui préciser les clefs à copier, mais par défaut le script prendra les clefs stockées par ssh-agent (ssh-add -L)

  • # Re: Ne plus taper ses mots de passe avec ssh

    Posté par  . Évalué à 1.

    Attention à ne pas trop utiliser ce genre de choses avec le cvs de daCode, particulièrement si vous vous appelez w**f.

  • # Re: Ne plus taper ses mots de passe avec ssh

    Posté par  . Évalué à 1.

    « Si vous avez confiance dans la machine (et dans root), vous pouvez laisser la passphrase vide. »

    Ce qui semble parfaitement stupide : une machine crackée permetterait de cracker les autres dans la foulée.

  • # Pub : les pages man de ssh existent désormais en français

    Posté par  . Évalué à 1.

    Voir http://www.delafond.org/traducmanfr/ Au 19-11-02, toute la partie relative au client est traduite. scanssh.1 scp.1 sftp.1 ssh.1 ssh-add.1 ssh-agent.1 ssh_config.5 ssh-copy-id.1 ssh-keygen.1 ssh-keyscan.1 x11-ssh-askpass.1 Pour la partie serveur, attendre un peu ... ;) ssh-keysign.8 est déjà traduit Restent sshd.8 et sshd_config.5 (ça arrive !)

  • # Re: Ne plus taper ses mots de passe avec ssh

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

    et pour ceux qui trouvent ca trop difficile a gerer, keychain est votre ami.
    http://www.gentoo.org/proj/en/keychain.xml(...)

  • # Re: Ne plus taper ses mots de passe avec ssh

    Posté par  . Évalué à 1.

    Venant de passer une journée à rendre compte de ça, je tiens à vous partager ma découverte :

    Il faut que les fichiers authorized_keys* soient en rw pour le owner uniquement (600), sinon ça ne fonctionne pas, la clef n'est pas acceptée.

    Voilà.

    • [^] # Re: Ne plus taper ses mots de passe avec ssh

      Posté par  . Évalué à 1.

      authorized_keys* en go-rw : pas forcément ; pour ma part ça marche alors que: 
      -rw-r--r--    1 salagnac kronos        606 Dec  2 08:45 authorized_keys

      • [^] # Re: Ne plus taper ses mots de passe avec ssh

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

        Ya une option dans le fichier de configuration global qui permet d'activer ou non le refus de connection si les fichiers de configuration utilisateur n'ont pas les bons droits je pense.

        pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

  • # Quelques remarques....

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

    Quelques remarques sur l'utilisation de ssh:
    • Toutes les clés devraient avoir une passphrase. Un vol de clés ssh est vité arrivé.
    • En théorie, on ne devrait avoir qu'un seul ssh-agent ouvert à la fois. Ne lancer surtout pas votre agent dans le fichier de configuration de votre shell. Lancez le dans votre .xsession avec une commande du genre ssh-agent winmanager. Ainsi tous les nouveaux sous-processus (tous les shell donc) utiliseront le même agent ssh. Utilisez toujours l'option -A de ssh pour faire suivre (forwarder) votre agent (mettre un alias est une bonne idée). Ainsi, il n'y qu'un agent ssh lancé (sur la machine ou vous êtes physiquement connecté), mais il est utilisé sur toutes les machine distantes sur lesquelles vous êtes connecté.
    • En respectant les règles ci-dessus, vous remarquerez que vous n'avez besoin de taper votre passphrase qu'une seule fois pour toute votre session (le matin en arrivant). Si ca n'est pas le cas, c'est qu'il y a un problème dans votre système (plusieurs ssh-agents lancés, ssh-agent pas forwardé).
    • ssh-add permet d'enregistrer les identités locales sur votre agent. Une bonne idée est de lancer cette commande dès que vous vous connectez. Il existe des outils graphiques qui permettre d'avoir une fenêtre toute jolie pour ca. Ssh-askpass par exemple.
    • Correctement utilisé, votre agent retient vos identités. Imaginons que vous vous connectez physiquement sur A. Pour vous connectez sur C, vous avez besoin d'une clé se trouvant sur B. Normallement, vous devriez vous connecter sur B, puis sur C à partir de B. Avec ssh-agent: 
        A$ ssh B
  B$ ssh-add
  B$ exit
  A$ ssh C
  C$
      Votre agent a retenu l'identité que vous lui avez fournis lorsque vous étiez connecté sur B.
    • ssh-add -x permet de bloquer votre ssh-agent (quand vous allez prendre un café)

  • # script pour décharger les clefs en fonction d'xscreensaver

    Posté par  . Évalué à 1.

    Ce petit script de rien du tout permet de vider l'agent de ses clef quand on verrouille la session via xscreensaver. Quand on déverrouille la session, il recharge les clefs et redemande la (les) phrase(s) de passe. A lancer dans le .xsession ou via le Desktop Manager, comme ssh-agent. 
    #!/usr/bin/perl
# unload identity when screen is locked

# put your favourite graphical ssh-askpass here, unless you use SSH_ASKPASS
# environment variable
my $ssh_askpass = "/usr/lib/openssh/gnome-ssh-askpass";

$ENV{SSH_ASKPASS} = "$ssh_askpass" unless ($ENV{SSH_ASKPASS});

my $locked;
open (IN, "xscreensaver-command -watch |");
while () {
    if (m/^LOCK/) {
            system("ssh-add -d") if (! $locked);
            $locked = 1;
    } elsif (m/^UNBLANK/) {
            system("ssh-add < /dev/null") if ($locked);
            $locked = 0;
    }
}

Suivre le flux des commentaires

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