• # ssh : bien plus qu'un telnet crypté

    Posté par . En réponse au message Utilisation pratique d'openssh. Évalué à 1.

    Sans même rentrer dans le sujet des tunnels (que j'utilise peu), je suis fan de l'exécution de commande non interactive et de redirection de l'entrée et la sortie standard par ssh.

    Ca permet de faire plein de trucs sympa, comme un tar à la volée de données distantes :

    ssh user@monserver "tar cf - /mondossier" > mondossier.tar

    Pratique si on n'a pas rsync, et qu'on veut conserver les attributs des fichiers par exemple :

    ssh user@monserver "cd /mon/chemin ; tar cf - mondossier" | tar xvf -

    Encore plus fort, d'un serveur à un autre en passant par la machine locale :

    ssh user@monserver "cd /mon/chemin ; tar cf - mondossier" | ssh user@monserver2 "cd /mon/chemin2; tar xvf - "

    Ca marche avec n'importe quoi, on peut exécuter une commande sur un hôte et nourrir une boucle sur un autre, la puissance du shell à travers le réseau, comme avec netcat mais chiffré et authentifié. Evidemment il faut faire attention à l'échappement des caractères, et au fait qu'une variable valide localement ne l'est pas sur le serveur (ou pire, pourrait avoir une valeur différente).

    On peut même faire du "rebond" à peu de frais :

    ssh -A -t user@srv1 ssh -A user@srv2

    (le -A sert pour la propagation de l'agent, attention à ne faire que sur des hôtes de confiance... Et le -t pour forcer l'allocation d'un pseudo-terminal même si on lance une commande non-interactive, sans ça impossible de lancer une session interactive dans le rebond).


    Un dernier truc bon à savoir : les variables d'environnement SSH_CLIENT et SSH_CONNECTION contiennent respectivement l'ip source, le port source et le port destination, et l'ip source, le port source, l'adresse de destination et le port de destination. Ca peut servir.

    Allez encore quelques-un, rapide, pour la route :

    - Les shells qui ont une completion évoluée peuvent souvent faire de la completion de nom de fichier à travers scp si on a une clef pour se connecter au serveur et un agent,
    - lftp supporte sftp, il suffit d'utiliser sftp://
    - si on a un domaine kerberos (ou quelque chose qui y ressemble, comme un active directory), et que c'est le moyen d'authentification, on peut faire du single sign-on en autorisant l'authentification GSSAPI (côté serveur et côté client)
    - les clefs sont hashée par défaut (sous debian en tout cas) dans le .ssh/known_host, pour éviter de se faire voler la liste des hôtes auquel on se connecte. Pour faire de la completion sur les noms d'hôte (si on n'a pas peur de se faire voler ce fichier), on peut utiliser le format en clair avec "HashKnownHosts no" dans son .ssh/config.
    - pour supprimer un hôte de son known_hosts quand il est hashé, il suffit d'utiliser ssh-keygen -r <hôte>
    - si on utilise un agent (par exemple celui inclus par gnome...), il est préférable de s'assurer que les phrases de passe sont oubliées quand on verrouille la session.

    Si on utilise xscreensaver, on peut faire ça simplement avec un script perl à lancer à l'ouverture de session :


    #!/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;
    }
    }


    Si on utilise gnome, remplacer xscreensaver-command par gnome-screensaver-command.

    Amuse-toi bien :-)