Home arrow Site Administration arrow Page 4 - Secure Tunnelling with SSH

Et Tu, Brute? - Administration

You probably already know how to use SSH to securely log in toremote hosts over the Web. In this article, take things a little further byusing SSH to encrypt connections to other ports as well. Scenarios coveredinclude securing your mail server connection so that your mail password isalways protected and creating secure pathways through firewalls for trustedhosts.

TABLE OF CONTENTS:
  1. Secure Tunnelling with SSH
  2. Kicking The Tyres
  3. Test Drive
  4. Et Tu, Brute?
  5. No Forwarding Address
  6. Any Port In A Storm
  7. Remote Control
  8. In And Out
  9. Log Out
By: icarus, (c) Melonfire
Rating: starstarstarstarstar / 29
April 02, 2003

print this article
SEARCH DEV SHED

TOOLS YOU CAN USE

advertisement
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] $


 
 
>>> More Site Administration Articles          >>> More By icarus, (c) Melonfire
 

blog comments powered by Disqus
escort Bursa Bursa escort Antalya eskort
   

SITE ADMINISTRATION ARTICLES

- Coding: Not Just for Developers
- To Support or Not Support IE?
- Administration: Networking OSX and Win 7
- DotNetNuke Gets Social
- Integrating MailChimp with Joomla: Creating ...
- Integrating MailChimp with Joomla: List Mana...
- Integrating MailChimp with Joomla: Building ...
- Integrating MailChimp with Joomla
- More Top WordPress Plugins for Social Media
- Optimizing Security: SSH Public Key Authenti...
- Patches and Rejects in Software Configuratio...
- Configuring a CVS Server
- Managing Code and Teams for Cross-Platform S...
- Software Configuration Management
- Back Up a Joomla Site with Akeeba Backup

Developer Shed Affiliates

 


Dev Shed Tutorial Topics: