But first, let’s install some dependencies. I assume that you will try the code on a machine aimed for testing, so I won’t be using the system’s package manager but instead use easy_install to install the needed Python modules. Other commands like pip could be used as well. If you do not want to mess with your system-wide python installation, just use virtualenv and pip, but I won’t go into the details about how to use these tools in the current document.

Install the needed dependencies:

easy_install pycrypto
easy_install pyasn1
easy_install pam
easy_install twisted

Make sure you have gcc installed, because it will be needed to complete the installation of Twisted and PyCrypto.

I have created a project for this code at Bitbucket, called RapidSSH. This will make it easier to share code and ideas about SSH server implementations in Python using Twisted.

Filename: scripts/rapidsshd_unix.py

#!/usr/bin/env python
#
# This file is part of rapidssh - http://bitbucket.org/gnotaras/rapidssh/
#
# rapidssh - A set of Secure Shell (SSH) server implementations in Python
#            using Twisted.conch, part of the Twisted Framework.
#
# Copyright (c) 2010 George Notaras - http://www.g-loaded.eu
#
# Permission is hereby granted, free of charge, to any person obtaining a copy
# of this software and associated documentation files (the "Software"), to deal
# in the Software without restriction, including without limitation the rights
# to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
# copies of the Software, and to permit persons to whom the Software is
# furnished to do so, subject to the following conditions:
#
# The above copyright notice and this permission notice shall be included in
# all copies or substantial portions of the Software.
#
# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
# AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
# OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
# THE SOFTWARE.
#
# Initially based on the sshsimpleserver.py kindly published by:
# Twisted Matrix Laboratories - http://twistedmatrix.com
#
 
import sys
import pam
 
from twisted.conch.unix import UnixSSHRealm
from twisted.cred import portal
from twisted.cred.credentials import IUsernamePassword
from twisted.cred.checkers import ICredentialsChecker
from twisted.cred.error import UnauthorizedLogin
from twisted.conch.checkers import SSHPublicKeyDatabase
from twisted.conch.ssh import factory, userauth, connection, keys, session
from twisted.internet import reactor, defer
from zope.interface import implements
from twisted.python import log
 
# Logging
# Currently logging to STDERR
log.startLogging(sys.stderr)
 
# Server-side public and private keys. These are the keys found in
# sshsimpleserver.py. Make sure you generate your own using ssh-keygen!
 
publicKey = 'ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAGEArzJx8OYOnJmzf4tfBEvLi8DVPrJ3/c9k2I/Az64fxjHf9imyRJbixtQhlH9lfNjUIx+4LmrJH5QNRsFporcHDKOTwTTYLh5KmRpslkYHRivcJSkbh/C+BR3utDS555mV'
 
privateKey = """-----BEGIN RSA PRIVATE KEY-----
MIIByAIBAAJhAK8ycfDmDpyZs3+LXwRLy4vA1T6yd/3PZNiPwM+uH8Yx3/YpskSW
4sbUIZR/ZXzY1CMfuC5qyR+UDUbBaaK3Bwyjk8E02C4eSpkabJZGB0Yr3CUpG4fw
vgUd7rQ0ueeZlQIBIwJgbh+1VZfr7WftK5lu7MHtqE1S1vPWZQYE3+VUn8yJADyb
Z4fsZaCrzW9lkIqXkE3GIY+ojdhZhkO1gbG0118sIgphwSWKRxK0mvh6ERxKqIt1
xJEJO74EykXZV4oNJ8sjAjEA3J9r2ZghVhGN6V8DnQrTk24Td0E8hU8AcP0FVP+8
PQm/g/aXf2QQkQT+omdHVEJrAjEAy0pL0EBH6EVS98evDCBtQw22OZT52qXlAwZ2
gyTriKFVoqjeEjt3SZKKqXHSApP/AjBLpF99zcJJZRq2abgYlf9lv1chkrWqDHUu
DZttmYJeEfiFBBavVYIF1dOlZT0G8jMCMBc7sOSZodFnAiryP+Qg9otSBjJ3bQML
pSTqy7c3a2AScC/YyOwkDaICHnnD3XyjMwIxALRzl0tQEKMXs6hH8ToUdlLROCrP
EhQ0wahUTCk1gKA4uPD6TMTChavbh4K63OvbKg==
-----END RSA PRIVATE KEY-----"""
 
 
class PamPasswordDatabase:
    """Authentication/authorization backend using the 'login' PAM service"""
    credentialInterfaces = IUsernamePassword,
    implements(ICredentialsChecker)
 
    def requestAvatarId(self, credentials):
        if pam.authenticate(credentials.username, credentials.password):
            return defer.succeed(credentials.username)
        return defer.fail(UnauthorizedLogin("invalid password"))
 
 
class UnixSSHdFactory(factory.SSHFactory):
    publicKeys = {
        'ssh-rsa': keys.Key.fromString(data=publicKey)
    }
    privateKeys = {
        'ssh-rsa': keys.Key.fromString(data=privateKey)
    }
    services = {
        'ssh-userauth': userauth.SSHUserAuthServer,
        'ssh-connection': connection.SSHConnection
    }
 
# Components have already been registered in twisted.conch.unix
 
portal = portal.Portal(UnixSSHRealm())
portal.registerChecker(PamPasswordDatabase())   # Supports PAM
portal.registerChecker(SSHPublicKeyDatabase())  # Supports PKI
UnixSSHdFactory.portal = portal
 
if __name__ == '__main__':
    reactor.listenTCP(5022, UnixSSHdFactory())
    reactor.run()

Some notes:

• The server uses the very same public and private keys as found in the sshsimpleserver.py script. Make sure you generate new keys using ssh-keygen if you plan to run this on a public server (although this not recommended).
• Twisted included a module for PAM authentication, twisted.cred.pamauth, but unfortunately I could not locate one of its dependencies to make it work. So, I used the excellent python-pam to create a custom PAM authenticator class.
• I can guess what you might thought when you read about this code:
  

  Python is a cross-platform programming language. Twisted runs on Windows. So, is this a solution for running a SSH server on Win32?

  Well, at the moment it won’t run because internally it uses some Python modules that are available on UNIX platforms only. But, I intend to investigate the possibility of running this on Windows since I already need something like that.

We can now enjoy our Python SSH server. Run as root:

python scripts/rapidsshd_unix.py

From another machine, connect to the server using an ssh client:

ssh -p 5022 rocky@arena

If you have deployed your public key in the ~/.ssh/authorized_keys file on the remote machine (arena), you should be able to authenticate using the public key:

ssh -p 5022 -i /path/to/private.key rocky@arena

You should get output like the following on the server:

[root@arena ~]# python ssh.py
2010-03-26 21:30:05+0000 [-] Log opened.
2010-03-26 21:30:05+0000 [-] __main__.UnixSSHdFactory starting on 5022
2010-03-26 21:30:05+0000 [-] Starting factory <__main__.UnixSSHdFactory instance at 0xb7a0b0cc>
2010-03-26 21:30:13+0000 [__main__.UnixSSHdFactory] disabling diffie-hellman-group-exchange because we cannot find moduli file
2010-03-26 21:30:13+0000 [SSHServerTransport,0,192.168.0.172] kex alg, key alg: diffie-hellman-group1-sha1 ssh-rsa
2010-03-26 21:30:13+0000 [SSHServerTransport,0,192.168.0.172] outgoing: aes256-ctr hmac-sha1 none
2010-03-26 21:30:13+0000 [SSHServerTransport,0,192.168.0.172] incoming: aes256-ctr hmac-sha1 none
2010-03-26 21:30:14+0000 [SSHServerTransport,0,192.168.0.172] NEW KEYS
2010-03-26 21:30:14+0000 [SSHServerTransport,0,192.168.0.172] starting service ssh-userauth
2010-03-26 21:30:17+0000 [SSHService ssh-userauth on SSHServerTransport,0,192.168.0.172] rocky trying auth none
2010-03-26 21:30:17+0000 [SSHService ssh-userauth on SSHServerTransport,0,192.168.0.172] rocky trying auth publickey
2010-03-26 21:30:17+0000 [SSHService ssh-userauth on SSHServerTransport,0,192.168.0.172] rocky trying auth publickey
2010-03-26 21:30:17+0000 [SSHService ssh-userauth on SSHServerTransport,0,192.168.0.172] rocky authenticated with publickey
2010-03-26 21:30:17+0000 [SSHService ssh-userauth on SSHServerTransport,0,192.168.0.172] starting service ssh-connection
2010-03-26 21:30:17+0000 [SSHService ssh-connection on SSHServerTransport,0,192.168.0.172] got channel session request
2010-03-26 21:30:17+0000 [SSHChannel session (0) on SSHService ssh-connection on SSHServerTransport,0,192.168.0.172] channel open
2010-03-26 21:30:17+0000 [SSHChannel session (0) on SSHService ssh-connection on SSHServerTransport,0,192.168.0.172] pty request: xterm (24L, 80L, 0L, 0L)
2010-03-26 21:30:17+0000 [SSHChannel session (0) on SSHService ssh-connection on SSHServerTransport,0,192.168.0.172] getting shell

This first release of the RapidSSH project exists solely for demonstration purposes. Don’t get fooled by the small amount of code. Information about how to put the pieces together is scarce and it required a lot trial&error and source code reading. The above implementation contains none of the customizations I had in mind. These will be done as soon as I find some time to do so. Until then it will be nice to hear about your experiences or implementations you have worked on.

Related Articles

• Use Python to get the web page data in Epiphany
• Epiphany Python Console – Open New Tab
• Python IRC Bot
• Python Crash Course
• Set up the VNC Server in Fedora

This article describes in brief how to configure VNC server instances for one or multiple users on a remote machine, how to use VNC to start graphical applications on boot and finally how to enhance security by connecting to the server through encrypted SSH tunnels.

Prerequisites

A user account should exist on the remote machine.
The RPM packages vnc-server and vnc should be installed on the remote machine and your workstation respectively.

Setting up the server

I assume that we have setup a remote user account, named "leopard" and we want to start an X session through VNC for this user.

In Fedora Core or Red Hat based distros in general, all we have to do is define the VNC server instances in /etc/sysconfig/vncservers. These will be started by the vncserver initscript. This has to be done as root. Edit this file so that it contains the following:

VNCSERVERS="3:leopard"
VNCSERVERARGS[3]="-geometry 1024x768 -depth 16"

With these we define that a vnc server instance should be started as user leopard on display 3 and we also set some options for this server such as resolution and color depth. Each VNC server instance listens on port 5900 plus the display number on which the server runs. In our case, leopard’s vnc server would listen on port 5903.

For multiple vnc instances /etc/sysconfig/vncservers would look like this:

VNCSERVERS="1:tiger 2:albatros 3:leopard"
VNCSERVERARGS[1]="-geometry 1024x768 -depth 16"
VNCSERVERARGS[2]="-geometry 800x600 -depth 8"
VNCSERVERARGS[3]="-geometry 1024x768 -depth 16"

These would listen on ports 5901, 5902, 5903 respectively.

User Configuration

There is one more thing that needs to be done on the remote machine. User leopard’s vnc password needs to be set. So, as user leopard give the command:

# vncpasswd

We are prompted for a password. This is the password that we will use when we connect to leopard’s vnc server instance. This password is saved in /home/leopard/.vnc/passwd.

Start the VNC server

After the initial configuration is done we restart the vnc service. As root:

# service vncserver restart

To make VNC server to start on boot:

# chkconfig vncserver on

More User Configuration

After the VNC service is started, some new files are created in /home/leopard/.vnc/ directory. These include leopard’s vnc server log file, pid file and an X startup script. As user leopard we edit the script in order to customize some settings. The default /home/leopard/.vnc/xstartup script contains some commands that are executed when the VNC server is started. These include:

xsetroot -solid grey
vncconfig -iconic &
xterm -geometry 80x24+10+10 -ls -title "$VNCDESKTOP Desktop" &
twm &

xsetroot in this case sets the background color.
vncconfig is a supplementary program that can be used to control the vnc server. Apart from this, when run without arguments it acts as a helper application and its main purpose is to provide support for clipboard transfers between the client (vncviewer) and the vnc server.
xterm starts an xterm terminal.
twm starts the X server’s default window manager. We probably want to change that to a more user friendly window manager, eg fluxbox.

The VNC server, apart from letting us control a remote machine using a graphical interface, it serves as a way to start graphical applications on boot. For example, I want my favourite p2p program, amule, to start on boot. So, I add this to the /home/leopard/.vnc/xstartup script. This is how my xstartup file looks like:

xsetroot -solid grey
vncconfig -iconic &
xterm -geometry 80x24+10+10 -ls -title "$VNCDESKTOP Desktop" -e ./menu &
amule &
fluxbox & 

menu is a script of mine that is executed when xterm is started.
Remember to put the "&" symbol after each command, so that it goes to the background and the xstartup script continues on.

Restart the VNC service for the changes to take effect. As root:

# service vncserver restart

Connect to the VNC server

In our example, leopard’s vnc server listens for connections on port 5903. So, open this port in the remote machine’s firewall.

We connect to the remote machine using a vnc viewer. Having installed the vnc package, connect to to the server with the following command:

# vncviewer 192.168.0.1:5903:3

The general usage is :

vncviewer [Server's IP]:[Port]:[Display]

We are prompted for the password and eventually connect to the server. Closing the vncviewer’s window, does not affect the server or the programs we run on it. If we reconnect everything will be there.

Special Note: There is no need, actually it’s pointless and could give you some trouble, to logoff from your remote X session. If this happens, generally you need to restart the VNC service on the remote machine to get your remote desktop back. If you want to stop working on your remote desktop, just close the vncviewer’s window and you are done.

Security

The VNC protocol is not a secure communication protocol. The use of a vnc password provides security at the level of server access (it’s vulnerable to brute-force attacks though), but the whole VNC session is transmitted in the clear, without encryption. The easiest, but most effective, way to secure our connection to the VNC server is to connect through an encrypted SSH tunnel. This way the whole session will be encrypted.

The rest assume that you have the SSH server up and running on your remote machine (server.example.com) and you know what SSH tunnels are.

So, what we are going to do is to create an encrypted tunnel, and connect to our VNC server through it. We also want this tunnel to be automatically closed as soon as we shut down vncviewer. All this is done with the following command:

# ssh -f -L 25903:127.0.0.1:5903 leopard@server.example.com sleep 10; vncviewer 127.0.0.1:25903:3

This is what it does:

• -L 25903:127.0.0.1:5903 forwards our local port 25903 to port 5903 on the remote machine. In other words, it creates the tunnel.
• -f forks the SSH session to the background, while sleep is being executed on the remote machine. This ssh option is needed because we want to execute the following command (vncviewer) in the same local machine’s terminal.
• vncviewer connects to the forwarded local port 25903 in order to connect to the VNC server through the encrypted tunnel.

The sleep command is of major importance in the above line as it keeps the encrypted tunnel open for 10 seconds. If no application uses it during this period of time, then it’s closed. Contrariwise, if an application uses it during the 10 sec period, then the tunnel remains open until this application is shut down. This way the tunnel is automatically closed at the time we close vncviewer’s window, without leaving any SSH processes running on our workstation. This is pure convenience! More information can be found at the Auto-closing SSH Tunnels article.

Using SSH tunnels to conect to your VNC server has two advantages:

1. The whole session is encrypted.
2. Keeping port 5903 open on your remote machine is no longer needed, since all take place through the SSH tunnel. So, noone will know that you run a VNC server on the remote machine.

Further Reading

I recommend that you read the man pages. Everything is in there:

# man vncserver
# man Xvnc
# man vncconfig
# man vncviewer
# man ssh

Related Articles

• SSH Tunnels Headaches
• Auto-closing SSH tunnels
• Setup the SSH server to use keys for authentication
• Netcat – a couple of useful examples
• Python SSH Server for UNIX Systems using Twisted.conch

An SSH server can be set up in various ways, but in this document I’ll describe how it can be configured to:

• only support connections through the 2nd version of the SSH protocol (SSH-2)
• use DSA keys for user authentication, without permitting authentication with passwords
• allow only a specific group of users to connect

The SSH-2 protocol, apart from many other useful features, provides stronger security than SSH-1. It’s a bit more cpu hungry than the latter, but this should not be a problem. Using the above configuration, someone must be extremely lucky to manage to break into our system.

But, let me say a few words about how the authentication is done. The user creates a keypair, which consists of a private key, that can be protected with a passphrase, and a public key. The public key is transfered to the server and the private key is kept in our workstation. We assume that the user has accounts in both the server machine and his workstation. Everytime he tries to connect to the server, the keys are validated and the user is granted access.

Prerequisites

A user account in the SSH server machine.

You need to install the following packages to the SSH server machine:

• openssh
• openssh-server

The client machines should have the following:

• openssh
• openssh-clients

First things first…

I assume that our server machine (server.example.com) is a headless one and that the SSH server is up and running with the default configuration. This permits users, including root, to login with their username/password combination. I also assume that we have already set up a user account on the server with the username "leopard". From a client machine (pc1.example.com) we connect like this:

# ssh leopard@server.example.com

Keypair generation

The default key directory is "~/.ssh". Create this directory in both the user leopard’s home on the server and in your current home directory on the client machine and chmod it so that only the users have access to it.

# mkdir ~/.ssh
# chmod 0700 ~/.ssh

Now, we will create our keypair on our client machine. The following command creates a standard 1024-bit DSA keypair:

# ssh-keygen -t dsa -f ~/.ssh/id_dsa

You will be asked for a passphrase for the private key. You can type any phrase here or leave it blank. Keep in mind that if you do not set a passphrase for you private key and someone else gets access to it, then it will take him only a few seconds to connect to your user account on the server. Anyway, this is up to you. After the key generation is finished, the files id_dsa (private key) and id_dsa.pub (public key) are created in the ~/.ssh/ directory.

Now, we will copy the public key to the /home/leopard/.ssh/ directory on the server saving it with the name authorized_keys and delete id_dsa.pub from our client machine, just because it’s not needed to be there.

# scp ~/.ssh/id_dsa.pub leopard@server.example.com:~/.ssh/authorized_keys
# rm -f ~/.ssh/id_dsa.pub

Make sure that you chmod both keys so that only the respective users have access to them. Issue the following command on both the server and the client machine:

# chmod 0600 ~/.ssh/*

A limited group of SSH users

As an extra security measure, we will create a new group on the server machine and configure the SSH server to only allow this group’s members to authenticate. So, we create a group named "sshusers" and add user "leopard" to it. This has to be done as root:

# groupadd sshusers
# usermod -a -G sshusers leopard

The SSH Server configuration

The SSH server’s configuration file is /etc/ssh/sshd_config. Most of the default options do not need to be modified. What we’ll do is to set it up so that only the members of the "sshusers" group can authenticate using keys instead of passwords. So, as root, fire up your favourite text editor and edit the server configuration file.
NOTE: It’s a good habit to create backups before editing system files.
The options that need to be modified are shown below:

Port 22
Protocol 2
AddressFamily inet
ListenAddress 192.168.0.1

With these we configure the server to listen on port 22, accept connections only over the SSH-2 protocol, use the IPv4 address family and bind on the 192.168.0.1 IP address. Only the "protocol" option is really critical. You can set the others as you like or leave the defaults.

HostKey /etc/ssh/ssh_host_dsa_key

Uncomment or add this line. This is exactly the same as the default option, but needs to be uncommented in the server configuration file, so that the server shows its DSA key’s fingerprint when the client tries to authenticate the server during the connection process. If this is not set, then the server shows its RSA key’s fingerprint (the reason is unknown to me).

LoginGraceTime 2m
PermitRootLogin no
MaxAuthTries 1

The LoginGraceTime option sets a time limit for the user authentication process. If this time passes and the user has not yet authenticated succesfully, then the server closes the connection. Leave this value to the default "2m" until everything is set up properly, so that you have enough time to read any server messages. After that, you can lower it to a reasonable value. I have set it to "20s".
Setting the "PermitRootLogin" option to "no" the server does not allow root to login directly. You can still use "su" after you have succesfully logged in as a normal user.
The "MaxAuthTries" option sets the maximum login attempts per connection. Since we use keys and key validation never fails, we set it to "1".

PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys

These are the default options. I just add them here so that you make sure they are set up properly in your config.

RSAAuthentication no
PasswordAuthentication no
UsePAM no
KerberosAuthentication no
GSSAPIAuthentication no

We do not want the server to let users authenticate using passwords or use SSH-1 based authentication methods. You should comment out any Kerberos or GSSAPI options too.

AllowGroups sshusers

Only users that belong to the "sshusers" group can authenticate. Any other user will be rejected without even being given the oportunity to authenticate.

MaxStartups 2

This option specifies the maximum number of concurrent unauthenticated connections to the SSH Server. It has nothing to do with the number of authenticated connections. The default value is "10". We lower this value in order to limit the connections from third parties which do not have an account on our server machine.

Banner /etc/ssh/banner

Finaly, you can set a text file that will be displayed as a banner when someone connects to the server. Just remember that it is displayed before the authentication takes place, so do not be very descriptive. The banner is not really needed.

This is all we have to do. The rest of the configuration options should be left to their default values, unless you need something different. This is up to you.

Restarting the server

Now, that we have finished editing the config file, we need to restart the server, so that our changes take effect. Before that, I would recommend deleting any existing server keys. Don’t worry, they will be recreated as soon as the service is restarted. A quick way to delete all the keys is to:

# rm -f ssh_host*key*

Then restart the server:

# service sshd restart

Note that the key creation time may vary from machine to machine, so it may take a few minutes if the CPU is slow.

The server logging is done through syslog and authentication information is sent to /var/log/secure. This file should not be world-readable.

A last thing is to take a note of the server’s DSA public key fingerprint, so that we can compare it with the fingerprint the server sends to our client when we connect. This is important for connections to the server from locations other than our LAN in order to be sure that we actually connect to our server. On the server console type:

# ssh-keygen -l -f /etc/ssh/ssh_host_dsa_key.pub

Take a note of the fingerprint.

Connect to the server

To connect to our SSH server from our client machine (pc1.example.com), we type:

# ssh leopard@server.example.com

I suggest that the first time you connect you should add the -v option to the above command for verbose output.

Before the user authentication takes place, the ssh client will try to authenticate the SSH server. Since, there is no stored information about your server it will present you the server’s public DSA key fingerprint so you can compare it with the fingerprint you had previously taken a note of during the server configuration. If the fingerprints are identical, you can answer positively to the question. At this time the file ~/.ssh/known_hosts is created on your client machine and it contains the trusted SSH server’s information. You will never be asked again if you trust this server. If the fingerprint comparison took you longer than the server’s LoginGraceTime, the user authentication does not take place. Just try to reconnect. This time you will eventually log in succesfully using key authentication.

Hashing the known_hosts file

Because the servers’ hostnames and addresses are stored in plain text in the known_hosts file, hashing it is a good habit. This can be done using the ssh-keygen utility. Type:

# ssh-keygen -H -f ~/.ssh/known_hosts

This process makes it unreadable, but the ssh programs can still read the contents. Make sure you permanently delete the known_hosts.old backup file.

Change your private key’s passphrase

If you ever need to change the private key’s passphrase you can use ssh-keygen:

# ssh-keygen -p -f ~/.ssh/id_dsa

The ssh-agent

Although key authentication has many advantages over the authentication with passwords, it has one significant drawback: we have to type the passphrase every time we make a connection to the SSH server. One solution would be not to use a passphrase for our private key. But, this is unacceptable. If someone else gets access to our key and finds out to which servers we connect, things get really bad. A second solution is to use the ssh-agent (part of the openssh package) which caches our passphrase in the memory and then it’s automatically used when we make the connection to the SSH server. This way, we only need to type the passphrase once. This is by far more secure than not using a passphrase.

The ssh-agent is a small daemon that runs in the background. When it is run, it exports some environment variables (SSH_AUTH_SOCK, SSH_AGENT_PID) which can be used by programs like ssh-add in order to manage the agent’s cached info or by other programs like the ssh client in order to use this cached info for user authentication. These environment variables must be available to these programs, so the ssh-agent needs to be started in our login shell. There are many different ways to start the agent. Here I’ll describe a rather simple, but very efficient one.

The ssh-agent’s configuration

What we need is to start the agent when we login to our client machine’s shell and stop it when we log out. So, we add the following line to ~/.bash_profile:

eval `ssh-agent`

Why do we use eval? When the ssh-agent is started, it just prints some commands to the stdout. These commands set and export the environment variables we talked about earlier. We use eval, so that these commands are actually executed, or better, evaluated by the shell, so the environment variables are made available to all applications that can use them.

We add the following line to ~/.bash_logout

eval `ssh-agent -k`

This "unsets" the environment variables and kills the agent every time we logout.

Management of cached passphrases

A small utility called ssh-add is used to manage the cached passphrases.

To add a key to the ssh-agent’s cache, we issue the command:

# ssh-add ~/.ssh/id_dsa

We are prompted for the passphrase. After typing it succesfully, it gets cached. From now on, the cached passphrase will be automatically used for every connection we make to the SSH server. Convenient!
If we store our key to the standard location ~/.ssh/ and name it with the standard filename id_dsa, then ssh-add can be run without arguments. Our key will be used.

To list the cached keys we type:

# ssh-add -l

To remove a cached key:

# ssh-add -d ~/.ssh/id_dsa

To empty the ssh-agent’s cache:

# ssh-add -D

Further Reading

There are numerous articles around the web about SSH. Just use google. Keep in mind though that all the necessary info is in the man pages. You should not just read them, but rather study them:

1. The official openssh manuals
2. The openssh FAQ

This article appeared in the digg.com homepage on November 16th, 2005. I thank all “diggers” by heart.

Related Articles

• Set up the VNC Server in Fedora
• Be your own Certificate Authority (CA)
• Auto-closing SSH tunnels
• Python SSH Server for UNIX Systems using Twisted.conch
• Netcat – a couple of useful examples

• create the SSH tunnel (local port forwarding)
• execute vncviewer on the local machine
• have the SSH tunnel to be automatically closed at the time vncviewer was closed

After about one hour of trial and error and man page reading, I ended up with a very useful line of code:

ssh -f -L 25930:127.0.0.1:5904 -C me@remote sleep 10; vncviewer 127.0.0.1:25930:4

What this does is:

• forwards local port 25930 to remote port 5904
• forks the ssh session to the background executing a sleep command on the remote machine
• executes vncviewer so that it connects to the vnc server through the tunnel

What I badly needed was a way to auto-close the tunnel at the time vncviewer was closed. This seems to do it. The sleep command keeps the tunnel open for ten seconds. After this period of time it’s closed, unless vncviewer or some other application uses it. In this case, it is closed at the time this application stops using it. Pretty fu..ing cool!! I have wasted all my head’s juice until I managed to figure this out…

Related Articles

• Auto-closing SSH tunnels
• Set up the VNC Server in Fedora
• Netcat – a couple of useful examples
• Setup the SSH server to use keys for authentication
• Linux Tips – Pack I