Getting X11 forwarding through ssh working after running su

Le problème est le suivant:
We want to export a display from a remote unix box, but from another user than the one we connect with.
Example:
i connect on a remote host with the user root, or the user user1.
but i want to export the display of a program started with the user oracle.
if i just do:
ssh user1@remotehost
su - oracle
xlogo
i receive an error, display broken.
Lets see the tip:
TIP:
X authentication is based on cookies -- secret little pieces of random data that only you and the X server know...
So, you need to let the other user in on what your cookie is. One way to do this is as follows:
Before you issue the su or sudo (but after having ssh'ed into the remote system), request the cookie for the current DISPLAY that's connecting to your X server:
Remote Host:
I assume we connected with ssh and X11 forwarding, and mmsdyy00 is my host with a screen/display:
$ xauth list
mmsdyy00/unix:13  MIT-MAGIC-COOKIE-1  c1825a6cb90d3c4f23368c6764c18989
mmsdyy00/unix:14  MIT-MAGIC-COOKIE-1  5f79f56e5fb5b801572fe0c07598a72b
mmsdyy00/unix:10  MIT-MAGIC-COOKIE-1  5a0510f245c81f1bb2741c6af0a13c8c
mmsdyy00/unix:11  MIT-MAGIC-COOKIE-1  146e0c800789cc7f0aceb75a5d6d9857
mmsdyy00/unix:12  MIT-MAGIC-COOKIE-1  59b4090b6ded3a79ad59523238925873

$ echo $DISPLAY # quel est notre display ?
localhost:12.0


$ su - oracle

$ export DISPLAY=localhost:12.0 #==> positionnement de la variable

$ xlogo # ==> erreur
X connection to localhost:12.0 broken (explicit kill or server shutdown).

$ xauth add mmsdyy00/unix:12  MIT-MAGIC-COOKIE-1  59b4090b6ded3a79ad59523238925873

$ xlogo # ==> OK
Remarque: j'ai pris dans la liste le dpyname qui contient un 12 :
    ( DISPLAY=localhost:12.0 )
    (dpyname=mmsdyy00/unix:12)

SSH: Authentication with PublicKeys

Ce document explique les différentes étapes pour mettre en place l'authentification par clef
publiques.

Les avantages tirés sont pluriel:

• Evite la propagation des mots de passe ( celui de root en particulier ),
• Evite l'utilisation d'un mot de passe trop simple, souvent utilisé pour ne pas l'oublier, et car les connexions sont nombreuses dans une journée,
• Ajoute une granularité dans la mise en place de la sécurité,
• Facilite le travail quotidien, par des connexions plus rapides.

Coté client
Création des paires de clef privée/publiques cliente.

Les clef sont crée avec la commande `ssh-keygen', il vous sera demander un nom
de fichier, acceptez celui par défaut, puis une pass-phrase (Le mot de passe),
veillez à en choisir un assé long, une phrase serait l'idéal.

$ ssh-keygen -t rsa1 # SSH1
$ ssh-keygen -t rsa # SSH2
$ ssh-keygen -t dsa # SSH2

L'agent ssh

Maintenant pour éviter d'avoir à taper notre passphrase à chaque connexion,
nous allons utiliser la commande `ssh-agent'. Grâce à lui, nous n'aurons qu'à
taper notre passphrase qu'une fois au début de la journée:

$ eval $(ssh-agent)
Agent pid 2592

puis il nous faut ajouter nos clef.
Rem: si vous avez choisi la même passphrase pour toutes les trois clef, elle
ne vous sera demandée qu'une seulle fois:

$ ssh-add
Enter passphrase for ~/.ssh/id_rsa:
Identity added: ~/.ssh/id_rsa (~/.ssh/id_rsa)
Identity added: ~/.ssh/id_dsa (~/.ssh/id_dsa)
Identity added: ~/.ssh/identity (Philippe@MyHost)


On peut verifier qu'elles ont bien été prises en compte:

$ ssh-add -l
2048 9a:08:b9:b8:e6:25:bd:6c:4e:8c:25:13:2e:36:62:97 Philippe@MyHost (RSA1)
2048 5b:7f:cd:96:2c:f4:41:66:1a:83:4b:ff:ad:89:85:42 ~/.ssh/id_rsa (RSA)
2048 9a:e0:e3:af:b8:65:a1:c6:06:2c:80:8e:8a:1a:c9:30 ~/.ssh/id_dsa (DSA)

Coté client c'est Fait.

Coté serveur

passons sur l'installation du serveur ssh, et concentrons nous sur le
spécifique pour accepter l'Authentification par Clef publiques.


La configuration du serveur:

Les options suivante doivent être présentes dans le fichier de conf :

/opt/ssh/etc/sshd_config:

RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys

StrictModes no # Si les droits sur le $HOME ne sont pas 0700


puis pour recharger la config :

$ kill -1 $(cat /var/run/sshd.pid)

Ajout des clef.

Pour que la connexion soit possible, il nous faut rajouter la(les) clef
publique dans le fichier d'authorization:

Après avoir copié sur le serveur la clef publique (DSA):

$ cat id_dsa.pub >>$HOME/.ssh/authorized_keys

Test de connexion

$ ssh unix@support
MyHost [HP Release B.11.00]
Last successful login for unix: Tue Sep 20 15:12:54 MET-1METDST 2005 on pts/43
Last unsuccessful login for unix: Tue Sep 20 09:58:07 MET-1METDST 2005 on pts/tp
Last login: Mon Aug 29 20:19:36 2005 from otherhost
You have mail.

Dans les logs:

Sep 20 15:17:32 myhost sshd[24103]: Accepted publickey for unix from 192.168.1.2 port 3546 ssh2