web-dev-qa-db-ja.com

ssh接続。認証が間違っているためX11接続が拒否されました

私の研究室のクラスターにsshでアクセスしようとすると、うまくいきます。しかし、私は何もすることができません:

user@users:~> nautilus
X11 connection rejected because of wrong authentication.
Could not parse arguments: Cannot open display

または

user@users:~> gedit
X11 connection rejected because of wrong authentication.

(gedit:151222): Gtk-WARNING **: cannot open display: localhost:11.0

それは今日まで機能しました...そして、何かが変更されたかどうかを確認する方法がわかりません。このマシンのrootパスワードがないのですが、何かできることはありますか?

私はこのようなこのエラーについて多くのものを読みましたが、何も解決されていません...

編集:

ローカルOSはUbuntu 16で、サーバーはOpenSuseです。私はこのように接続しています:

ssh -XY -p22 [email protected]

編集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
6
Dadep

Xauthority Miniハウツー

X11ディスプレイサーバーを実行するGNU/Linuxシステムでは、ファイル~/.Xauthorityには、ディスプレイへの接続を承認するために使用される認証Cookieまたは暗号化キーが格納されます。ほとんどの場合、認証メカニズムはMagic Cookieと呼ばれる対称cookieです。サーバーとクライアントは同じCookieを使用します。

各X11認証Cookieは、個々のシステム認証ユーザーの制御下にあります。認証Cookieはプレーンテキストのセキュリティトークンとして保存されるため、~/.Xauthorityファイルのアクセス許可は、所有者のみrw、8進形式の600にする必要があります。ただし、認証ファイルの権限は適用されません。

ユーザーは、xauthプログラムを使用して、認証Cookieをリスト、エクスポート、作成、または削除できます。次のコマンドは、DISPLAY 32の認証Cookieを作成します。

xauth add localhost:32 - `mcookie`

sshがリモートマシン上でX11プロキシを起動し、ローカルディスプレイ上に認証Cookieを自動的に生成するため、sshでX11転送を使用する場合、Cookieの手動作成および操作は通常必要ありません。ただし、特定の構成では、認証Cookieを手動で作成してローカルマシンにコピーする必要がある場合があります。

これはsshセッションで行うことができ、次にscpを使用してCookieをコピーします。

sshをリ​​モートマシンに:

ssh -XY user@remote

現在のX11ディスプレイに認証Cookieが存在するかどうかを確認します

echo $DISPLAY
xauth list

$DISPLAYという名前の環境変数がない場合、X11プロキシは正しく起動していません。 DISPLAY 0は通常ローカルでログインしているユーザーであり、xinitを介してxserverがローカルで起動されている場合にのみ実行されることに注意してください。 X11転送がsshを介して機能するために、ローカルで起動されたX11サーバーは必要ありません。

$DISPLAY環境変数が設定されているが、そのディスプレイ番号に対応する認証Cookieがない場合は、作成できます。

xauth add $DISPLAY - `mcookie`

そして今クッキーがあることを確認してください:

xauth list

そのCookieをコピーして、ローカルマシンにマージできます。

user@remote> xauth nextract ~/xcookie $DISPLAY
user@remote> exit
user@local> scp user@remote:~/xcookie ~/xcookie
user@local> xauth nmerge ~/xcookie

次に、Cookieがインストールされていることを確認します。

user@local> xauth list

X11転送ssh接続を試してください。

~/.Xauthorityに関する注意

~/.Xauthorityは、ユーザーがアクセスできる各ディスプレイのすべての認証情報を含むバイナリファイルです。各レコードは2バイト0x0100で区切られます。各フィールドの前には、フィールドのバイト数が16進数でカウントされます。すべてのテキストは16進数のASCIIでエンコードされます。次の表は、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
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

先頭行は、~/.Xauthorityコマンドを使用してxauth nlistファイルから取得できます。もちろん、認証ファイルには私の例とは異なる情報が含まれます。

Security ExtensionsがX11サーバーで使用されている場合、Cookieごとの時間制限のある承認を含む、各承認ラインにいくつかの構成オプションがあります。

18
RubberStamp