私の研究室のクラスターに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
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ごとの時間制限のある承認を含む、各承認ラインにいくつかの構成オプションがあります。