Problem
Ich kann die X11-Weiterleitung über SSH als normaler Benutzer nicht mehr zum Laufen bringen. Vor ein paar Monaten hat es noch funktioniert, also wurde versehentlich etwas geändert.
Was ich versucht habe
Funktioniert mit sudo:
Soweit ich das beurteilen kann, sind meine SSH- und SSHD-Konfigurationen korrekt. Tatsächlich wird X11 korrekt weitergeleitet, wenn ich als Root mit sudo laufe:
$ ssh -X lm@<ip> -i <key>
lm@localhost:~$ xeyes
Error: Can't open display: localhost:10.0
lm@localhost:~$ sudo xeyes
lm@localhost:~$
X erfolgreich weitergeleitetmitsudo scheint ein häufiges Problem zu sein, aber dies ist das gegenteilige Problem. Ich verstehe die Informationen, die ich über die X-Weiterleitung als Root oder ein anderer Benutzer gesehen habe, nicht wirklich, und ich muss sowieso nicht als Root oder ein anderer Benutzer weiterleiten. Also,wie kann ich das wieder auf den Normalzustand zurücksetzen?
xauth
Für mich würde es Sinn ergeben, dass es sich hier um ein Authentifizierungsproblem handelt. Ich bin mir jedoch nicht sicher, wie ich feststellen kann, ob es richtig ist oder nicht.
Es gibt zwei Einträge in der .Xauthority des Benutzers
lm@localhost:~$ xauth info
Authority file: /home/lm/.Xauthority
File new: no
File locked: no
Number of entries: 2
Changes honored: yes
Changes made: no
Current input: (argv):1
lm@localhost:~$ xauth list
edare-fmt17138762/unix:10 MIT-MAGIC-COOKIE-1 48081e511d8ba861ccaf146b73a01617
localhost/unix:10 MIT-MAGIC-COOKIE-1 ce23a352c8f10814e103474aa620fc31
Ich habe versucht, .Xauthority zu entfernen, aber das hat das Problem nicht gelöst.
Möglicherweise damit verbundene Hostnamenprobleme
Der Hostnamesollenbe edare-fmt17138762, aber das wird bei jedem Neustart zurückgesetzt. Ich habe versucht, den Hostnamen erneut festzulegen und ihn auch vollständig auf localhost zurückzusetzen, aber keines davon hatte Auswirkungen auf die Weiterleitung von X, also scheint es nicht so, als ob der Hostname speziell das Problem ist.
sshd_config-Änderungen
X11UseLocalhost yesIch habe es ohne Wirkung versucht .
Ich habe auch versucht X11UseLocalhost no, was zusätzliche und leicht andere Fehler erzeugt:
$ ssh -Y [email protected] -i <key>
Welcome to Ubuntu 16.04.3 LTS (GNU/Linux 4.4.0-93-generic x86_64)
* Documentation: https://help.ubuntu.com
* Management: https://landscape.canonical.com
* Support: https://ubuntu.com/advantage
Last login: Thu Mar 1 14:51:41 2018 from 192.168.0.2
/usr/bin/xauth: (stdin):1: bad display name "edare-fmt17138762:10.0" in "remove" command
/usr/bin/xauth: (stdin):2: bad display name "edare-fmt17138762:10.0" in "add" command
lm@edare-fmt17138762:~$ xeyes
Error: Can't open display: edare-fmt17138762:10.0
Einstellung DISPLAY
Ich habe auch versucht, die Variable DISPLAY wie folgt einzustellen 127.0.0.1:10.0:
lm@edare-fmt17138762:~$ export DISPLAY='192.168.0.15:10.0'
lm@edare-fmt17138762:~$ xeyes
X11 connection rejected because of wrong authentication.
Error: Can't open display: 192.168.0.15:12.0
SSH-Konfiguration
Server
Ubuntu 16.04 mit Standard-OpenSSH.
# Package generated configuration file
# See the sshd_config(5) manpage for details
# What ports, IPs and protocols we listen for
Port 22
# Use these options to restrict which interfaces/protocols sshd will bind to
#ListenAddress ::
#ListenAddress 0.0.0.0
Protocol 2
# HostKeys for protocol version 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
HostKey /etc/ssh/ssh_host_ecdsa_key
HostKey /etc/ssh/ssh_host_ed25519_key
#Privilege Separation is turned on for security
UsePrivilegeSeparation yes
# Lifetime and size of ephemeral version 1 server key
KeyRegenerationInterval 3600
ServerKeyBits 1024
# Logging
SyslogFacility AUTH
LogLevel INFO
# Authentication:
LoginGraceTime 120
PermitRootLogin prohibit-password
StrictModes yes
RSAAuthentication yes
PubkeyAuthentication yes
#AuthorizedKeysFile %h/.ssh/authorized_keys
# Don't read the user's ~/.rhosts and ~/.shosts files
IgnoreRhosts yes
# For this to work you will also need host keys in /etc/ssh_known_hosts
RhostsRSAAuthentication no
# similar for protocol version 2
HostbasedAuthentication no
# Uncomment if you don't trust ~/.ssh/known_hosts for RhostsRSAAuthentication
#IgnoreUserKnownHosts yes
# To enable empty passwords, change to yes (NOT RECOMMENDED)
PermitEmptyPasswords no
# Change to yes to enable challenge-response passwords (beware issues with
# some PAM modules and threads)
ChallengeResponseAuthentication no
# Change to no to disable tunnelled clear text passwords
PasswordAuthentication no
# Kerberos options
#KerberosAuthentication no
#KerberosGetAFSToken no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes
# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes
X11Forwarding yes
X11DisplayOffset 10
PrintMotd no
PrintLastLog yes
TCPKeepAlive yes
#UseLogin no
#MaxStartups 10:30:60
#Banner /etc/issue.net
# Allow client to pass locale environment variables
AcceptEnv LANG LC_*
Subsystem sftp /usr/lib/openssh/sftp-server
# Set this to 'yes' to enable PAM authentication, account processing,
# and session processing. If this is enabled, PAM authentication will
# be allowed through the ChallengeResponseAuthentication and
# PasswordAuthentication. Depending on your PAM configuration,
# PAM authentication via ChallengeResponseAuthentication may bypass
# the setting of "PermitRootLogin without-password".
# If you just want the PAM account and session checks to run without
# PAM authentication, then enable this but set PasswordAuthentication
# and ChallengeResponseAuthentication to 'no'.
UsePAM yes
PasswordAuthentication no
Kunden
Das Problem ist bei mehreren Clients das gleiche und funktionierte auch hier: OpenSSH von einem anderen Ubuntu 16.04-Rechner und puTTy von Windows 10.
ssh -v
OpenSSH_7.2p2 Ubuntu-4ubuntu2.4, OpenSSL 1.0.2g 1 Mar 2016
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to 192.168.0.15 [192.168.0.15] port 22.
debug1: Connection established.
debug1: identity file <my file> type 1
debug1: key_load_public: No such file or directory
debug1: identity file <my file> type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.2p2 Ubuntu-4ubuntu2.4
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.2p2 Ubuntu-4ubuntu2.2
debug1: match: OpenSSH_7.2p2 Ubuntu-4ubuntu2.2 pat OpenSSH* compat 0x04000000
debug1: Authenticating to 192.168.0.15:22 as 'lm'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: [email protected]
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: [email protected] MAC: <implicit> compression: none
debug1: kex: client->server cipher: [email protected] MAC: <implicit> compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:WVq6hBhuqXF99QGeoyfeiLYk+l7fJOGqpyk52roqdcE
debug1: Host '192.168.0.15' is known and matches the ECDSA host key.
debug1: Found key in /home/jmilloy/.ssh/known_hosts:34
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<rsa-sha2-256,rsa-sha2-512>
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: <my key>
debug1: Server accepts key: pkalg rsa-sha2-512 blen 279
debug1: Authentication succeeded (publickey).
Authenticated to 192.168.0.15 ([192.168.0.15]:22).
debug1: channel 0: new [client-session]
debug1: Requesting [email protected]
debug1: Entering interactive session.
debug1: pledge: exec
debug1: client_input_global_request: rtype [email protected] want_reply 0
debug1: Requesting X11 forwarding with authentication spoofing.
debug1: Sending environment.
debug1: Sending env LANG = en_US.UTF-8
Welcome to Ubuntu 16.04.3 LTS (GNU/Linux 4.4.0-93-generic x86_64)
Antwort1
Überprüfen Sie hinsichtlich des Zurücksetzens des Hostnamens, ob Sie etwas wie Cloud-Config installiert und konfiguriert haben. Das bringt einiges durcheinander, Sie müssen wahrscheinlich eine Option wie update_hostname oder set_hostname ändern.
Versuchen Sie bezüglich der Frage, Folgendes zu Ihrer sshd_config hinzuzufügen und sshd neu zu starten.
X11Forwarding yes
X11DisplayOffset 10
X11UseLocalhost yes
AddressFamily inet
Antwort2
hatte das gleiche Problem, die Lösung war: Mein Hostname ( cat /etc/hostname) war NICHT in /etc/hosts.
Es gab einen anderen Namen mit meiner IP-Adresse definiert in/etc/hosts
Antwort3
/etc/hostsmuss lesbar sein. Meine /etc/hostsBerechtigungen waren -rw-r-----und das Ändern in -rw-r--r--hat das Problem behoben.