我有一台运行Ubuntu的计算机,该计算机从Fedora 14计算机上通过SSH SSH到。我想将X从Ubuntu计算机转发回Fedora,以便可以远程运行图形程序。两台机器都在局域网上。
我知道该-X
选项启用了SSH中的X11转发,但是我感觉缺少一些步骤。
通过SSH将X从Ubuntu计算机转发到Fedora的必要步骤是什么?
我有一台运行Ubuntu的计算机,该计算机从Fedora 14计算机上通过SSH SSH到。我想将X从Ubuntu计算机转发回Fedora,以便可以远程运行图形程序。两台机器都在局域网上。
我知道该-X
选项启用了SSH中的X11转发,但是我感觉缺少一些步骤。
通过SSH将X从Ubuntu计算机转发到Fedora的必要步骤是什么?
Answers:
需要在客户端和服务器端都启用X11转发。
在客户端,使用-X
(大写X)选项ssh
启用X11转发,您可以使用ForwardX11 yes
in 将其设置为默认值(对于所有连接或特定连接)~/.ssh/config
。
在服务器端,X11Forwarding yes
必须在中指定/etc/ssh/sshd_config
。请注意,默认设置为不转发(某些发行版在其默认设置下将其打开/etc/ssh/sshd_config
),并且用户无法覆盖此设置。
该xauth
程序必须安装在服务器端。如果那里有X11程序,那么很有可能xauth
在那里。在不太可能的情况下xauth
,将其安装在非标准位置的情况下,可以通过~/.ssh/rc
(在服务器上!)调用它。
请注意,您不需要在服务器上设置任何环境变量。DISPLAY
并且XAUTHORITY
将被自动设置到正确的值。如果运行ssh DISPLAY
且未设置ssh,则表示ssh没有转发X11连接。
为了确认SSH是转发X11,检查用于容纳线Requesting X11 forwarding
的ssh -v -X
输出。请注意,服务器不会以任何一种方式进行答复,这是一种安全措施,可防止向潜在攻击者隐藏详细信息。
xhost +
。xhost
是从一个平和的时代开始的,当时有一台机器连接到网络意味着您值得信赖。xhost +
意味着任何可以欺骗您IP的人都可以控制您的X服务器会话。ssh -X
将设置所有必需的授权。如果在服务器配置中禁用了X11转发,请与管理员联系。如果不起作用,请参阅服务器配置不允许的通过SSH转发X11。
~/.ssh/config
和/etc/ssh/sshd_config
在同一位置。我不知道它们是否是不同的文件,还是只是命名上的变化。
.Xauthority
文件的权限。如果将Red Hat或其他系统与SELinux一起使用,请检查SELinux上下文,请参见unix.stackexchange.com/questions/36540/…–
ssh -X
运行xterm &
得到一个图形终端作为最终测试,看看它的工作。
要使X11转发通过ssh工作,您需要准备三件事。
如果同时拥有#1和#2但缺少#3,那么最终将得到一个空的DISPLAY环境变量。
汤圆螺母,这是使X11转发工作的方法。
在服务器上,确保/ etc / ssh / sshd_config包含:
X11Forwarding yes
X11DisplayOffset 10
您可能需要SIGHUP sshd,以便它接受这些更改。
cat /var/run/sshd.pid | xargs kill -1
在服务器上,确保已安装xauth。
belden@skretting:~$ which xauth
/usr/bin/xauth
如果您没有安装xauth,则会遇到“空DISPLAY环境变量”问题。
在客户端上,连接到服务器。一定要告诉ssh允许X11转发。我更喜欢
belden@skretting:~$ ssh -X blyman@the-server
但是你可能会喜欢
belden@skretting:~$ ssh -o ForwardX11=yes blyman@the-server
或者您可以在〜/ .ssh / config中进行设置。
今天早些时候,当我进入一个我不管理的新服务器时,我遇到了这个空的DISPLAY环境变量。跟踪缺少的xauth部分很有意思。这就是我所做的,您也可以做。
在我是管理员的本地工作站上,我验证了/ etc / ssh / sshd_config已设置为转发X11。当我将ssh -X返回到本地主机时,我的显示设置正确。
强迫DISPLAY取消设置并不难。我只需要查看sshd和ssh在做什么才能正确设置它。这是我在此过程中所做的所有工作的全部输出。
blyman@skretting:~$ mkdir ~/dummy-sshd
blyman@skretting:~$ cp -r /etc/ssh/* ~/dummy-sshd/
cp: cannot open `/etc/ssh/ssh_host_dsa_key' for reading: Permission denied
cp: cannot open `/etc/ssh/ssh_host_rsa_key' for reading: Permission denied
我没有使用sudo强制将ssh_host_ {dsa,rsa} _key文件复制到位,而是使用ssh-keygen为自己创建了虚拟文件。
blyman@skretting:~$ ssh-keygen -t rsa -f ~/dummy-sshd/ssh_host_rsa_key
Generating public/private rsa key pair.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/blyman/dummy-sshd/ssh_host_rsa_key.
Your public key has been saved in /home/blyman/dummy-sshd/ssh_host_rsa_key.pub.
用-t dsa反复冲洗:
blyman@skretting:~$ ssh-keygen -t dsa -f ~/dummy-sshd/ssh_host_dsa_key
# I bet you can visually copy-paste the above output down here
编辑〜/ dummy-sshd / sshd_config指向正确的新ssh_host密钥文件。
# before
blyman@skretting:~$ grep ssh_host /home/blyman/dummy-sshd/sshd_config
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
# after
blyman@skretting:~$ grep ssh_host /home/blyman/dummy-sshd/sshd_config
HostKey /home/blyman/dummy-sshd/ssh_host_rsa_key
HostKey /home/blyman/dummy-sshd/ssh_host_dsa_key
以非分离模式在新端口上启动sshd:
blyman@skretting:~$ sshd -p 50505 -f ~/dummy-sshd/sshd_config -d
sshd re-exec requires execution with an absolute path
糟糕,请更正该路径:
blyman@skretting:~$ /usr/sbin/sshd -p 50505 -f ~/dummy-sshd/sshd_config -d
debug1: sshd version OpenSSH_5.5p1 Debian-4ubuntu6
debug1: read PEM private key done: type RSA
debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048
debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048
debug1: private host key: #0 type 1 RSA
debug1: read PEM private key done: type DSA
debug1: Checking blacklist file /usr/share/ssh/blacklist.DSA-1024
debug1: Checking blacklist file /etc/ssh/blacklist.DSA-1024
debug1: private host key: #1 type 2 DSA
debug1: setgroups() failed: Operation not permitted
debug1: rexec_argv[0]='/usr/sbin/sshd'
debug1: rexec_argv[1]='-p'
debug1: rexec_argv[2]='50505'
debug1: rexec_argv[3]='-f'
debug1: rexec_argv[4]='/home/blyman/dummy-sshd/sshd_config'
debug1: rexec_argv[5]='-d'
Set /proc/self/oom_adj from 0 to -17
debug1: Bind to port 50505 on 0.0.0.0.
Server listening on 0.0.0.0 port 50505.
debug1: Bind to port 50505 on ::.
Server listening on :: port 50505.
弹出一个新终端,并通过端口50505 SSH到localhost:
blyman@skretting:~$ ssh -p 50505 localhost
The authenticity of host '[localhost]:50505 ([::1]:50505)' can't be established.
RSA key fingerprint is 81:36:a5:ff:a3:5a:45:a6:90:d3:cc:54:6b:52:d0:61.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '[localhost]:50505' (RSA) to the list of known hosts.
Linux skretting 2.6.35-32-generic #67-Ubuntu SMP Mon Mar 5 19:39:49 UTC 2012 x86_64 GNU/Linux
Ubuntu 10.10
Welcome to Ubuntu!
* Documentation: https://help.ubuntu.com/
1 package can be updated.
0 updates are security updates.
Last login: Thu Aug 16 15:41:58 2012 from 10.0.65.153
Environment:
LANG=en_US.UTF-8
USER=blyman
LOGNAME=blyman
HOME=/home/blyman
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
MAIL=/var/mail/blyman
SHELL=/bin/bash
SSH_CLIENT=::1 43599 50505
SSH_CONNECTION=::1 43599 ::1 50505
SSH_TTY=/dev/pts/16
TERM=xterm
DISPLAY=localhost:10.0
Running /usr/bin/xauth remove unix:10.0
/usr/bin/xauth add unix:10.0 MIT-MAGIC-COOKIE-1 79aa9275ced418dd445d9798b115d393
看那里的最后三行。我很幸运地设置了DISPLAY,并从/ usr / bin / xauth获得了这两行漂亮的代码。
从那里开始,把我的/ usr / bin / xauth移到/usr/bin/xauth.old,断开与ssh的连接并停止sshd,然后启动sshd并将ssh返回本地主机,这是小孩子的戏。
/ usr / bin / xauth消失后,我的环境没有看到DISPLAY。
这里没有任何精彩的事情。通常,我很幸运地选择了一种理智的方法来尝试在本地计算机上重现此方法。
export DISPLAY=:10
。我从没猜过这么多显示器。
确保:
xauth
安装在服务器上(请参阅:xauth info
/ xauth list
)。在服务器上,/etc/ssh/sshd_config
文件有以下几行:
X11Forwarding yes
X11DisplayOffset 10
X11UseLocalhost no
在客户端,您的~/.ssh/config
文件包含以下几行:
Host *
ForwardAgent yes
ForwardX11 yes
在客户端,您已经安装了X服务器(例如macOS:XQuartz; Windows:Xming)。
然后,要使用SSH执行X11转发,您需要添加-X
到ssh
命令中,例如
ssh -v -X user@host
然后确认你DISPLAY
是不是由空:
echo $DISPLAY
如果是,则为ssh(-v
)提供详细参数,请检查是否有任何警告,例如
debug1: No xauth program.
Warning: untrusted X11 forwarding setup failed: xauth key data not generated
如果您遇到了如上所述的不受信任的X11,请尝试改用-Y
标志(如果您信任主机):
ssh -v -Y user@host
请参阅:用-X SSH时,“警告:不可信的X11转发设置失败:未生成xauth密钥数据”是什么意思?
如果您警告:没有xauth数据,则可以尝试生成一个新.Xauthority
文件,例如
xauth generate :0 . trusted
xauth list
如果您收到的警告与以上所述不同,请遵循其他提示。
ssh -X
以在远程服务器上获取GUI环境安装以下所有内容。在Window上,安装Xming
。在Ubuntu bash上,使用sudo apt install
install ssh xauth xorg
。
sudo apt install ssh xauth xorg
转到包含ssh_config
文件的文件夹,我的是/etc/ssh
。
ssh_config
以管理员身份编辑(USE sudo
)。里面ssh_config
,删除哈希#
中的台词ForwardAgent
,ForwardX11
,ForwardX11Trusted
,并设置相应的参数yes
。
# /etc/ssh/ssh_config
Host *
ForwardAgent yes
ForwardX11 yes
ForwardX11Trusted yes
在ssh_config
文件中,删除和#
之前的前哈希,Port 22
并在文件Protocol 2
末尾添加新行以声明xauth文件的位置XauthLocaion /usr/bin/xauth
,请记住编写您自己的xauth文件路径。
# /etc/ssh/ssh_config
# IdentifyFile ...
Port 22
Protocol 2
# Cipher 3des
# ...
# ...
...
...
GSSAPIDelegateCredentials no
XauthLocaion /usr/bin/xauth
现在,由于我们已经完成了ssh_config
文件编辑,因此在离开编辑器时将其保存。现在去到文件夹~
或者$HOME
,添加export DISPLAY=localhost:0
到您的.bashrc
文件并保存它。
# ~/.bashrc
...
...
export DISPLAY=localhost:0
我们快完成了。重新启动bash shell,打开Xming
程序并使用ssh -X yourusername@yourhost
。然后享受GUI环境。
ssh -X yourusername@yourhost
问题也出现在Windows的Ubuntu子系统中,并且链接位于
https://gist.github.com/DestinyOne/f236f71b9cdecd349507dfe90ebae776
对我来说,问题出在/ tmp文件系统的nodev挂载选项中。X11需要在其中创建一个特殊文件。
因此,如果您使用一个单独的分区或磁盘,请检查/ tmp文件系统的安装选项是什么。
X11Forwarding
必须在SSH服务器(在您的情况下为Ubuntu框中)的SSH服务器上进行设置sshd_config
,并且必须通过传递-X
选项或编辑ssh_config
文件以添加ForwardX11
默认值来允许将X11转发给SSH客户端(您的Fedora框)。
xauth
安装在远程计算机上,否则x Authority权限将无法正常工作。
DISPLAY
呢?
$DISPLAY
如果X11Forwarding
已启用)并且xauth
存在于客户端系统上。
export DISPLAY=:10.0
但在其他情况下则无效。否则,它抱怨找不到:0
。也许这需要其他一些东西才能自动发生?