Secure Tunnelling with SSH - Et Tu, Brute? (
Page 4 of 9 )
Now comes the real test. Use SSH to log in to the remote system with this command:
[me@olympus] $ /usr/local/ssh/bin/ssh -v brutus
The "-v" option tells SSH to spew out debugging information. If all goes well, you'll see something like this:
[me@olympus] $ /usr/local/ssh/bin/ssh -v brutus
OpenSSH_3.5p1, SSH protocols 1.5/2.0, OpenSSL 0x0090701f
debug1: Reading configuration data /usr/local/ssh//etc/ssh_config
debug1: Rhosts Authentication disabled, originating port will not be
trusted.
debug1: ssh_connect: needpriv 0
debug1: Connecting to brutus [192.168.2.77] port 22.
debug1: Connection established.
debug1: identity file /home/me/.ssh/identity type 0
debug1: identity file /home/me/.ssh/id_rsa type 1
debug1: identity file /home/me/.ssh/id_dsa type 2
debug1: Remote protocol version 1.99, remote software version OpenSSH_3.5p1
debug1: match: OpenSSH_3.5p1 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_3.5p1
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: 128/256
debug1: bits set: 1543/3191
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host '192.168.2.77' is known and matches the RSA host key.
debug1: Found key in /home/me/.ssh/known_hosts:1
debug1: bits set: 1539/3191
debug1: ssh_rsa_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,keyboard-interactive
debug1: next auth method to try is publickey
debug1: try pubkey: /home/me/.ssh/id_rsa
debug1: input_userauth_pk_ok: pkalg ssh-rsa blen 149 lastkey 0x8106070 hint
1
debug1: read PEM private key done: type RSA
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
debug1: channel request 0: shell
debug1: fd 3 setting TCP_NODELAY
debug1: channel 0: open confirm rwindow 0 rmax 32768
Last login: Fri Mar 28 10:18:59 2003 from 192.168.2.81
You have mail.
[me@brutus] $
Now, wasn't that simple? What's happening behind the scenes here is very interesting. When "olympus" first connects to "brutus", it sends the user's public key to "brutus". "brutus" then sends "olympus" a challenge, usually a random number encrypted with the user's public key. "olympus" receives the challenge, decrypts it with the private key, and sends it back to "brutus". Since one of the principles of RSA authentication is that data encrypted with a public key can only be decrypted by the corresponding private key, "olympus" thus proves its identity without actually disclosing the private key, and is granted access to "brutus". In case you're asked whether or not to accept the host key, you should usually accept it - this host key is added to SSH's database of "known hosts". In case your username on the remote system is different from that on the local system, you need to specify your username on the remote host on the command line. So, in the example above, if me@olympus wanted to log in as john@brutus, the command would look like this:
[me@olympus] $ /usr/local/ssh/bin/ssh -v -l john brutus
Last login: Fri Mar 28 10:18:59 2003 from olympus.localdomain.com You have
mail. [john@brutus] $
Now comes the real test. Use SSH to log in to the remote system with this command:
[me@olympus] $ /usr/local/ssh/bin/ssh -v brutus
The "-v" option tells SSH to spew out debugging information. If all goes well, you'll see something like this:
[me@olympus] $ /usr/local/ssh/bin/ssh -v brutus
OpenSSH_3.5p1, SSH protocols 1.5/2.0, OpenSSL 0x0090701f
debug1: Reading configuration data /usr/local/ssh//etc/ssh_config
debug1: Rhosts Authentication disabled, originating port will not be
trusted.
debug1: ssh_connect: needpriv 0
debug1: Connecting to brutus [192.168.2.77] port 22.
debug1: Connection established.
debug1: identity file /home/me/.ssh/identity type 0
debug1: identity file /home/me/.ssh/id_rsa type 1
debug1: identity file /home/me/.ssh/id_dsa type 2
debug1: Remote protocol version 1.99, remote software version OpenSSH_3.5p1
debug1: match: OpenSSH_3.5p1 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_3.5p1
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: 128/256
debug1: bits set: 1543/3191
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host '192.168.2.77' is known and matches the RSA host key.
debug1: Found key in /home/me/.ssh/known_hosts:1
debug1: bits set: 1539/3191
debug1: ssh_rsa_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,keyboard-interactive
debug1: next auth method to try is publickey
debug1: try pubkey: /home/me/.ssh/id_rsa
debug1: input_userauth_pk_ok: pkalg ssh-rsa blen 149 lastkey 0x8106070 hint
1
debug1: read PEM private key done: type RSA
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
debug1: channel request 0: shell
debug1: fd 3 setting TCP_NODELAY
debug1: channel 0: open confirm rwindow 0 rmax 32768
Last login: Fri Mar 28 10:18:59 2003 from 192.168.2.81
You have mail.
[me@brutus] $
Now, wasn't that simple? What's happening behind the scenes here is very interesting. When "olympus" first connects to "brutus", it sends the user's public key to "brutus". "brutus" then sends "olympus" a challenge, usually a random number encrypted with the user's public key. "olympus" receives the challenge, decrypts it with the private key, and sends it back to "brutus". Since one of the principles of RSA authentication is that data encrypted with a public key can only be decrypted by the corresponding private key, "olympus" thus proves its identity without actually disclosing the private key, and is granted access to "brutus". In case you're asked whether or not to accept the host key, you should usually accept it - this host key is added to SSH's database of "known hosts". In case your username on the remote system is different from that on the local system, you need to specify your username on the remote host on the command line. So, in the example above, if me@olympus wanted to log in as john@brutus, the command would look like this:
[me@olympus] $ /usr/local/ssh/bin/ssh -v -l john brutus
Last login: Fri Mar 28 10:18:59 2003 from olympus.localdomain.com You have
mail. [john@brutus] $
