Contents

  1. OpenSSH
    1. Using Through SOCKS Proxy
    2. Opportunistic SSH Tunnels
    3. Setting Up Passwordless SSH
    4. NFS Through an SSH Tunnel
    5. Restricting Access to Chroot SCP/SFTP Only
  2. Cisco Pix
  3. Windows

OpenSSH

Please note that all Unix SSH stuff refers to OpenSSH, while most of it will work with F-Secure SSH some of the fancier features won't. You should upgrade anyway if you haven't. As a side note the version of SSH that comes with MacOS X is OpenSSH.

Using Through SOCKS Proxy

Read all about it here:

Opportunistic SSH Tunnels

New versions of OpenSSH support the -D option. What this does is allow SSH tunnels to be dynamically setup as needed between your client host (say your laptop) and a particular server. This is expecially useful when using an insecure network (like an open wireless network).

How it works:

From your laptop run (where host.domain.com is a trusted host you can log into where you want all of your connections tunnelled to):

# ssh -D 1080 host.domain.com

SSH now emulates a SOCKS 4 service on localhost. So configure your client applications to access the network via the SOCKS proxy (many applications support this).

Their are two problems with this:

  1. SOCKS 4 doesn't allow DNS queries to go through it, so make sure that any hosts you reference are resolvable without the tunnel (you may need to put hosts into your /etc/hosts file).

  2. Many applications that don't support SOCKS. Windows and MacOS X have an OS wide setting to make everything go via SOCKS (I believe) so it's primarily a Unix/Linux problem.

Fortunately there is a Unix utility called socksify which will enable a non-SOCKS application to talk SOCKS (in DebianLinux the package is called dante-client). Here's a sample /etc/socks.conf file which will work: 

route { 
        from: 0.0.0.0/0   to: 0.0.0.0/0   via: 127.0.0.1 port = 1080
        proxyprotocol: socks_v4
}

You run it like this:

# socksify ftp ftp.netscape.com

and use it as normal. If you get a "Name or service not known" error, it means that the host your are trying to reach is non-resolvable. Either try it with an IP or fix your DNS.

If you're curious about why you should secure your traffic check out RobFlickenger's WebLog post about what he did at the O'Reilly Emerging Tech conference.

Setting Up Passwordless SSH

This is often useful for scripting transfers of data, but sometimes requires more cooperation from the server then you have (eg. they have to enable RhostsRSAAuthentication or similar which admins are reluctant to do). Here's a way around that I just found out about, do the below steps on the box you want to SSH from:

Generate an SSH key with a null password (I've been using DSA with SSHv2 but it will work with any scheme). Using the "-f ~/.ssh/identiy" parameter means that that it will save the keys in your ~/.ssh/ directory with the names identity and identity.pub which saves you some hassle later:

Set up the remote server to accept the new key as a trusted key (if you are using an older version of OpenSSH you and you want to use SSHv2 you may have to call the file authorized_keys2):

And now setup passwordless SSH as normal:

And you are done. Bear in mind though that your account on the remote server is only as secure as your account on the local server as this trick nicely by passes all of SSH's protection mechanisms to keep your keys safe (ie. I shoot you if you do this into my server ;) ).

Note: You can do the same thing with an alternate identity file (useful if you don't want your primary identity file to be passwordless) like this:

JohnMcDaniel says: This may not work so great for you if your username is different on the remote host than on the local machine. I have been trying to set up a tunnel via a password-less ssh and I get no love. Yes, I know about -l and user@host.

Brett Johnson says: A better (and more secure) way to do this is to generate a key with a passphrase, and use ssh-agent to authenticate the key for you. Most desktops (i.e. gnome & kde) run ssh-agent for you, so all you need to do is type "ssh-add", and type the passphrase for your key. From then on, anytime you use that key from that machine, you won't need to retype the passphrase.

For non-interactive use there is keychain which maintains the same ssh-agent process throughout the life of the machine and allows you to hook into it without providing a passphrase. This article shows how to set it up including how to setup cron jobs to use the existing ssh-agent. -- AaronCaskey

NFS Through an SSH Tunnel

While not as sexxy as Intermezzo it's also not nearly as close to the bleeding edge. Best reference I've seen is here:

Restricting Access to Chroot SCP/SFTP Only

If you want to use OpenSSH's built in support for SCP/SFTP as a way to provision a secure replacement for traditional FTP servers you need to be able to make sure that FTP accounts are restricted to their home directory (chroot'd) and can't execute commands on the server (eg. normally SSH access). One way of doing this is with the "scponly" shell.

http://sublimation.org/scponly/

Cisco Pix

This is untested but should be how to setup SSH on a Cisco Pix. -- AdamShand

First you have to make sure that it's name is setup right:

Now you have to generate the key that SSH uses for authentication and encryption:

and finally setup who can access the server and timeouts:

And that should do it. If you have any aaa authentication lines then you will need a line for SSH as well, something like this might work (where Auth is the keyword you used in a prior aaa-server line):

Note: SSH is not supported on PIXes configured for failover.

Windows

Cygwin is available at:

Alternatively, Putty is a really nice set of ssh utilities

There is information (and a download) for running SSH on NT available:

CategorySoftware

UsingSsh (last edited 2004-05-17 11:02:31 by httpproxy)