# $OpenBSD: ssh_config,v 1.35 2020/07/17 03:43:42 dtucker Exp $
# This is the ssh client system-wide configuration file. See
# ssh_config(5) for more information. This file provides defaults for
# users, and the values can be changed in per-user configuration files
# or on the command line.
# Configuration data is parsed as follows:
# 1. command line options
# 2. user-specific file
# 3. system-wide file
# Any configuration value is only changed the first time it is set.
# Thus, host-specific definitions should be at the beginning of the
# configuration file, and defaults at the end.
# Site-wide defaults for some commonly used options. For a comprehensive
# list of available options, their meanings and defaults, please see the
# ssh_config(5) man page.
# Host *
# ForwardAgent no
# ForwardX11 no
# PasswordAuthentication yes
# HostbasedAuthentication no
# GSSAPIAuthentication no
# GSSAPIDelegateCredentials no
# BatchMode no
# CheckHostIP yes
# AddressFamily any
# ConnectTimeout 0
# StrictHostKeyChecking ask
# IdentityFile ~/.ssh/id_rsa
# IdentityFile ~/.ssh/id_dsa
# IdentityFile ~/.ssh/id_ecdsa
# IdentityFile ~/.ssh/id_ed25519
# Port 22
# Ciphers aes128-ctr,aes192-ctr,aes256-ctr,aes128-cbc,3des-cbc
# MACs hmac-md5,hmac-sha1,umac-64@openssh.com
# EscapeChar ~
# Tunnel no
# TunnelDevice any:any
# PermitLocalCommand no
# VisualHostKey no
# ProxyCommand ssh -q -W %h:%p gateway.example.com
# RekeyLimit 1G 1h
# UserKnownHostsFile ~/.ssh/known_hosts.d/%k
Host *
ForwardX11 yes
ForwardX11Trusted yes
When I do ssh -Xvvv marco@mgcl1n3 I am getting:
debug1: Next authentication method: password
marco@mgcl1n3's password:
debug3: send packet: type 50
debug2: we sent a password packet, wait for reply
debug3: receive packet: type 52
Authenticated to mgcl1n3 ([192.168.1.108]:22) using "password".
debug1: channel 0: new [client-session]
debug3: ssh_session2_open: channel_new: 0
debug2: channel 0: send open
debug3: send packet: type 90
debug1: Requesting no-more-sessions@openssh.com
debug3: send packet: type 80
debug1: Entering interactive session.
debug1: pledge: exec
debug3: receive packet: type 80
debug1: client_input_global_request: rtype hostkeys-00@openssh.com want_reply 0
debug3: client_input_hostkeys: received RSA key SHA256:8hXK2Wvykd9xAc9jc8wzqzf6eedzo4PxTbNR19mdRWs
debug3: client_input_hostkeys: received ECDSA key SHA256:qp4RuAKhZY66w33ELNjO/7u1sutzkxbrkpAMyr16ElE
debug3: client_input_hostkeys: received ED25519 key SHA256:C7s11eKa6CKTPKWul0j2DZtY2nApUjNKIhxPbW9yXc4
debug1: client_input_hostkeys: searching /home/marco/.ssh/known_hosts for mgcl1n3 / (none)
debug3: hostkeys_foreach: reading file "/home/marco/.ssh/known_hosts"
debug3: hostkeys_find: found ssh-ed25519 key at /home/marco/.ssh/known_hosts:78
debug3: hostkeys_find: found ssh-rsa key at /home/marco/.ssh/known_hosts:79
debug3: hostkeys_find: found ecdsa-sha2-nistp256 key at /home/marco/.ssh/known_hosts:80
debug1: client_input_hostkeys: searching /home/marco/.ssh/known_hosts2 for mgcl1n3 / (none)
debug1: client_input_hostkeys: hostkeys file /home/marco/.ssh/known_hosts2 does not exist
debug3: client_input_hostkeys: 3 server keys: 0 new, 3 retained, 0 incomplete match. 0 to remove
debug1: client_input_hostkeys: no new or deprecated keys from server
debug3: receive packet: type 91
debug2: channel_input_open_confirmation: channel 0: callback start
debug2: client_x11_get_proto: xauth command: /usr/bin/xauth -f /tmp/ssh-XXXXXXUKmgyw/xauthfile generate :0.0 MIT-MAGIC-COOKIE-1 untrusted timeout 1260 2>/dev/null
debug2: x11_get_proto: /usr/bin/xauth -f /tmp/ssh-XXXXXXUKmgyw/xauthfile list :0.0 2>/dev/null
debug1: Requesting X11 forwarding with authentication spoofing.
debug2: channel 0: request x11-req confirm 1
debug3: send packet: type 98
debug2: fd 3 setting TCP_NODELAY
debug3: set_sock_tos: set socket 3 IP_TOS 0x48
debug2: client_session2_setup: id 0
debug2: channel 0: request pty-req confirm 1
debug3: send packet: type 98
debug2: channel 0: request shell confirm 1
debug3: send packet: type 98
debug2: channel_input_open_confirmation: channel 0: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768
debug3: receive packet: type 100
debug2: channel_input_status_confirm: type 100 id 0
X11 forwarding request failed on channel 0
debug3: receive packet: type 99
debug2: channel_input_status_confirm: type 99 id 0
debug2: PTY allocation request accepted on channel 0
debug2: channel 0: rcvd adjust 2097152
debug3: receive packet: type 99
debug2: channel_input_status_confirm: type 99 id 0
debug2: shell request accepted on channel 0
Last login: Sun Feb 6 19:05:49 2022 from 192.168.1.38
If I manually do the command /usr/bin/xauth -f /tmp/ssh-XXXXXXUKmgyw/xauthfile generate :0.0 MIT-MAGIC-COOKIE-1 untrusted timeout 1260 I am getting:
/usr/bin/xauth: error in locking authority file /tmp/ssh-XXXXXXUKmgyw/xauthfile
Please don’t post screenshots for simple text output.
From the xhost manual…
XHOST(1) General Commands Manual XHOST(1)
NAME
xhost - server access control program for X
SYNOPSIS
xhost [[+-]name ...]
DESCRIPTION
The xhost program is used to add and delete host names or user names to the list allowed to make connections to the X server. In the case of hosts, this provides a rudimentary form of privacy control
and security. It is only sufficient for a workstation (single user) environment, although it does limit the worst abuses. Environments which require more sophisticated measures should implement the
user-based mechanism or use the hooks in the protocol for passing other authentication data to the server.
OPTIONS
Xhost accepts the following command line options described below. For security, the options that affect access control may only be run from the "controlling host". For workstations, this is the same
machine as the server. For X terminals, it is the login host.
-help Prints a usage message.
[+]name The given name (the plus sign is optional) is added to the list allowed to connect to the X server. The name can be a host name or a complete name (See NAMES for more details).
-name The given name is removed from the list of allowed to connect to the server. The name can be a host name or a complete name (See NAMES for more details). Existing connections are not broken,
but new connection attempts will be denied. Note that the current machine is allowed to be removed; however, further connections (including attempts to add it back) will not be permitted.
Resetting the server (thereby breaking all connections) is the only way to allow local connections again.
+ Access is granted to everyone, even if they aren't on the list (i.e., access control is turned off).
- Access is restricted to only those on the list (i.e., access control is turned on).
nothing If no command line arguments are given, a message indicating whether or not access control is currently enabled is printed, followed by the list of those allowed to connect. This is the only
option that may be used from machines other than the controlling host.
You need to add the host name or fully qualified domain name of the server you’re connecting to, so that it can forward its graphical output to your local X11 session.
Note:
The xhost command must be used on the machine you wish to use for viewing the GUI output of applications running on the remote machine.
The /etc/ssh/sshd_config modifications have to be applied on the remote machine.
[marco@dellg5 ~]$ xhost +mgcl1n3
mgcl1n3 being added to access control list
[marco@dellg5 ~]$ ssh -X marco@mgcl1n3
marco@mgcl1n3's password:
X11 forwarding request failed on channel 0
Last login: Sun Feb 6 20:07:09 2022 from 192.168.1.38
[marco@mgcl1n3 ~]$
If you get “X11 forwarding request failed on channel 0” when you connect (and the server /var/log/errors.log shows “Failed to allocate internet-domain X11 display socket”), make sure package xorg-xauth is installed. If its installation is not working, try to either:
enable the AddressFamily any option in sshd_config on the server, or
set the AddressFamily option in sshd_config on the server to inet.
Setting it to inet may fix problems with Ubuntu clients on IPv4.
For running X applications as other user on the SSH server you need to xauth add the authentication line taken from xauth list of the SSH logged in user.
Crazy! In /etc/ssh/ there are two config files: ssh_config and sshd_config.
I was changing the first while the config for the server is the second!
Sorry @Aragorn .
Thanks a lot.
Because xdmcp is insecure - it is recommended to use x11 forwarding over ssh but you will have to enable it on the server - not the client. It is a long time ago - it was an experiment so I have forgotten the details. I think it was a combination of Arch wiki XDM and XDMCP plus the Xming web which made it work.
What I do remember is not a trivial task to set up and the first time I actually made it work - it was an eyeopener - What?! Is that really possible?!
It’s like VNC but with a single app instead of a desktop - even browsing the filesystem from that app - I remember it was Webstorm - it was the remote file system - not my laptop’s.
