AIX: debug de session OpenSSH

J'ai rencontré récemment un problème qui concernait le déport d'affichage X11 sous Openssh 4.3 sur AIX. J'en profite donc pour écrire un billet décrivant ma méthode pour investiguer ce genre de problème.

Il existe un projet openssh on AIX hébergé sur sourceforge qui propose des packages de OpenSSH relativement récents et bien intégrés dans AIX.
La dernière version disponible est la 4.3.

En général, pour obtenir le déport d'affichage, il suffit de positionner la variable X11Forwarding à Yes dans le fichier /etc/ssh/sshd_config et de relancer le service
stopsrc -s sshd
startsrc -s sshd

Une petite remarque qui peut sembler évidente, les sessions ssh déjà actives ne sont pas affectés par un redémarrage du service ssh. C'est toujours sympa de savoir que l'on ne perdra pas sa connection en cas de mauvaise configuration.

J'ai lancé ma commande ssh à partir de mon linux avec l'option -X pour le X11 forwarding :

ssh -X adejoux@srv1

La vérification la plus simple pour savoir si le X11 forwarding fonctionne est de voir si la variable DISPLAY est positionné sur le serveur :

echo $DISPLAY

La sortie devrait être du type localhost:10.0, si la variable est vide, le X11 forwarding ne fonctionne pas. Ce fut mon cas avec la version 4.3p2 de SSH

debug à partir du client ssh

J'ai commencé par relancer la commande ssh en mode verbeux. Il s'agit de l'option -v. On peut augmenter le niveau de verbosité de la commande en augmentant le nombre de v jusqu'à un maximum de 3(soit -v, -vv, -vvv). Il vaut mieux commencer par le premier niveau de debug et l'augmenter au fur et à mesure si besoin.

On relance la commande en mode verbeux :

ssh -v -X adejoux@srv1

Voici l'extrait de la sortie de la commande intéressant :

debug1: Authentication succeeded (password).
debug1: channel 0: new [client-session]
debug1: Entering interactive session.
debug1: Requesting X11 forwarding with authentication spoofing.
debug1: Sending environment.
debug1: Sending env LANG = en_US.UTF-8
debug1: Remote: No xauth program; cannot forward with spoofing.

On voit que le client réclame bien le X11 forwarding au serveur :

debug1: Requesting X11 forwarding with authentication spoofing.

Et qu'il obtient une réponse distante lui indiquant que le binaire xauth n'existe pas sur le serveur :

debug1: Remote: No xauth program; cannot forward with spoofing.

Sur le serveur, on vérifie que le fichier xauth existe :

# which xauth
/usr/bin/X11/xauth

Le problème semble donc situer du coté du serveur ssh


Debug à partir du serveur ssh

Le mieux est de lancer le serveur ssh en mode debug sur un port non utilisé du serveur. Cela permet d'éviter de toucher au service ssh existant et d'effectuer ses tests sans géner personne.
Les options utilisées sont :

  • -d :mode debug

  • -p : spécifie sur quel port écoute le serveur
Après avoir vérifier que le port est libre ( en utilisant netstat -an ), on lance le serveur avec les paramètres suivants :
 /usr/sbin/sshd -p 4444 -d
A noter qu'il est nécessaire de spécifier le chemin absolu du binaire sshd. Le serveur ssh lancé en debug ne se détache pas du terminal et accepte une seule session avant de se terminer.
Voici sa sortie de démarrage:
debug1: sshd version OpenSSH_4.3p2
debug1: read PEM private key done: type RSA
debug1: private host key: #0 type 1 RSA
debug1: read PEM private key done: type DSA
debug1: private host key: #1 type 2 DSA
debug1: rexec_argv[0]='/usr/sbin/sshd'
debug1: rexec_argv[1]='-p'
debug1: rexec_argv[2]='4444'
debug1: rexec_argv[3]='-d'
debug1: Bind to port 4444 on 0.0.0.0.
Server listening on 0.0.0.0 port 4444.

La sortie permet de vérifier les paramètres pris en compte par le serveur et si l'ouverture de socket TCP se passe correctement.
Maintenant voici un extrait de la sortie commençant après que l'utilisateur est entré son mot de passe :

Accepted password for miis4n from 172.31.233.198 port 33827 ssh2
debug1: Entering interactive session for SSH2.
debug1: server_init_dispatch_20
debug1: server_input_channel_open: ctype session rchan 0 win 65536 max 16384
debug1: input_session_request
debug1: channel 0: new [server-session]
debug1: session_new: init
debug1: session_new: session 0
debug1: session_open: channel 0
debug1: session_open: session 0: link with channel 0
debug1: server_input_channel_open: confirm session
debug1: server_input_channel_req: channel 0 request x11-req reply 0
debug1: session_by_channel: session 0 channel 0
debug1: session_input_channel_req: session 0 req x11-req
debug1: server_input_channel_req: channel 0 request pty-req reply 0
debug1: session_by_channel: session 0 channel 0
debug1: session_input_channel_req: session 0 req pty-req
debug1: Allocating pty.
debug1: session_pty_req: session 0 alloc /dev/pts/11
debug1: Ignoring unsupported tty mode opcode 13 (0xd)
debug1: Ignoring unsupported tty mode opcode 18 (0x12)
debug1: server_input_channel_req: channel 0 request env reply 0
debug1: session_by_channel: session 0 channel 0
debug1: session_input_channel_req: session 0 req env
debug1: server_input_channel_req: channel 0 request shell reply 0
debug1: session_by_channel: session 0 channel 0
debug1: session_input_channel_req: session 0 req shell
setsid: Operation not permitted.
Et enfin ! Grâce à ce fabuleux mode debug, on voit ... rien. Aucune trace du problème. Et oui, les seules entrées concernant le X11 forwarding coté serveur sont celles-ci:
debug1: server_input_channel_req: channel 0 request x11-req reply 0
debug1: session_by_channel: session 0 channel 0
debug1: session_input_channel_req: session 0 req x11-req
Et elles sont loin d'indiquer une erreur. j'ai justement pris comme exemple ce problème car c'est la première fois que je n'arrivais pas à trouver la cause d'un problème ssh avec les debug au niveau client et serveur. Ca me permet d'introduire le troisième niveau de debug de openssh possible.

Debug avec truss

Et oui, la seule manière que j'ai trouvé pour identifier ce problème est de tracer les appels systèmes avec la commande truss. Voici la ligne de commande :
truss -f -t !close -o /tmp/truss.out /usr/sbin/sshd -p 4444 -d Voici une description des options de truss utilisées :

  • -t !close : je précise que je veux récupérer tout les appels systèmes sauf close pour éviter de polluer mon fichier log.

  • -f : cette option indique à truss de tracer les appels systèmes des processus fils aussi.
  • -o /tmp/truss.out :indique le fichier où stocker la sortie de la commande truss.

Concernant l'option -f, on peut se poser la question du pourquoi l'utiliser alors que le processus sshd accepte une unique session. Et bien, c'est due à la séparation des privilèges qui crée un nouveau processus avec un utilisateur différent de root. On peut aussi passer en paramètre à sshd l'option -o UsePrivilegeSeparation=no pour désactiver ça. L'option -f de truss n'est plus nécessaire dans ce cas.

Et maintenant on regarde ce que l'on trouve dans le fichier de sortie de truss concernant xauth :
#grep xauth /tmp/truss.out
statx("/usr/contrib/bin/xauth", 0x2FF216C0, 128, 010) Err#2 ENOENT
Il n'y a qu'une seule entrée pour xauth et elle indique que sshd vérifie la présence de xauth dans le mauvais répertoire. Et voilà le problème est clairement identifié.

Correction

Après une petite recherche dans le man de sshd, on trouve l'option XAuthLocation qui permet de spécifier l'endroit où se trouve xauth.
Il suffit donc de rajouter dans le fichier de configuration, l'entrée XAuthLocation /usr/bin/X11/xauth

Une bonne pratique lorsque l'on modifie la configuration du serveur ssh de manière importante et de faire une copie du fichier de configuration originelle, appliquer les modifications dessus et lancer un nouveau service ssh qui se base sur ce fichier avec l'option -f de sshd.

Ce qui peut donner une ligne de commande de ce type :

truss  -t !close -o truss.out /usr/sbin/sshd -p 4444 -o UsePrivilegeSeparation=no -f /etc/ssh/test_sshd_config -d

Dans le fichier de sortie de truss, on voit que maintenant xauth est bien trouvé :

statx("/usr/bin/X11/xauth", 0x2FF216C0, 128, 010) = 0

Et si on utilise le client ssh en mode verbeux on obtient en plus les lignes suivantes à la fin de la connexion :

Running /usr/bin/X11/xauth remove unix:11.0
/usr/bin/X11/xauth add unix:11.0 MIT-MAGIC-COOKIE-1 b0a2a12ddd31aabaf98acf3613010267
Et voilà, j'ai trouvé ce problème très intéressant car il est vraiment très rare qu'un problème de configuration ne soit pas détecté lorsqu'on passe en mode debug le serveur et le client en mode verbeux. En plus, ce problème semble spécifique à cette version sur AIX car je n'ai vraiment rien trouvé sur le web à ce sujet.

Commentaires

1. Le mardi, mai 27 2008, 17:36 par nyme

Merci

cela faisait un moment que j'avais ce problème ....

Merci 1000 fois