Skip to content

Linux Attitude

Le libre est un état d'esprit

Archive

Tag: Ssh

Niveau :      
Résumé :

Aujourd'hui nous allons mettre en valeur deux articles précédents. J'espère que vous avez déjà mis votre home sous un système de suivi de version pour suivre ses évolutions. J'ai déjà décrit à dans un article précédent. En résumé :

$ cd
$ git init
$ git add .bashrc # et tout ce que vous voulez
$ git commit

Le but étant de propager tout cela automatiquement sur différentes machines. Il est difficile de toujours penser à mettre a jour lorsqu'on fait une modification. C'est pourquoi nous allons mettre à profit l'article précédent et intercepter ssh. Grâce à cela le home de toutes nos machines seront à jour sans qu'on ait à s'en préoccuper.

Mise en place

Cette fois nous allons modifier le script en question pour lancer automatiquement une mise à jour de git de façon furtive à chaque connexion ssh. La méthode run était prévue pour :

# test permettant de savoir qu'on est bien sur le bon dépôt git pour les mises à jour (id du premier commit)
MASTER=11edf02e95ceac1fa58d4444f82f8cd4ae9c1cf5
# command tu run via the ssh socket
run()
{
    # no test if running init
    if [ "$MASTER" != "" ]
    then
        # test if distant has OUR git
        ssh -S "$1" XXX '[ -e /usr/bin/git ] && [ -d .git ] && git rev-list --reverse master 2>/dev/null | head -1' | grep "$MASTER" > /dev/null
    else
        ssh -S "$1" XXX '[ -e /usr/bin/git ]'
    fi
    if [ $? -eq 0 ]
    then
        # if yes push updates
        tmp=$(mktemp ~/.sshgit.XXXXXX)
        echo "#!/bin/sh" > $tmp
        echo "exec ssh -S $1 \"\$@\"" >> $tmp
        chmod +x $tmp
        GIT_SSH=$tmp git push --all ssh://XXX/~ > /dev/null 2> /dev/null
        rm -f $tmp
        ssh -S "$1" XXX 'git checkout -f > /dev/null'
    fi
}

continue reading...

Niveau :      
Résumé :alias ssh='ssh macommande && ssh'

Aujourd'hui interceptons les commandes ssh. Alors ne commencez pas à penser que je suis passé du côté obscur de la force. Il y a des usage bien pratique ce script et je vous en proposerai un dans le prochain article.

Tout d'abord le problème : on veut pouvoir intercepter une commande ssh de façon silencieuse pour pouvoir utiliser la connexion qui va s'établir et lancer les commandes qu'on veut sur la machine distante. Cela implique une acceptation implicite de l'utilisateur puisqu'on va utiliser un simple alias pour "intercepter" la commande. Bien sûr rien ne vous empêche de modifier l'alias d'un ami selon les moyens qui sont à votre disposition ;-)

Principe de fonctionnement

Vous vous dites qu'il suffit de reprendre les paramètres de la commande et de la relancer. Non, habitués que vous êtes à l'agent ssh, vous avez oublié qu'en son absence l'utilisateur devra taper un mot de passe pour que la commande passe.

Pour récupérer la connexion ssh, openssh met à notre disposition tout ce qu'il faut. L'option s'appelle ControlMaster, elle crée une socket sur laquelle ssh peut ensuite se connecter pour ouvrir un nouveau terminal sans repasser toute la chaine de connexion au serveur.

La méthode est donc fait simple :

  • on intercepte la commande ssh (alias)
  • on lance notre script en background ($0 &)
  • on ajoute un option -M et -S si besoin à la commande ssh pour créer la socket
  • on garde les options originales et le processus original (exec ssh -M -S "$@")
  • dans le script en background on peut ensuite utiliser directement la socket en question pour faire ce qu'on veut

continue reading...

Niveau :      
Résumé : SSH et certificats x509

Vous avez une ferme de serveurs ? Vous avez une ferme d'utilisateurs ? Vous avez déjà une infrastructure de gestion de clés pour des certificats x509 (ssl) ?

Si vous répondez oui à deux de ces points alors cet article va vous intéresser.

Sachez qu'il est possible d'utiliser des certificats x509 avec ssh. Quel intérêt ? Tout simplement vous pouvez réutiliser votre PKI si vous en avez déjà une en x509. Ensuite les certificats fonctionnent par un système de signature hiérarchisée, donc il n'est plus nécessaire de mettre en place un système de distribution des clés des utilisateurs sur les machines. Et inversement, les utilisateurs n'auront plus à se reposer sur leur pifomètre pour accepter les clés des serveurs à leur première connexion.

Maintenant qu'on sait qu'on va pouvoir vendre de la sécurité à notre boss tout en évitant de se farcir des systèmes de synchronisation, on va pouvoir se lancer dans les choses sérieuses.

Compilation

Tout d'abord il nous faut une version de ssh qui supporte ce mode de fonctionnement. On la trouvez chez un certain Roumen Petrov. Bon, petite déception, il ne fournit que des patchs. A nous d'en faire un vrai ssh compilé. Pour une fois, ça va être une peu plus difficile pour les debianistes. Pour ceux qui recompilent leur ssh directement :

# à adapter à vos besoins et à votre version
$ wget http://www.roumenpetrov.info/openssh/x509-6.1.1/openssh-5.1p1+x509-6.1.1.diff.gz
$ cd openssh-source
$ zcat ../openssh-5.1p1+x509-6.1.1.diff.gz | patch -p1
$ ./configure
$ make
$ make install

continue reading...

Niveau :      
Résumé : sshd -T ; ssh -l

I'm back ! Ca y est j'ai déménagé. Je peux maintenant reprendre mon activité normale ...

Au cas où vous ne le sauriez pas, la dernière version de openssh vient de sortir, la 5.1. La lecture du changelog est très instructive. On y découvre entre autre deux nouveautés ben sympathiques.

Serveur

Commençons par une nouvelle option de sshd :

$ sshd -T

Cette option permet de tester la configuration du serveur. Ce genre d'option devrait être disponible sur tous les softs, grâce à elle, vous pourrez savoir du premier coup d'oeil si vous avez bien écrit votre configuration et si sshd a bien compris la même chose que ce que vous vouliez lui dire.

Client

Ensuite, une nouvelle option de ssh (qui n'est pas activée par défaut) :

$ ssh -o "VisualHostKey true" mamachine.net

Cette option affiche une interprétation du fingerprint de la machine distante sous forme d'ASCII art. Il est ainsi beaucoup plus facile de comparer 2 clés (il suffit de les regarder).

Cette fonction répond au problème de la confiance au serveur ssh. Lorsque vous vous connectez, ssh vérifie que le serveur distant est connu, si vous vous y êtes déjà connecté et que la clé n'a pas changé, on peut faire confiance en son identité. Mas lorsque c'est la première fois que vous vous connectez, il faut vérifier manuellement que la clé est ben la bonne. Avec cette option la vérification est simplifiée, on espère donc que les gens la feront plus souvent ...

Niveau :      
Résumé : clusterssh, clusterm, konsole, dsh, pssh

Bonjour à tous, très honoré d'être à la tribune de ce blog, mais on m'a forcé la main !

Pour rebondir sur un post récent (tout juste un an !), voici quelques outils pour travailler efficacement sur un groupe de machines.

Konsole et dsh, les ancêtres

Comme Peck l'avait présenté, pour envoyer une même suite de commandes sur un groupe de machines, on peut soit le faire à l'aveugle avec Konsole (si on supporte KDE), soit lancer ses commandes coûte que coûte avec dsh, mais sans contrôle encore une fois sur le déroulement.

Avec Konsole : préparez dans une même fenêtre une machine à contrôler par onglet, puis dans les menus : View > Send Input to All Sessions. Désormais, tout ce que vous tapez est répété dans toutes les fenêtres.

Avec dsh :

 dsh -m machine1 -m machine2 commande

Attention, n'oubliez pas que votre commande est d'abord interprétée par votre shell. Ainsi, comparez :

 dsh -m machine1 -m machine2 -m ... "echo $HOSTNAME"
 dsh -m machine1 -m machine2 -m ... 'echo $HOSTNAME'

Relisez l'article pour apprendre comment créer des groupes de machines avec dsh.

clusterssh et clusterm

Mais si on désire surveiller ce qui se passe sur toutes les machines, et ainsi avoir un contrôle visuel, et au besoin effectuer une correction sur une machine en particulier, alors des outils graphiques rendent bien service, en affichant dans un terminal distinct chacune des machines que l'on contrôle. Par ici pour des captures d'écran, et un petit article de présentation de clusterssh !

Vous pouvez définir vos groupes de machines dans le fichier /etc/clusters :

groupe1 machine1 machine2 machine3 machine4 machine5 machine6 machine7 machine8 machine9
groupe2 machine10 machine11 machine12 machine13 machine14 machine15
all groupe1 groupe2

continue reading...

Niveau :      
Résumé : locale ; export LANG ; AcceptEnv ; SendEnv

Je vais devoir arrêter les voyages, hier, je change de locale, aujourd'hui je me connecte ... rien !

Une locale c'est tout un ensemble de choses qui permettent de faire en sorte que les logiciels s'affichent dans la langue qui vous convient. Pour les développeurs, j'ai un début d'explication sur la technique.

Et ça commence par des variables locales. La première c'est LANG, qui définit la façon par défaut d'afficher les informations. Cette méthode peut ensuite être surchargée finement avec les variables LC_*, par exemple LC_MONETARY permet de changer spécifiquement l'affichage de la monnaie. Et enfin, toutes ces valeurs peuvent encore être surchargées globalement et d'un coup par la variable LC_ALL.

Étant des variables d'environnement, ces infos sont transmises de processus en processus. Donc de shell en commande. Pour connaître la locale en cours, c'est simple :

$ locale

Pour la changer :

# on liste les locales disponibles
$ locale -a
# on en choisit une
$ export LANG=fr_FR

À ajouter dans votre .bashrc pour conserver la chose un peu plus longtemps (attention, gnome et kde et caetera sont à configurer séparément).

Pour changer ceci de façon globale, ben c'est pas gagné, selon les distributions et les softs, tous n'utilisent pas les même fichiers de configuration. Tout d'abord, il y a l'historique /etc/environment, pour les shells on peut aussi chercher dans /etc/profile. Et ensuite, mais c'est spécifique debian, il y a /etc/default/locale.

Pour les systèmes utilisant pam (su, login, kdm, gdm, ...) vous pouvez aller lire les /etc/pam.d/XXX qui peuvent contenir une ligne du type :s

auth    required        pam_env.so readenv=1 envfile=/etc/default/locale

indiquant où chercher vos variables.

Et enfin, parlons ubiquité, je ne sais pas vous, mais moi je suis partout, j'ai un compte sur toutes les machines (si je n'en ai pas chez vous, appelez-moi, j'accepterai volontiers un compte, de préférence root, mais je ne voudrais pas déranger). Je suis tout d'abord chez moi, avec ma locale, et donc mon terminal adapté à cette locale (hé oui, pensez iso vs utf8) et je me connecte en ssh sur un de mes comptes. Je voudrais bien rester moi-même et garder mes locales et non pas prendre celle du système ou devoir configurer chacun des shells de destinations à la main. Heureusement, ssh a aussi prévu ce cas. Il permet la transmission des locales s'il est configuré correctement.

Sur le serveur, dans /etc/ssh/sshd_config :

# on autorise le client a jouer avec les locales à la connexion
AcceptEnv LANG LC_*

Sur le client, de préférence dans /etc/ssh/ssh_config :

Host *
# on envoit nos locales au serveur
    SendEnv LANG LC_*

Et voilà, pour peu que votre /etc/pam.d/ssh ne contienne pas de référence à un fichier qui forcerait les locales, vous êtes chez vous.

Niveau :      
Résumé : ssh -M -S

Si vous faites de nombreuses connexions ssh à une machine, soit pour lancer plusieurs shells, soit pour exécuter des séries de commandes, votre client ssh va initialiser une nouvelle connexion à chaque fois. Ceci peut devenir très lourd pour une machine un peu ancienne. En effet, ceci implique le handshake tcp, la négociation du cryptage, l'échange de clés et donc un certain temps de calcul.

Il est plus judicieux de ne faire qu'une seule connexion ssh et de multiplexer toutes vos commandes par dessus (soit à cause de la faiblesse de la machine, soit parce que vous faites un grand nombre de connexions). Heureusement, ssh a tout prévu :

# première connexion
$ ssh -M -S /tmp/master mamachine.net

# deuxième connexion
$ ssh -S /tmp/master mamachine.net

La deuxième connexion est infiniment plus rapide (ajoutez l'option -v pour en être convaincu). De plus notez que même si vous terminez la commande (ou le shell) de la première connexion, celle-ci ne sera vraiment terminée que lorsque la deuxième commande le sera aussi. Vous pouvez ainsi multiplexer autant de connexions que vous voulez, l'option -M ne sert qu'une fois pour la création du master de connexion.

Remarquez que vous pouvez utiliser n'importe quel nom de machine pour les connexions slave, c'est la syntaxe ssh qui vous force à en utiliser un, mais il n'est pas réellement utilisé, exemple :

$ ssh -M -S /tmp/master mamachine.net
# mamachine.net ou azerty c'est pareil
$ ssh -S /tmp/master azerty