Administration
  Home arrow Administration arrow Page 5 - Secure Tunnelling with SSH
Dev Shed Forums 
Administration  
Apache  
BrainDump  
DHTML  
Flash  
Java  
JavaScript  
Multimedia  
MySQL  
Oracle  
Perl  
PHP  
Practices  
Python  
Reviews  
Security  
Style-Sheets  
Web Services  
XML  
Zend  
Zope  
Forums Sitemap 
IBM® developerWorks 
Dedicated Servers 
E-Commerce Hosting 
Linux Web Hosting 
Managed Hosting 
Small Business Hosting 
Download TestComplete 
VPS Hosting 
Weekly Newsletter

 
Developer Updates  
Free Website Content 
 RSS  Articles
 RSS  Forums
 RSS  All Feeds
Write For Us Get Paid 
Request Media Kit
Contact Us 
Site Map 
Privacy Policy 
Support 
 USERNAME
 
 PASSWORD
 
 
  >>> SIGN UP!  
  Lost Password? 
ADMINISTRATION

Secure Tunnelling with SSH
By: icarus, (c) Melonfire
  • Search For More Articles!
  • Disclaimer
  • Author Terms
  • Rating: 5 stars5 stars5 stars5 stars5 stars / 27
    2003-04-02

    Table of Contents:
  • Secure Tunnelling with SSH
  • Kicking The Tyres
  • Test Drive
  • Et Tu, Brute?
  • No Forwarding Address
  • Any Port In A Storm
  • Remote Control
  • In And Out
  • Log Out

  • Rate this Article: Poor Best 
      ADD THIS ARTICLE TO:
      Del.ici.ous Digg
      Blink Simpy
      Google Spurl
      Y! MyWeb Furl
    Email Me Similar Content When Posted
    Add Developer Shed Article Feed To Your Site
    Email Article To Friend
    Print Version Of Article
    PDF Version Of Article
     
     
     
    ADVERTISEMENT

    Stay one step ahead of the competition. Evaluate and give feedback on some of the hottest web development tools on the market today. Make your opinion heard! Click Here

    Secure Tunnelling with SSH - No Forwarding Address
    (Page 5 of 9 )

    Now that you have your two hosts talking to each other over an encrypted connection, the next step is to set up a secure channel between them for non-telnet type activities - for example, setting up a secure tunnel for mail transfer.

    In order to do this, you need to use the port forwarding support built into OpenSSH. Port forwarding essentially means that connections made to a port on one host are automatically and transparently forwarded to another port on another host. Since SSH is taking care of the forwarding for you, the connection also gets encrypted - a nice (and very useful) bonus.

    The best way to demonstrate how this works is with an example. Let's suppose that I would like to read my mail on "brutus", the network's POP3 mail server, from my personal Linux box, "olympus". Normally, I would configure my mail client to connect to port 110 on "brutus" to retrieve my mail - this would involve sending my username and mail password to "brutus" in cleartext across the network, a technique that we have determined to be unsuitable for purposes of this tutorial.

    With port forwarding, I have an alternative. I can have SSH forward a port (say, 9000) on my local host, "olympus", to port 110 on "brutus", and protect all traffic passing between the two (including my mail password) by creating a secure tunnel between the two hosts and ports. Once the tunnel is established, my mail client would no longer connect to port 110 on "brutus" to get my mail; rather, I would configure it to use port 9000 on my local host, "olympus", instead, and SSH would take care of automatically passing the data to post 110 on "brutus" via the tunnel.

    Here's how to go about doing this:
    [me@olympus] $ /usr/local/ssh/bin/ssh -L 9000:localhost:110 brutus
    
    Translated into English, the above command merely says "listen for connections to port 9000 on this local host, and use the remote host named brutus to forward all those connections to port 110 on the host named localhost".

    SSH will now connect and log in to "brutus", and simultaneously begin forwarding port 9000.
    [me@olympus] $ /usr/local/ssh/bin/ssh -L 9000:localhost:110 brutus Last
    login: Fri Mar 28 10:18:59 2003 from olympus.localdomain.com [me@brutus] $ 
    You can now verify that the port is indeed being forwarded by switching to another terminal on "olympus" and opening up a telnet connection to port 9000.
    [me@olympus] $ telnet localhost 9000
    Trying 127.0.0.1...Connected to localhostEscape character is '^]'.+OK POP3 brutus v7.64 server ready
    As you can see, connections to port 9000 on your local host are being transmitted to port 110 (the POP3 server port) on the host named "brutus". All data transmitted in this session will be encrypted and decrypted by the SSH daemons running at the two ends of the connection.

    Note that this connection remains available for the duration of your SSH session - the moment you log out of "brutus", the port forwarding will also stop.

    If this is not what you want, you can add the "-N" command-line argument to tell SSH *not* to execute any command on the remote side once the connection has been established. Background the task, and you'll have port forwarding without a login on the remote host!
    [me@olympus] $ /usr/local/ssh/bin/ssh -L 9000:localhost:110 brutus -N &
    
    Note that if you do this, you will need to manually kill the process when you want to stop forwarding the specified ports.

    You can also forward more than one port at a time by specifying them all on the same command line:
    [me@olympus] $ /usr/local/ssh/bin/ssh -L 9000:localhost:110 -L
    9001:localhost:25 brutus

    More Administration Articles
    More By icarus, (c) Melonfire


     

       

    ADMINISTRATION ARTICLES

    - Configuring Load-Balanced Clusters
    - Load-Balanced Clusters
    - UNIX Time Format Demystified
    - Making Changes in the CVS
    - Building Your First CVS Repository
    - CVS Quickstart Guide
    - Authorizing Users in Samba
    - Handling User Accounts in Samba
    - Authentication in Samba
    - Accounts, Authentication, and Authorization
    - Advanced Concepts on Dealing with Files and ...
    - Dealing with Files and Filesystems
    - More Hacks for the User Environment in BSD
    - Personalizing the User Environment in BSD
    - Customizing the User Environment in BSD

     
    Accelerating Trading Partner Performance
     
    Competing on Analytics
     
    Cost Effective Scaling with Virtualization and Coyote Point Systems
     
    Five Checkpoints to Implementing IP Telephony
     
    Hosted Email Security: Staying Ahead of New Threats
     




    © 2003-2008 by Developer Shed. All rights reserved. DS Cluster 3 hosted by Hostway