SSH keygen under Cygwin

You will need to install the "openssh" package using the Cygwin installer before doing this.

Notes:

• In the near future, OpenSSH is deprecating support for DSA keys.
• Minimum supported RSA key size will be 1024 bits, but you should really do 2048 or larger.

Typical steps for creating SSH keys:

$ mkdir ~/.ssh

$ chmod 700 ~/.ssh

$ cd ~/.ssh

$ ssh-keygen.exe -t rsa -b 3200 -C 'Borg backup key thomast61p July 2015' -N '' -f ~/.ssh/ssh-borg-backup-july2015

In this particular case, I am creating a RSA/3200 key with no password (-N '') and with a comment indicating that it will only be used for Borg backups.  Because the key has no password, I should only use it in conjunction with the borg backup command on a separate server-side account that has very limited permissions on the server.

Checking authorized_keys for duplicate SSH key lines

After a while, unless you are using Puppet or some other tool, your ~/.ssh/authorized_key file will end up with half a dozen or dozens of different SSH public key lines.  And depending on how careful you were, some of them may be duplicates or screwed up.

One way to make sense of the madness is to look at the first N bytes of each line in the ~/.ssh/authorized_keys file and look for strangeness.

$ cut --bytes=1-80 ~/.ssh/authorized_keys 
ssh-dss AAAAB3NzaC1kc3MAAACBAP0090dCcnFwtuP9Rmjgf7eHR20JdmHASXS+un4cAKNYpwHIDlA9
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC54VI+7J1DoEEiJml8JusdM4M9UNNIA8gv/JER7rQ7
qDkz/87jwJ0jufKy7XQyiiwHGg7GvqMej8enLCN90wc4xOTrFUO9FaSinWGOJmtdjVH8m7oXZ+OfClOX
h1o14nqandnzYPNyOH7iHZyVcAl082Ua1nmsesrAj7ilNPLZFiQhGhPAbWPz/O9dVBvfW+I5stRgb7FD
014

ssh-rsa AAAAB3NzaC1yc2EAAAABJQAAAZB+mI3xeVeYo3B2yJqvQYUpVBrNtMmtd3iAj6O6pMIvRGzm

ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAsrOtkkIXu0ci/8h79/zCFgAoDZgw6yQExBs4o/KjfmB/

Just by looking at the above output, I can see that the second ssh-rsa key line was not placed on a single line as it should have been, but has line breaks.  After a quick edit of the file, now the output looks like:

$ cut --bytes=1-80 ~/.ssh/authorized_keys
ssh-dss AAAAB3NzaC1kc3MAAACBAP0090dCcnFwtuP9Rmjgf7eHR20JdmHASXS+un4cAKNYpwHIDlA9
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC54VI+7J1DoEEiJml8JusdM4M9UNNIA8gv/JER7rQ7

ssh-rsa AAAAB3NzaC1yc2EAAAABJQAAAZB+mI3xeVeYo3B2yJqvQYUpVBrNtMmtd3iAj6O6pMIvRGzm

ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAsrOtkkIXu0ci/8h79/zCFgAoDZgw6yQExBs4o/KjfmB/

Now I can run the output of that through sort/uniq to see whether I have any duplicate SSH public key lines:

$ cut --bytes=1-80 ~/.ssh/authorized_keys | sort | uniq -c -d
      5 
      2 ssh-rsa AAAAB3NzaC1yc2EAAAABJQAAAZB+mI3xeVeYo3B2yJqvQYUpVBrNtMmtd3iAj6O6pMIvRGzm
      2 ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC54VI+7J1DoEEiJml8JusdM4M9UNNIA8gv/JER7rQ7

Looks like I do have a pair of duplicated SSH public key lines.  This is a good thing to know because if was trying to remove a particular SSH key pair, I might remove one line but not see the other.

View and changing the SSH HostKey files

With all of the NSA leaks in the past few months, I figured it was a good time to go look at the SSH keys that we use on the servers and decide whether we want to re-key things. Naturally, this is a bit of a PITA because you'll have to let all clients know that the SSH host key changed and users will have to edit their ~/.ssh/known_hosts file.

First off, let's look at the current key information (using the "-l" option to display the signature, and the "-f filename" option to look at an existing file):

# /usr/bin/ssh-keygen -l -f /etc/ssh/ssh_host_dsa_key
1024 86:72:0c:d8:47:ce:c4:4a:79:25:9b:ad:22:1b:de:87 /etc/ssh/ssh_host_dsa_key.pub (DSA)
# /usr/bin/ssh-keygen -l -f /etc/ssh/ssh_host_rsa_key 
3072 2b:3d:27:77:49:bf:05:09:ee:b7:74:68:e8:f3:fc:3f /etc/ssh/ssh_host_rsa_key.pub (RSA)

This displays a few useful pieces of information:

#1 - The key size is 1024 for the DSA key. All DSA keys are 1024 bits in size due to FIPS 186-2 (Federal Information Processing Standard 186-2). While there is a newer FIPS 186-3 and FIPS 186-4 standard that allows larger DSA keys, I'm not sure how well supported it is in OpenSSH.

My RSA key is 3072 bits in size instead of the default 2048 bits in CentOS 6. Older releases had a default of only RSA/1024 bits, which is considered to be a bit weak today. The current recommended minimum is 2048 bits and the maximum in common use is 4096 bits.

A good read is Anatomy of a change - Google announces it will double its SSL key sizes.

#2 - The key signature, which should be communicated to your users via out-of-band communications.

To re-key, I suggest using the following for DSA keys:

# /usr/bin/ssh-keygen -N '' -C 'servername SSH host key Sep 2013' -t dsa -f /etc/ssh/ssh_host_dsa_key
Generating public/private dsa key pair.
/etc/ssh/ssh_host_dsa_key already exists.
Overwrite (y/n)? y
Your identification has been saved in /etc/ssh/ssh_host_dsa_key.
Your public key has been saved in /etc/ssh/ssh_host_dsa_key.pub.
The key fingerprint is:
86:72:0c:d8:47:ce:c4:4a:79:25:9b:ad:22:1b:de:87 severname SSH host key Sep 2013

For RSA keys, you need to change "-t dsa" to "-t rsa", change the filename, and add a "-b 2048" option before the "-f filename" option. Suggested key sizes are 2048 for short-term, 3172 for 1-2 decades, and 4096 for keys that will be in use past 2030. The downside is that as key length doubles, performance drops by a factor of 6-7x.

Setting up NX Client access to Linux servers running FreeNX/NX

In order to talk to a Linux box running FreeNX/NX server...

1) Grab a copy of the NX client from NoMachine's download page. For Windows users, look for "NX Client for Windows".

2) Install the client software.

3) Start up "NX Client for Windows".

4) The "Login" field will be your username on the Linux server (i.e. "thomas"). The "Password" field is obviously, your login password on the Linux server. In the "Session" field, enter a descriptive name of the server that you are trying to connect to. (This name does not have to reflect the server's DNS name, IP address and can be any name or nickname.)

5) As you press [Tab] to leave the "Session" field, you will be prompted whether you want to "Create" a new session or "Rename" the existing session. In most cases, you'll want to pick "Create" so that you can setup a new session.

6) You will now be taken to the advanced configuration screen.

a) Server Host: Enter the fully qualified DNS name, or the IP address.
b) Server Port: Most servers run SSH on port 22.
c) Desktop: I usually use "Unix / Gnome"
d) Speed: ISDN or ADSL is a good first choice
e) Display: Choose full-screen or setup a window of any size that you want.

7) Before you click "Save" or "OK", check with your server administrator and find out whether you need to provide the NX client with a custom key. This key is located on the Linux server and is usually at the following location:

/etc/nxserver/client.id_dsa.key

If you need this key, be sure to obtain it, then use the "Server, Key" button on the advanced configuration screen. Just paste the key in to the provided box and you'll be able to talk to the server.

8) Click "Save" then "OK".

9) If everything is configured properly, you can now enter your login password and press the "Login" button to access the remote server.

...

When you are finished with your session on the remote server, you can either "Terminate" (logout) or "Suspend" it if you want to leave things running for later.

Setting up FreeNX/NX on CentOS 5

Quick guide to setting up FreeNX/NX. This the approximate minimums on a fresh CentOS 5.1 box. We're limiting things to using public-key authentication from the outside and we already have a second ssh daemon running (listening on localhost, allowing password authentication).

Note: If you have ATRPMs configured as a repository, make sure that you exclude nx* and freenx*. (Add/edit the exclude= line in the ATRPMs .repo file.)

# yum install nx freenx
# cp /etc/nxserver/node.conf.sample /etc/nxserver/node.conf
# vi /etc/nxserver/node.conf

Change the following lines in the node.conf file:

ENABLE_SSH_AUTHENTICATION="1"
-- remove the '#' at the start of the line

ENABLE_SU_AUTHENTICATION="1"
-- remove the '#' at the start of the line
-- change the zero to a one

ENABLE_FORCE_ENCRYPTION="1"
-- remove the '#' at the start of the line
-- change the zero to a one

Change the server's public/private key pair:

# mv /etc/nxserver/client.id_dsa.key /etc/nxserver/client.id_dsa.key.OLD
# mv /etc/nxserver/server.id_dsa.pub.key /etc/nxserver/server.id_dsa.pub.key.OLD
# ssh-keygen -t dsa -N '' -f /etc/nxserver/client.id_dsa.key
# mv /etc/nxserver/client.id_dsa.key.pub /etc/nxserver/server.id_dsa.pub.key
# cat /etc/nxserver/client.id_dsa.key

You'll need to give the DSA Private Key information to people who should be allowed to use FreeNX/NX to access the server.

You'll also need to put the new public key into the authorized_keys2 file:

# cat /etc/nxserver/server.id_dsa.pub.key >> /var/lib/nxserver/home/.ssh/authorized_keys2

# vi /var/lib/nxserver/home/.ssh/authorized_keys2

Comment out the old key, put the following at the start of the good key line.

no-port-forwarding,no-X11-forwarding,no-agent-forwarding,command="/usr/bin/nxserver"

Restart the FreeNX/NX service:

# service freenx-server restart

You should now be able to connect (assuming that you specify the proper SSH port and paste the private key into the configuration).

Setup sshd to run a second instance

In order to lock down the servers like I prefer to, yet still allow FreeNX/NX to work, I have to setup a second copy of the sshd daemon. The FreeNX/NX client requires that you have sshd running with password access (not just public key), but we prefer to only allow public-key access to our servers.

I did the following on CentOS 5, it should also work for Fedora or Red Hat Enterprise Linux (RHEL). But proceed at your own risk.

1) Create a hard link to the sshd program. This allows us to distinguish it in the process list. It also makes sure that our cloned copy stays up to date as the sshd program is patched.

# ln /usr/sbin/sshd /usr/sbin/sshd_nx

2) Copy /etc/init.d/sshd to a new name

This is the startup / shutdown script for the base sshd daemon. Make a copy of this script:

# cp -p /etc/init.d/sshd /etc/init.d/sshd_nx
# vi /etc/init.d/sshd_nx

Change the following lines:

# processname: sshd_nx
# config: /etc/ssh/sshd_nx_config
# pidfile: /var/run/sshd_nx.pid
prog="sshd_nx"
SSHD=/usr/sbin/sshd_nx
PID_FILE=/var/run/sshd_nx.pid
OPTIONS="-f /etc/ssh/sshd_nx_config -o PidFile=${PID_FILE} ${OPTIONS}"
[ "$RETVAL" = 0 ] && touch /var/lock/subsys/sshd_nx
[ "$RETVAL" = 0 ] && rm -f /var/lock/subsys/sshd_nx
if [ -f /var/lock/subsys/sshd_nx ] ; then

Note: The OPTIONS= line is probably new and will have to be added right after the PID_FILE= line in the file. There are also multiple lines that reference /var/lock/subsys/sshd, you will need to change all of them.

3) Copy the old sshd configuration file.

# cp -p /etc/ssh/sshd_config /etc/ssh/sshd_nx_config

4) Edit the new sshd configuration file and make sure that it uses a different port number.

Port 28822

5) Clone the PAM configuration file.

# cp -p /etc/pam.d/sshd /etc/pam.d/sshd_nx

6) Set the new service to startup automatically.

# chkconfig --add sshd_nx

...

Test it out

# service sshd_nx start
# ssh -p 28222 username@localhost

Check for errors in the log file:

# tail -n 25 /var/log/secure

...

At this point, I would go back and change the secondary configuration to only listen on the localhost ports:

ListenAddress 127.0.0.1
ListenAddress ::1

...

References:

How to Add a New "sshd_adm" Service on Red Hat Advanced Server 2.1

How to install NX server and client under Ubuntu/Kubuntu Linux (revised)

...

Follow-on notes:

This setup is specifically for cases where you do not want to allow password access to the server from outside. The way that the NXClient authenticates is basically:

1) NXClient uses a SSH public key pair to authenticate with the server

2) It then logs into the server using the supplied username/password via SSH.

So by setting things up this way, we keep public-key authentication as the only way to login to the server - but the NX server daemon is able to cross-connect to a localhost-only SSH daemon.

Setting up svn+ssh on an alternate point for TortoiseSVN

This builds off a post to the TortoiseSVN user list: Specifying custom port for svn+ssh: a workaround

1. Right-click on the Pageant icon in the system tray (I'm assuming that you're loading the SSH public key that you use for SVN into Pageant).
   
2. Choose "New Session"
   
3. Enter the hostname / IP address and SSH port that you'll be connecting to. If you're going to connect as "svn+ssh://thomas@svn.tgharold.com:2222", then this would be "svn.tgharold.com" and "2222".
   
4. Go back to the "Session" tab and name the session as "svn.tgharold.com:2222".
   

Now you will be able to use both TortoiseSVN and the command-line version of SVN to talk to your repository over the alternate SSH port.

Why do this?

This is useful for cases where you want to put a SVN server on a publicly accessible IP address. What you will find is that if you leave SSH running on the default port, you will be inviting attacks on your SSH server. On the other hand, if you put the SSH server on an alternate port, you'll find that it gets attacked a lot less often (1-2 orders of magnitude difference would be likely).

Since mid-Oct of last year (around 8.5 months), we've logged 90,300 attack attempts against our SSH server. Usually they come in batches of attempting to guess accounts that normally exist or by attacking a list of common usernames. Since we don't allow root login, we don't allow password authentication, we only allow public key authentication and our SSH keys are limited to running "svnserve -t", we have yet to see a break-in attempt succeed.

Remote GUI administration of CentOS5 using Windows

Over the years, I've become very spoiled by Windows Terminal Services that we use to administer our Windows 2000 and Windows 2003 servers. It's fast, it's slick, it allows copy-paste and with a bit of command line fu you can connect to the physical display (instead of one of the two virtual sessions). It also uses built-in Windows authentication and offers encryption.

So, now that I'm rolling out CentOS 5 servers - I need something similar that allows me to look at the graphical UI on the box from elsewhere. From what I can tell, my options are:

KVM that supports TCP/IP

Probably one of the holy grails of remote administration. It allows you to see everything from the BIOS setup screen onward without needing to be physically at the machine. The downside is cost. So while I will eventually be hooking one of these up, it's not in the budget for this quarter.

VNC over SSH

I have a love/hate relationship with VNC. On the Windows clients, we use UltraVNC with built-in Windows authentication and the AES encryption plug-in.

But if you want to wrap VNC with SSH, you have to configure port forwarding all the time in PuTTY. Which turns connecting to a remote server into a multi-step process. With Windows' RDP, I just say "connect to IP address X" and I'm done (and I can connect in as anyone that I want). For PuTTY+VNC, I have to jump through a lot more hoops.

There's also the (possible) issue that VNC is nowhere as efficient over the network as RDP. Once you use Terminal Services' RDP, you'll be spoiled and never want to use older technologies. It (almost) never glitches, it's lightning fast and responsive, and it's just pure remote GUI goodness (except for being a MS-only protocol).

X11 over SSH

This is where I'm heading at the moment. It uses SSH for authentication, so we can lock things down that way (forcing the use of public keys).

Now, a word of caution. A misconfigured SSH or X11 server is a security breach waiting to happen. Pay close attention to chapter 9 in SSH, The Secure Shell, The Definitive Guide by Barrett, Silverman & Byrnes (published by O'Reilly).

Installing Xming on Windows

In order to do X11 on Microsoft Windows, you need to install "X Server" software on the Windows box. While there are pay options out there, I'd suggest starting with Xming which is free (GPLv2). You'll want to download and install both Xming and Xming-fonts.

Configuration of sshd and X11

In order for the local X Server (Xming - running on your Windows system) to talk to the remote Linux server, you'll need to verify some settings on the Linux server. First up is configuration of the sshd daemon (typically /etc/ssh/sshd_config for OpenSSH). Look for the following 2 lines and make sure they are configured correctly:

X11Forwarding yes
#X11UseLocalhost yes

By default, OpenSSH ships with X11Forwarding set to "no" but the default for X11UseLocalhost is "yes". So you should only have to add the "X11Forwarding yes" line.

Create a PuTTY session

I'll make the assumption that you're going to use a PuTTY public-key pair. If you need to install a generated PuTTY key (maybe you want to use a separate PuTTY key for X11 forwarding), then here are the directions for OpenSSH.

(login as yourself or as root and then "su" to your username)
# cd ~/.ssh
# cat > machinename@svn.pub
(paste in PuTTY key)
# ssh-keygen -i -f machinename@svn.pub >> authorized_keys
(Ctrl-D to exit)

1. Right-click on the Pageant icon in the system tray and choose "New Session".
   
2. Enter the hostname (i.e. 192.168.1.1)
   
3. Go to the Connection -> SSH -> X11 tab
   
4. Turn ON "X11 forwarding"
   
5. Display location should be: localhost:0
   
6. Go back to the Session tab
   
7. Enter a name in the Saved Sessions text box (i.e. "MyHost-X11") and click on "Save"
   
8. Click the "Open" button to connect to the server
   

If all goes well, you should see a line like:

/usr/bin/xauth: creating new authority file /home/thomas/.Xauthority

Which tells us that SSH is ready to do some X forwarding.

Fire up Xming

If you haven't already ran Xming you should run XLaunch and just roll through the defaults. Now, in the PuTTY window that is sitting at a command prompt, try:

# xeyes

And you should see the xeyes application open up on your Windows system. If you want to continue to start up other X applications, put an ampersand (&) at the end of the line.

More advanced stuff

1. Fire up XLaunch
   
2. Select "One window" and click "Next"
   
3. Select "Start a program" and click "Next"
   
4. The start program should be either "gnome-session" or "startkde"
   
5. Select Run Remote using PuTTY (plink.exe) and turn on the compression option.
   
6. Enter the IP address or hostname in "Connect to computer" of the Linux box that you are connecting to
   
7. Enter your username in the "Login as user"
   
8. Click the "Next" button
   
9. In the "Additional parameters", enter "-screen 0 1024 768" which will set screen zero to be 1024x768
   
10. If you run your SSH server on a non-standard port, enter "-P port" in the PuTTY extra options field (run "plink" at a Windows command prompt to see the possible options)
    
11. Save your configuration file and click "Finish"
    

If all goes well, you should see the Gnome desktop!

Final thoughts (for the moment)

Now, it's still not as slick as Terminal Services. But it seems to work just fine and gives me a GUI desktop. I still plan on doing most of my administration from the command line, but this provides a nice GUI for those who follow in my footsteps.

Forcing users to use public SSH keys to authenticate

Here are the steps I use when I create a new user account on a secure SSH server (where only public keys are allowed).

# useradd -m username
# passwd username
(paste in a super-long randomized password)
# cd /home/username
# su username
$ mkdir .ssh
$ chmod 700 .ssh
$ cd .ssh
$ cat > username@linux.pub
(paste in the public key file from SecureCRT)
$ ssh-keygen -i -f username@linux.pub >> authorized_keys
$ chmod 600 *

At this point, the user should be able to login via SecureCRT using their private/public key pair. There's no need for them to know the password that you assigned to them on the server (so use something random and at least 30+ characters).

SSH authorized_keys (creating pub keys using SecureCRT)

For optimal security, it's better to require public keys for logging into a server rather then allowing password authentication. As long as the user's keep their SSH private key files safe (along with protecting them with a decent passphrase), you're less likely to encounter a break-in of your Unix/Linux servers.

The process is similar for PuTTY, but SecureCRT offers a much cleaner interface then PuTTY. Because of the way things work in SSH2-land, you typically create the SSH2 keys using the client software in Windows, then copy the public key up to your user directory on the server that it will be used for. (Or you have an admin install the public key for you.)

Note #1: One advantage of public keys is that SecureCRT runs a key-agent in the background. So for additional connections to the same server, you will not be re-prompted for a password. This will allow you somewhat seamless movement between the 4 Solaris servers.

Note #2: You can use a particular key file for multiple servers. You should do this as little as possible, because if an attacker swipes your private keyfile and passphrase, they can impersonate you on those servers. My recommendation for users is that they create a "super-secure" key and a "less-secure" key. The super-secure key should be used with critical servers and the less-secure key can be used for other servers.

Steps to create a public key pair in SecureCRT

1) Options -> Global Options -> SSH2.

Alternately, to create a session specific key (a better method).

a) Click on the Connect button, highlight the Session for which you want to create a session key and choose Properties.

b) Connection -> Authentication -> Primary -> PublicKey -> Properties

2) Under "Public Key", choose "Use Identify File". This file is the central storage location for all of your public/private SSH2 keys. It should be placed somewhere secure and backed up frequently. Your "My Documents" folder is probably a good place.

3) Click "Create Identify File"

4) Key type can be either RSA or DSA (doesn't matter except for older systems like Solaris).

5) The passphrase should be something you can remember. It will be used to encrypt your private key. The comment should probably be of the form "user@servername", although there are no strict requirements for what you place in the comment.

6) A key length of 1024 bits is fine. On more modern hardware, key length of 2048 bits can be used. DSA keys can only be 1024 bits. Given recent developments in the world of encryption, it may be better to use 2048 bit RSA keys.

7) Choose a directory for the private key. It should also be somewhere safe and part of your regular backups. A location like "C:\SSHKeys" or placing the key files in your "My Documents" folder, or somewhere under your user profile directories is best. For even more security, you may wish to place the key files on a removable USB key that you carry around.

8) Send the contents of the "something.pub" key to the server admin so that they can add it to the authorized key file on the servers. This will look something like:

---- BEGIN SSH2 PUBLIC KEY ----
Subject: Thomas
Comment: "Thomas@Solaris"
AAAAB3NzaC1kc3MAAACBALR3kfLsT5y1c84OCnaFqtp1+tB5QLMVcrY/6GuA7MXq0EP6
c47diCztdSzfvRgUV02uyC6LKKqypvwJeGvt987J1P7e1Mxo1jb5EEYoOyFuL683XK8u
NknA+Oj9l3cJeVhzGczwmTqf6hVCsRih8rxkwewkD4zNc60MeLveAqn9AAAAFQCPqhmR
ElRW4OaotTrU9Wf4JmQYYQAAAIEAsWeirEUPzurmsBzY4nEQ19bQQGuTedeps9EgzN6q
ocS4AEtyBotTMgMTlRIf/rrrRCt6W58fjrHIrMlgljBbopaPrHsdO0v9+iqNRkjAFCIE
kbhiTJHri81MNoQADj7gnN+jsOc0GfOIha+6p0ocnkU07v5HyvUH1C+qA+zvC0oAAACA
No2vpbOp/HpTeeq+guOccJaTmJy8WH7wAtBKewI3WCWSw8ygWtxkOrD9sdIreUeN58G5
eecdUWuxInAnMPmEn4f49sUAejO/0E7P8XKx1Mqx2CUYNOyoQ1EsX5lZXg6Hbx2Gc4BW
1uPFJw13j/9jAfQlRYzAqK80uS/cUwTaH9o=
---- END SSH2 PUBLIC KEY ----

9) Make a backup of your private key and public key files. One option would be to burn them to CD-R (multiple copies on the disk), write the passphrase on the CD-R, then put it all into a sealed envelope in a secure offsite location (safe-deposit box). Alternately, you may wish to simply print it out on paper and OCR it back if you lose the key files.

PuTTY and SubVersion on Windows 2003

One thing we use SubVersion for in the office is for tracking configuration changes to our Linux servers. Everything under /etc or any other file that we change by hand (or with configuration tools) gets put into SVN which tracks the changes. It's possible to do the same thing under Windows (although not everything can be tracked).

A) Install PuTTY on the Win2003 server

1. The usual defaults are fine (install to C:\Program Files\PuTTY)

2. Create a public key (RSA, 2048 bit, no passphrase) and save it somewhere on the Windows 2003 server hard drive. I'd recommend an easy-to-type location because you'll be referencing constantly in batch files.

Security implications:

- Make sure that the account on the SVN server is a limited account, maybe even with a restricted shell. Just in case the authorized_keys file restriction is ever removed by accident.

- Setting the authorized_keys file to only allow "svnserve -t" as a command will keep most attackers from gaining console access to the server. But you're relying on the security of the svnserver application to not have an buffer/overflow exploits that allow shell access.

- Our decision was that the public key on the Win2003 server did not need a passphrase. The risks are worth it in order to be able to script svn commands to shove log files across the wire to the central SVN server every hour.

3. Upload the public key to your SVN server, configure it in the authorized_keys file and restrict it to only allowing command="svnserve -t".

# su accountname
# cd /home/accountname
# mkdir .ssh
# chmod 700 .ssh
# cd .ssh
# cat > machinename@svn.pub
(paste in PuTTY key)
# ssh-keygen -i -f machinename@svn.pub >> authorized_keys
# vi authorized_keys
(add command="svnserve -t" to the front of the new key line)
# chmod 600 *

4. Fire up PuTTY and attempt to connect to your SVN server. That will cache the server's public key in PuTTY's records.

B) Install the SubVersion Win32 command-line client on the server.

1. Install SVN to the default location

2. Right-click on My Computer, Properties, Advanced, Environment Variables

3. Under System Variables, click "New":
Variable name: SVN_ASP_DOT_NET_HACK
Variable value (can be anything at all): _svn

4. Under System Variables, highlight "PATH" and click "Edit". Add ";C:\Program Files\PuTTY" to the end of the PATH statement (which assumes you installed PuTTY to that location)

5. Under User Variables, click "New":
Variable name: SVN_SSH
plink -ssh -l user -pw password
- "user" should be your username on the SVN server
- the "-pw password" is optional if you did not put a passphrase on your key

C) Add the base set of directories to the server.

1. Check connectivity to the SVN server

C:\ svn list svn+ssh://user@svn.example.com/var/svn/repos

(if that doesn't work, go back and verify SSH connectivity)

2. Create a "C" folder in the root of the repository to represent your "C" drive. I usually do it on another system in a temporary folder.

3. Do the default checkout to the root of C: and D:

C:\ svn co svn+ssh://user@svn.example.com/var/svn/repos/C .
D:\ svn co svn+ssh://user@svn.example.com/var/svn/repos/D .
(note the "." at the end of the command)

4. Start adding folders and files to the SVN repository.

C:\ svn add -N Data
C:\ svn add -N Data\Logs
C:\ svn ci -m "log folder"

Misc SSH as a VPN links

Just collecting some links that look interesting. My plan is to use SSH as a VPN server and I'll need to figure out how Mac and Windows clients can connect in.

Using a Linux L2TP/IPsec VPN server

arstechnica - teach me about ssh, vpn, allow remote connections

about.com - VPN Setup

Q&A on using the VPN service (www.doc.ic.ac.uk/csg/faqs/)

Gentoo Next Steps (ssh)

Setting up SSHD on Gentoo (which just covers the basics, also see the sshd manpage and OpenSSH.org).

I have a book called "Building Secure Servers with Linux", and it's extremely poor with regards to actually setting up the sshd system. (Specifically, it completely ignores the topic of how to create the public/private DSA key for the sshd process.) Googling around for how to create the ssh_host_dsa_key netted me a few useful articles.

NCSA OpenSSH Installation Guide
20020124: setting up sshd on Linux

The NCSA link is probably the most useful, except that on my gentoo linux system, configuration stuff is under /etc/ssh instead of /etc/openssh.

# /usr/bin/ssh-keygen -t dsa -b 1024 -f /etc/ssh/ssh_host_dsa_key -N ""
# chmod 600 /etc/ssh/ssh_host_dsa_key
# chmod 644 /etc/ssh/ssh_host_dsa_key.pub

(the two chmod commands weren't really necessary on my gentoo box, they had no effect on the permissions)

To add sshd so it runs at startup (I think the following is correct):
rc-update add sshd default

Now I can administer the box from the laptop (using SecureCRT software), getting it off of my desk and into the server rack where it belongs. Things to do include getting PostgreSQL up and running, Samba, backing up the system, setting up recurring backups and checkout SubVersion as a replacement for Visual SourceSafe / SourceOffSite.