connexion ssh. Connexion X11 rejetée en raison d'une mauvaise authentification
En essayant d'accéder à un cluster dans mon laboratoire par ssh et cela fonctionne. mais je ne peux rien faire:
user@users:~> nautilus
X11 connection rejected because of wrong authentication.
Could not parse arguments: Cannot open display
ou
user@users:~> gedit
X11 connection rejected because of wrong authentication.
(gedit:151222): Gtk-WARNING **: cannot open display: localhost:11.0
Cela a fonctionné jusqu'à aujourd'hui ... et je ne sais pas comment vérifier si quelque chose a changé. Je n'ai pas le mot de passe root pour cette machine, puis-je faire quelque chose?
J'ai lu beaucoup de choses sur cette erreur comme celle-ci mais rien n'a été résolu ...
MODIFIER:
Le système d'exploitation local est Ubuntu 16 et le serveur est OpenSuse. Je me connecte de cette façon:
ssh -XY -p22 [email protected]
MODIFIER 2:
user@users:~> env
MODULE_VERSION_STACK=3.1.6
LESSKEY=/etc/lesskey.bin
NNTPSERVER=news
INFODIR=/usr/local/info:/usr/share/info:/usr/info
MANPATH=/usr/local/man:/usr/share/man
HOSTNAME=users
XKEYSYMDB=/usr/share/X11/XKeysymDB
Host=users
TERM=xterm-256color
Shell=/bin/bash
PROFILEREAD=true
HISTSIZE=1000
SSH_CLIENT=10.44.0.1 49729 22
MORE=-sl
SSH_TTY=/dev/pts/2
JRE_HOME=/usr/lib64/jvm/jre
USER=user
LS_COLORS=no=00:fi=00:di=01;34:ln=00;36:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:or=41;33;01:ex=00;32:*.cmd=00;32:*.exe=01;32:*.com=01;32:*.bat=01;32:*.btm=01;32:*.dll=01;32:*.tar=00;31:*.tbz=00;31:*.tgz=00;31:*.rpm=00;31:*.deb=00;31:*.arj=00;31:*.taz=00;31:*.lzh=00;31:*.lzma=00;31:*.Zip=00;31:*.Zoo=00;31:*.z=00;31:*.Z=00;31:*.gz=00;31:*.bz2=00;31:*.tb2=00;31:*.tz2=00;31:*.tbz2=00;31:*.avi=01;35:*.bmp=01;35:*.fli=01;35:*.gif=01;35:*.jpg=01;35:*.jpeg=01;35:*.mng=01;35:*.mov=01;35:*.mpg=01;35:*.pcx=01;35:*.pbm=01;35:*.pgm=01;35:*.png=01;35:*.ppm=01;35:*.tga=01;35:*.tif=01;35:*.xbm=01;35:*.xpm=01;35:*.dl=01;35:*.gl=01;35:*.wmv=01;35:*.aiff=00;32:*.au=00;32:*.mid=00;32:*.mp3=00;32:*.ogg=00;32:*.voc=00;32:*.wav=00;32:
LD_LIBRARY_PATH=/usr/local/cuda-5.5/lib:/usr/local/cuda-5.5/lib64:
XNLSPATH=/usr/share/X11/nls
ENV=/etc/bash.bashrc
HOSTTYPE=x86_64
FROM_HEADER=
MSM_PRODUCT=MSM
PAGER=less
CSHEDIT=emacs
XDG_CONFIG_DIRS=/etc/xdg
MINICOM=-c on
MODULE_VERSION=3.1.6
MAIL=/var/mail/user
PATH=/usr/local/cuda-5.5/bin:/home/user/bin:/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/X11R6/bin:/usr/games:/usr/lib64/jvm/jre/bin:/usr/lib/mit/bin:/usr/lib/mit/sbin
CPU=x86_64
Java_BINDIR=/usr/lib64/jvm/jre/bin
INPUTRC=/home/user/.inputrc
PWD=/home/user
Java_HOME=/usr/lib64/jvm/jre
LANG=en_US.UTF-8
PYTHONSTARTUP=/etc/pythonstart
MODULEPATH=/usr/share/modules:/usr/share/modules/modulefiles
LOADEDMODULES=
QT_SYSTEM_DIR=/usr/share/desktop-data
SHLVL=1
HOME=/home/user
LESS_ADVANCED_PREPROCESSOR=no
OSTYPE=linux
LS_OPTIONS=-N --color=tty -T 0
XCURSOR_THEME=DMZ
MSM_HOME=/usr/local/MegaRAID Storage Manager
WINDOWMANAGER=/usr/bin/gnome
G_FILENAME_ENCODING=@locale,UTF-8,ISO-8859-15,CP1252
LESS=-M -I
MACHTYPE=x86_64-suse-linux
LOGNAME=user
XDG_DATA_DIRS=/usr/share:/etc/opt/kde3/share:/opt/kde3/share
SSH_CONNECTION=172.17.10.15 22
MODULESHOME=/usr/share/modules
LESSOPEN=lessopen.sh %s
INFOPATH=/usr/local/info:/usr/share/info:/usr/info
DISPLAY=localhost:12.0
XAUTHLOCALHOSTNAME=users
LESSCLOSE=lessclose.sh %s %s
G_BROKEN_FILENAMES=1
Java_ROOT=/usr/lib64/jvm/jre
COLORTERM=1
_=/usr/bin/env
Xauthority Mini Comment
Sur les systèmes GNU/Linux exécutant un serveur d'affichage X11, le fichier ~/.Xauthority stocke les cookies d'authentification ou les clés cryptographiques utilisés pour autoriser la connexion à l'écran. Dans la plupart des cas, le mécanisme d'authentification est un cookie symétrique appelé Magic Cookie. Le même cookie est utilisé par le serveur ainsi que par le client.
Chaque cookie d'authentification X11 est sous le contrôle de l'utilisateur authentifié du système individuel. Étant donné que le cookie d'authentification est stocké en tant que jeton de sécurité en texte brut, les autorisations sur le ~/.Xauthority le fichier doit être rw pour le propriétaire uniquement, 600 au format octal. Cependant, les autorisations sur le fichier d'autorisation ne sont pas appliquées.
Un utilisateur peut répertorier, exporter, créer ou supprimer des cookies d'authentification à l'aide du programme xauth. La commande suivante créera un cookie d'autorisation pour DISPLAY 32.
xauth add localhost:32 - `mcookie`
La création et la manipulation manuelles de cookies ne sont généralement pas nécessaires lors de l'utilisation du transfert X11 avec ssh, car ssh démarre un proxy X11 sur la machine distante et génère automatiquement des cookies d'autorisation sur l'affichage local. Cependant, pour certaines configurations, le cookie d'autorisation peut devoir être créé manuellement et copié sur la machine locale.
Cela peut être fait dans une session ssh puis utilisez scp pour copier le cookie.
ssh dans la machine distante:
ssh -XY user@remote
Vérifiez si un cookie d'autorisation est présent pour l'affichage X11 actuel
echo $DISPLAY
xauth list
S'il n'y a pas de variable d'environnement nommée $DISPLAY alors le proxy X11 n'a pas démarré correctement. Il est important de noter que DISPLAY 0 est généralement connecté localement et ne fonctionne que si un xserver a été démarré localement via xinit. Aucun serveur X11 démarré localement n'est requis pour que le transfert X11 fonctionne via ssh.
S'il y a un $DISPLAY ensemble de variables d'environnement mais pas de cookie d'autorisation correspondant pour ce numéro d'affichage, vous pouvez en créer un:
xauth add $DISPLAY - `mcookie`
Et vérifiez qu'il y a maintenant un cookie:
xauth list
Vous pouvez copier ce cookie et le fusionner dans la machine locale:
user@remote> xauth nextract ~/xcookie $DISPLAY
user@remote> exit
user@local> scp user@remote:~/xcookie ~/xcookie
user@local> xauth nmerge ~/xcookie
Et puis vérifiez que le cookie a été installé:
user@local> xauth list
Essayez votre connexion ssh de transfert X11.
Notes sur ~/.Xauthority
~/.Xauthority est un fichier binaire qui contient toutes les informations d'autorisation pour chaque affichage auquel l'utilisateur peut accéder. Chaque enregistrement est délimité par les deux octets 0x0100. Chaque champ est précédé d'un décompte hexidémique du nombre d'octets du champ. Tout le texte est codé en ASCII hexidécimal. Le tableau suivant est la structure de base de la configuration la plus courante d'une autorisation MIT MAGIC COOKIE:
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
0100 0004 61616161 0002 3435 0012 4d49542d4d414749432d434f4f4b49452d31 0010 c0bdd1c539be89a2090f1bbb6b414c2c
----------------- ----------- ------------------ ------------ ---------------------- ------------- -------------------------------------- ------------ ---------------------------------------
start-of-record 0xNumBytes 0xASCII Hostname 0xNumBytes 0xASCII Display Num 0xNumBytes 0xASCII Auth Type 0xNumBytes 0xkey
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
La ligne supérieure est récupérable à partir du ~/.Xauthority fichier via le xauth nlist commande. Bien sûr, votre fichier d'autorisation contiendra des informations différentes de mon exemple.
Si les extensions de sécurité sont utilisées avec le serveur X11, il existe plusieurs options de configuration pour chaque ligne d'autorisation, y compris l'autorisation limitée dans le temps par cookie.