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 0x0090701fdebug1: Reading configuration data /usr/local/ssh//etc/ssh_configdebug1: Rhosts Authentication disabled, originating port will not betrusted.debug1: ssh_connect: needpriv 0debug1: Connecting to brutus [192.168.2.77] port 22.debug1: Connection established.debug1: identity file /home/me/.ssh/identity type 0debug1: identity file /home/me/.ssh/id_rsa type 1debug1: identity file /home/me/.ssh/id_dsa type 2debug1: Remote protocol version 1.99, remote software version OpenSSH_3.5p1debug1: match: OpenSSH_3.5p1 pat OpenSSH*debug1: Enabling compatibility mode for protocol 2.0debug1: Local version string SSH-2.0-OpenSSH_3.5p1debug1: SSH2_MSG_KEXINIT sentdebug1: SSH2_MSG_KEXINIT receiveddebug1: kex: server->client aes128-cbc hmac-md5 nonedebug1: kex: client->server aes128-cbc hmac-md5 nonedebug1: SSH2_MSG_KEX_DH_GEX_REQUEST sentdebug1: expecting SSH2_MSG_KEX_DH_GEX_GROUPdebug1: dh_gen_key: priv key bits set: 128/256debug1: bits set: 1543/3191debug1: SSH2_MSG_KEX_DH_GEX_INIT sentdebug1: expecting SSH2_MSG_KEX_DH_GEX_REPLYdebug1: Host '192.168.2.77' is known and matches the RSA host key.debug1: Found key in /home/me/.ssh/known_hosts:1debug1: bits set: 1539/3191debug1: ssh_rsa_verify: signature correctdebug1: kex_derive_keysdebug1: newkeys: mode 1debug1: SSH2_MSG_NEWKEYS sentdebug1: waiting for SSH2_MSG_NEWKEYSdebug1: newkeys: mode 0debug1: SSH2_MSG_NEWKEYS receiveddebug1: done: ssh_kex2.debug1: send SSH2_MSG_SERVICE_REQUESTdebug1: service_accept: ssh-userauthdebug1: got SSH2_MSG_SERVICE_ACCEPTdebug1: authentications that can continue:publickey,password,keyboard-interactivedebug1: next auth method to try is publickeydebug1: try pubkey: /home/me/.ssh/id_rsadebug1: input_userauth_pk_ok: pkalg ssh-rsa blen 149 lastkey 0x8106070 hint1debug1: read PEM private key done: type RSAdebug1: ssh-userauth2 successful: method publickeydebug1: channel 0: new [client-session]debug1: send channel open 0debug1: Entering interactive session.debug1: ssh_session2_setup: id 0debug1: channel request 0: pty-reqdebug1: channel request 0: shelldebug1: fd 3 setting TCP_NODELAYdebug1: channel 0: open confirm rwindow 0 rmax 32768Last login: Fri Mar 28 10:18:59 2003 from 192.168.2.81You 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 havemail. [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 0x0090701fdebug1: Reading configuration data /usr/local/ssh//etc/ssh_configdebug1: Rhosts Authentication disabled, originating port will not betrusted.debug1: ssh_connect: needpriv 0debug1: Connecting to brutus [192.168.2.77] port 22.debug1: Connection established.debug1: identity file /home/me/.ssh/identity type 0debug1: identity file /home/me/.ssh/id_rsa type 1debug1: identity file /home/me/.ssh/id_dsa type 2debug1: Remote protocol version 1.99, remote software version OpenSSH_3.5p1debug1: match: OpenSSH_3.5p1 pat OpenSSH*debug1: Enabling compatibility mode for protocol 2.0debug1: Local version string SSH-2.0-OpenSSH_3.5p1debug1: SSH2_MSG_KEXINIT sentdebug1: SSH2_MSG_KEXINIT receiveddebug1: kex: server->client aes128-cbc hmac-md5 nonedebug1: kex: client->server aes128-cbc hmac-md5 nonedebug1: SSH2_MSG_KEX_DH_GEX_REQUEST sentdebug1: expecting SSH2_MSG_KEX_DH_GEX_GROUPdebug1: dh_gen_key: priv key bits set: 128/256debug1: bits set: 1543/3191debug1: SSH2_MSG_KEX_DH_GEX_INIT sentdebug1: expecting SSH2_MSG_KEX_DH_GEX_REPLYdebug1: Host '192.168.2.77' is known and matches the RSA host key.debug1: Found key in /home/me/.ssh/known_hosts:1debug1: bits set: 1539/3191debug1: ssh_rsa_verify: signature correctdebug1: kex_derive_keysdebug1: newkeys: mode 1debug1: SSH2_MSG_NEWKEYS sentdebug1: waiting for SSH2_MSG_NEWKEYSdebug1: newkeys: mode 0debug1: SSH2_MSG_NEWKEYS receiveddebug1: done: ssh_kex2.debug1: send SSH2_MSG_SERVICE_REQUESTdebug1: service_accept: ssh-userauthdebug1: got SSH2_MSG_SERVICE_ACCEPTdebug1: authentications that can continue:publickey,password,keyboard-interactivedebug1: next auth method to try is publickeydebug1: try pubkey: /home/me/.ssh/id_rsadebug1: input_userauth_pk_ok: pkalg ssh-rsa blen 149 lastkey 0x8106070 hint1debug1: read PEM private key done: type RSAdebug1: ssh-userauth2 successful: method publickeydebug1: channel 0: new [client-session]debug1: send channel open 0debug1: Entering interactive session.debug1: ssh_session2_setup: id 0debug1: channel request 0: pty-reqdebug1: channel request 0: shelldebug1: fd 3 setting TCP_NODELAYdebug1: channel 0: open confirm rwindow 0 rmax 32768Last login: Fri Mar 28 10:18:59 2003 from 192.168.2.81You 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 havemail. [john@brutus] $
Next: No Forwarding Address >>
More Administration Articles
More By icarus, (c) Melonfire
