Changing your SSH port and configuring SVN

A while ago I wrote an post on SSH. Yesterday I was discussing the brute force attacks you get and my conversation partner said that he now systematically configures SSH on another port and rarely sees any attacks.

Just for fun tonight I've switched my port 22 to another port and will monitor my logs to see if I get the same findings. What I actually did is alter the port forwarding scheme so that I keep the config of the server rather standard. I expect to see the same thing as my conversation partner.

After the change I had to figure out how this works out with SVN which I do with svn+ssh. Without the necessary modifications that fails of course since port 22 is not open anymore.

On the server side you don't have to change anything. On the client side there is in ~/.subversion/config in the section [tunnels] a line to add:
sshtunnel = ssh -p port_number -q

You can put in any name instead of sshtunnel but I personally like clear naming for when I am tired. The -q at the end is important otherwise you will get the message "Killed by signal 15."

A last hurdle was that I had already a number of check out projects and created a little problem. I simply renamed the directory, downloaded a new copy this time using
svn co svn+sshtunnel://server/path/dir dir

To merge the contents of both (the old one and the new one) without overwriting the new svn config it was simply
cp -R -n old_dir new_dir
rm -R -f old_dir

SSH fun - a poor man's VPN

Recently I saw an episode of HAK5 on SSH and using certificates to authenticate. I was thinking of implementing a VPN solution at home for when I am on the road but when I saw the show I liked the simplicity of it so I started and a couple of minutes of fun later I had an up and running poor man's VPN.

If you want a quick and easy solution to use an untrusted Internet connection, this might be a solution for you. Here is a description on how to implement it.

Setting up the server

Setting up your server can actually be any system that can run an openssh server. It can be a recent beefy thing but also an old desktop laying around. To install openssh server on a Ubuntu system, you do :

apt-get install openssh-server

Configure the firewall

Since we are about to hang this system to the Internet, a firewall is a must have. Ubuntu comes with ufw built in.

To configure the firewall for the openssh-server, you do:

ufw limit OpenSSH

To start the firewall run:

ufw enable

Configure your server

The configuration can be found in /etc/ssh/sshd_config. Change the following settings:

• PermitRootLogin no
• RSAAuthentication yes
• PasswordAuthentication no
• UsePAM no

SSH services connected to the Internet are constantly under attack. Since I want to use the attack data, I changed my log level to verbose.

Now that the server is configured, you got to restart the service. You do this with:

service ssh restart

Key generation

The basic idea is to create a key pair. One is a public key and will be installed on the server, the other one is your private key and is installed one the device you will connect with, your laptop or touchpad for example.

To generate the key you type on the laptop or touchpad:

ssh-keygen -t rsa

This will generate your generate your key pair. During the generation it will ask you where you want to store your keys and a password to protect it. The keys are by default stored in your home directory under the hidden directory ".ssh/". The private key is called id_rsa and the public key is called id_rsa.pub. Another important file in the ssh directory is called known_hosts. You will get more information on known_hosts later in this post.

Getting the public key on the server

To get the public key to the server there are a couple of possibilities. 

• the ssh-copy-id command
• copy text from id_rsa.pub to the server to the file authorized_keys in the hidden .ssh directory under your profile.

Since ssh-copy-id is not available on every platform in the world, my preference goes out to the second option.

It is always a good idea to have a copy of your private key id_rsa stored at a secure place if something goes wrong with your system.

Opening up the gates

When your internet provides you with a DHCP address you can configure your system to use a dynamic dns. If you got a static IP you don't need the dynamic dns, you just need to know your IP.

Configure your router so that you allow incoming traffic on port 22.

Connecting to your server

A regular SSH session

To build just a regular SSH session you type on the command line:

ssh account@server

Surfing/Skyping/... over SSH session

You can use the SSH session as a SOCKS5 proxy. To do this, you do:

ssh -D port account@server

Then you need to configure your browser so that it uses a local (localhost or 127.0.0.1) socks v5 proxy and of course the port you specified.

Logging

By default all logging will take place in /var/log/auth.log.

A regular connection looks like this:

timestamp server sshd[pid]: Connection from IP port port_number

timestamp server sshd[pid]: Found matching RSA key: key_in_hex

timestamp server sshd[pid]: Postponed publickey for user from IP port port_number ssh2 [preauth]

A disconnect looks like this:

timestamp server sshd[pid]: Received disconnect from IP ...

When somebody just does "ssh ip_address" it will show up like this: 

timestamp server sshd[pid]: Connection from IP port port_number

timestamp server sshd[pid]: Connection closed by IP [preauth]

Usually brute-force attacks are done like "ssh useraccount@IP" and since the attacker doesn't have the certificate it will show up like this:

timestamp server sshd[pid]: Connection from IP port port_number

timestamp server sshd[pid]: Invalid user useraccount from IP

timestamp server sshd[pid]: input_userauth_request: invalid user useraccount [preauth]

timestamp server sshd[pid]: Connection closed by IP [preauth]

Final thoughts on security considerations

If you want to slow down the attacks you can always implement a framework called Fail2Ban. This python framework reads out logs and uses iptables firewall to block brute-force attempts.