next up previous
Next: Reporting problems logging into Up: Problem-resolution guidelines Previous: Verifying basic networking


Diagnostics with verbose logging

Now that we have confirmed a basic networking connection, we can use the "ssh" client on WOMBATNET to provide a full dump on what is occurring during a connection attempt to chinookfe.ucar.edu. The "ssh -v chinookfe.ucar.edu" command attempts to establish a session from WOMBATNET to chinookfe and provides a rather full description of what "ssh" is trying to do while establishing the connection:

    [WOMBATNET:/home/wombat]
    $ ssh -v chinookfe.ucar.edu

    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: 127/256
    debug1: bits set: 1033/2049
    debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
    debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY

At this point in the debug output, you may see something like this:

    The authenticity of host 'chinookfe.ucar.edu (128.117.215.218)' can't be established.
    DSA key fingerprint is ff:ff:80:56:ec:b8:50:38:6e:3f:fb:95:0a:64:fb:46.
    Are you sure you want to continue connecting (yes/no)?

You will see this if you are connecting for the first time, or if you are connecting since the last major "sshd" upgrade, or if for some reason you have removed or lost your local ".ssh" directory, which should exist in your home directory on your workstation. If you are uncertain about what is happening and this isn't your first time connecting to chinookfe.ucar.edu, we suggest you contact consult1@ucar.edu to verify connectivity before proceeding. If this is your first time connecting or you have moved or removed your ".ssh" directory or the associated "known_hosts" file, located within the ".ssh" directory, respond with a "yes" and press "Enter".

The output will then continue:

    debug1: Host 'chinookfe' is known and matches the DSA host key.
    debug1: Found key in /home/wombat/.ssh/known_hosts:43
    debug1: bits set: 1042/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: authentications that can continue: publickey,password
    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

In this example, since we haven't generated a public key, "ssh" will prompt us for user wombat's password on chinookfe:

    wombat@chinookfe's password:

If, after entering several password attempts, you get:

    debug1: authentications that can continue: publickey,password
    Permission denied, please try again.

You will need to contact consult1@ucar.edu to confirm that the machine is not restricted. If it isn't an SCD consultant will provide directions to you to have your account checked and possibly have your password reset.

Assuming the system accepts your password, debug output will continue like this:

    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
    debug1: channel request 0: shell
    debug1: fd 3 setting TCP_NODELAY
    debug1: channel 0: open confirm rwindow 0 rmax 32768
    Last login: Mon Jul 15 12:12:01 MDT 2002 on ssh from WOMBATNET.net

Until the MOTD (Message Of The Day) displays:

    Last login: Wed Jul 17 13:27:28 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.
    =========================================================================
    Please report any problems to "consult1@ucar.edu".

    [chinookfe:/home/chinook/wombat]
    $

At this point, basic login via "ssh" to chinookfe is complete. Please note the prompt you see will be different than the one shown above.

Assuming this process has succeeded, you should logout and log in again in non-verbose mode. This will prevent the continuous streaming of debug messages to your screen:

    [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 chinookfe closed.
    debug1: Transferred: stdin 0, stdout 0, stderr 28 bytes in 3.6 seconds
    debug1: Bytes per second: stdin 0.0, stdout 0.0, stderr 7.8
    debug1: Exit status 0


next up previous
Next: Reporting problems logging into Up: Problem-resolution guidelines Previous: Verifying basic networking

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.