To enable verbose X11/ssh diagnostics back on WOMBATNET, we would issue the following command:
[WOMBATNET:/home/wombat]
$ ssh -v -X chinookfe.ucar.edu
This would then start to produce a diagnostic stream of data:
OpenSSH_3.4p1, SSH protocols 1.5/2.0, OpenSSL 0x0090601f
debug1: Reading configuration data /usr/etc/ssh_config
debug1: Rhosts Authentication disabled, originating port will not be trusted.
debug1: ssh_connect: needpriv 0
debug1: Connecting to chinookfe [128.117.215.218] port 22.
debug1: Connection established.
debug1: identity file /home/wombat/.ssh/identity type 0
debug1: identity file /home/wombat/.ssh/id_rsa type -1
debug1: identity file /home/wombat/.ssh/id_dsa type 2
debug1: Remote protocol version 1.99, remote software version OpenSSH_3.1p1
debug1: match: OpenSSH_3.1p1 pat OpenSSH_2.*,OpenSSH_3.0*,OpenSSH_3.1*
Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_3.4p1
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: dh_gen_key: priv key bits set: 134/256
debug1: bits set: 1041/2049
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'chinookfe' is known and matches the DSA host key.
debug1: Found key in /home/wombat/.ssh/known_hosts:17
debug1: bits set: 1003/2049
debug1: ssh_dss_verify: signature correct
debug1: kex_derive_keys
debug1: newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: waiting for SSH2_MSG_NEWKEYS
debug1: newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: done: ssh_kex2.
debug1: send SSH2_MSG_SERVICE_REQUEST
debug1: service_accept: ssh-userauth
debug1: got SSH2_MSG_SERVICE_ACCEPT
debug1: authentications that can continue: publickey,password
debug1: next auth method to try is publickey
debug1: userauth_pubkey_agent: testing agent key /home/wombat/.ssh/id_dsa
debug1: try privkey: /home/wombat/.ssh/id_rsa
debug1: try pubkey: /home/wombat/.ssh/id_dsa
debug1: authentications that can continue: publickey,password
debug1: next auth method to try is password
wombat@chinookfe's password:
We enter our password and diagnostics continue:
debug1: input_userauth_pk_ok: pkalg ssh-dss blen 433 lastkey 0x808e370 hint -1
debug1: ssh-userauth2 successful: method publickey
debug1: channel 0: new [client-session]
debug1: send channel open 0
debug1: Entering interactive session.
debug1: ssh_session2_setup: id 0
debug1: channel request 0: pty-req
The following messages are important to the X11 forwarding process and would not be present in the diagnostic stream if X11 forwarding was not requested via the "-X".
debug1: Requesting X11 forwarding with authentication spoofing.
debug1: channel request 0: x11-req
debug1: channel request 0: shell
debug1: fd 3 setting TCP_NODELAY
debug1: channel 0: open confirm rwindow 0 rmax 3276
Last login: Thu Jul 18 9:10:46 MDT 2002 on ssh from WOMBATNET.net
Here there certainly seems to be a problem, the "sshd" process on chinookfe gets the issued request from the "ssh" client software (see above) running on WOMBATNET and tries to run the "xauth" command on chinookfe. The following message indicates that a process on chinookfe already has the ".Xauthority" file in user wombat's home directory locked:
/usr/bin/X11/xauth: 1356-361 Timeout in locking authority file
/home/chinook/wombat/.Xauthority
After several attempts, the system continues to the MOTD and places us at our prompt, indicating a completion of the login process:
Last login: Thur Jul 18 8:31:00 2002 from WOMBATNET.net
=======================================================================
chinookfe: IRIX64 6.5.16, SGI Origin2000 (8 cpus, 8 GB's memory)
=======================================================================
THIS SYSTEM IS FOR THE USE OF AUTHORIZED USERS ONLY. INDIVIDUALS USING
THIS COMPUTER SYSTEM WITHOUT AUTHORITY, OR IN EXCESS OF THEIR AUTHORITY,
ARE SUBJECT TO HAVING ALL THEIR ACTIVITIES ON THIS SYSTEM MONITORED AND
RECORDED BY SYSTEM PERSONNEL. IN THE COURSE OF MONITORING INDIVIDUALS
IMPROPERLY USING THIS SYSTEM, OR IN THE COURSE OF SYSTEM MAINTENANCE,
THE ACTIVITIES OF AUTHORIZED USERS MAY ALSO BE MONITORED.
=========================================================================
[chinookfe:/home/chinook/wombat]
$
It is important to note that although this example was contrived to fail, there are two important high-level steps in successful X11 forwarding through "ssh". First, the "ssh" client on the workstation must issue the X11 forwarding request. We initiated this with "ssh -X" from WOMBATNET and further confirmed in our debug stream above. Second, the target host, in this case chinookfe, must be able to modify the user's ".Xauthority" file on chinookfe in response to the X11 forwarding request from the workstation.
On chinookfe, we can check the ".Xauthority" file using the "xauth" utility. See the man page on "xauth" for more details:
[chinookfe:/home/chinook/wombat]
$ xauth
xauth: 1356-361 Timeout in locking authority file
/home/chinook/wombat/.Xauthority
If we are unable to run "xauth" because of file locking issues, we can use the "xauth -b" command to try to clear any outstanding locks:
[chinookfe:/home/chinook/wombat]
$ xauth -b
Attempting to break locks on authority file /home/chinook/wombat/.Xauthority
Using authority file /home/chinook/wombat/.Xauthority
xauth> exit
It is important that we "exit" the "xauth" utility to clear the final lock on the file.
Another even more common occurence is that a user will overrun the disk quota in the home directory on the target system. This can prevent "xauth", as run by "sshd", from being able to add the appropriate entry to the ".Xauthority" file. We can double-check our file quotas on chinookfe by running the "quota -v" command. Assuming we haven't exceeded our disk quota, we now log out and log back in:
[chinookfe:/home/chinook/wombat]
$ exit
debug1: channel 0: rcvd eof
debug1: channel 0: output open -> drain
debug1: channel 0: obuf empty
debug1: channel 0: close_write
debug1: channel 0: output drain -> closed
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug1: channel 0: rcvd close
debug1: channel 0: close_read
debug1: channel 0: input open -> closed
debug1: channel 0: almost dead
debug1: channel 0: gc: notify user
debug1: channel 0: gc: user detached
debug1: channel 0: send close
debug1: channel 0: is dead
debug1: channel 0: garbage collecting
debug1: channel_free: channel 0: client-session, nchannels 1
Connection to blackforest closed.
debug1: Transferred: stdin 0, stdout 0, stderr 35 bytes in 2.2 seconds
debug1: Bytes per second: stdin 0.0, stdout 0.0, stderr 15.8
debug1: Exit status 0
Logging in without verbose diagnostics:
[WOMBATNET:/home/wombat]
$ ssh -X chinookfe.ucar.edu
wombat@chinookfe's password:
We enter our password to proceed and complete the login process.
Often a ".Xauthority" file will have many lines with cookie entries. There should be one entry that corresponds to the present DISPLAY setting. Comparing what follows to the ".Xauthority" entries shows that this is indeed the case:
[chinookfe:/home/chinook/wombat]
$ echo $DISPLAY
chinookfe:24.0
[chinookfe:/home/chinook/wombat]
$ xauth list
chinookfe.ucar.edu:24 MIT-MAGIC-COOKIE-1 1aecd6411dd6e0036d8a138325b1a25c
Note the match between the designated targets.
We should now be able to run X11 applications and display them back to WOMBATNET.
If you have questions about this document, please contact SCD Customer Support. You can also reach us by telephone 24 hours a day, seven days a week at 303-497-1278. Additional contact methods: consult1@ucar.edu and during business hours in NCAR Mesa Lab Suite 39.