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.

Labels: PuTTY, SSH, SubVersion

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.

Labels: CentOS5, SSH, X11

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).

Labels: SecureCRT, SSH

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.

Labels: SecureCRT, SSH

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"

Labels: PuTTY, SSH, SubVersion, Win2003

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/)

Labels: SSH, VPN

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.

Labels: Gentoo, SSH