Setup a Cheap SSH Relay with Provision Host

Dedicated Hosting

Over the years I’ve had multiple dedicated hosts that I’ve used for security testing of clients. Since my current employer has a dedicated security lab, I no longer need that kind of horsepower. It’s still convenient, though, to have access to a host on the Internet for testing purposes.

On Demand Hosting

I signed up for Amazon’s free tier AWS, which met all of my requirements. Once the free ride was over, though, I ran into immediate problems. To keep costs down, I’d shut down my instance when not in use. Unfortunately, when restarted it would now have a different IP address and SSH fingerprint – not an optimal situation for AutoSSH on a pentest dropbox.

Virtual Private Server (OpenVZ)

All I currently require is an always-on connection for SSH relaying. The site LowEndBox specializes in identifying such resources (http://www.lowendbox.com/). There I found the following from Provision Host.

PHVPS.25 Plan
•    128MB RAM
•    256MB Burst RAM
•    5GB DiskSpace
•    500GB Bandwidth
•    1 IPv4 Address
•    OpenVZ/SolusVM
•    $13.33/Year
•    Order: Toronto – https://client.provisionhost.com/cart.php?a=add&pid=107
•    Order: Dallas – https://client.provisionhost.com/cart.php?a=add&pid=108

I signed up for the Dallas location at just before midnight local time. The OpenVZ container was provisioned in less than 15-minutes.

The “Welcome” e-mail includes the website login credentials that were provided during signup. So, I logged in to the account and changed my password. The new password was not re-e-mailed.

The “New VPS Server Information” e-mail includes the root login credentials provided during signup. So, I SSH’d in to the account and changed the root password. This can also be done through the website, but why would you?

Setup – Relay

Login to the relay server ‘ssh root@relay-server.fqdn’.

The provisioned container is not up-to-date, so run ‘yum –exclude=kernel* update’. I don’t know if it’s necessary to include the kernel exclusion, but my understanding is that all OpenVZ containers on a host use the same kernel version.

Create a non-root user ‘useradd relay-user’ and set password ‘passwd relay-user’.

For the truly paranoid you shouldn’t be using OpenVZ, but if you want to change the SSH private keys do it now ‘ssh-keygen -f /etc/ssh/ssh_host_key’ and restart ‘/etc/init.d/sshd restart’. If you forget to do the latter step, like I did, and aren’t able to login, just go to the website and click reboot.

You may have to delete the fingerprint from your ‘known_hosts’ file when reconnecting to the relay.

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
c3:6e:41:bd:7b:ca:7d:20:00:65:3a:f9:dc:da:fc:e5.
Please contact your system administrator.
Add correct host key in /home/x/.ssh/known_hosts to get rid of this message.
Offending RSA key in /home/x/.ssh/known_hosts:9
remove with: ssh-keygen -f “/home/x/.ssh/known_hosts” -R relay.domain.com
RSA host key for relay.domain.com has changed and you have requested strict checking.
Host key verification failed.

Now make the following recommended changes to ‘/etc/ssh/sshd_config’

PermitRootLogin no

Match User relay-user
AllowTcpForwarding yes
GatewayPorts yes

Restart ‘/etc/init.d/sshd restart’.

Setup – Server

Create a non-root user ‘useradd server-user’ and set password ‘passwd server-user’.

Login to the server as server-user.

Create SSH keys ‘ssh-keygen -t rsa’. The default location should be something like ‘/home/server-user/.ssh/’.

Copy the contents of the public key ‘id_rsa.pub’. This should start with ‘ssh-rsa’ and end with ‘server-user@server-hostname’.

Login to the relay server ‘ssh relay-user@relay-server-fqdn’ – this will add the relay-server fingerprint to your server-user’s ‘known_hosts’ file – then paste your server-user’s public key into the file ‘/home/relay-user/.ssh/authorized_keys’.

Logout and then log back in to the relay server. You should no longer be prompted for a password.

Note: Validate appropriate permissions on your server-user’s private key ‘id_rsa’, and relay-user’s ‘authorized_keys’. (chmod 600 filename)

Setup – Client

Create a non-root user ‘useradd client-user’ and set password ‘passwd client-user’.

Login to the client as client-user.

Create SSH keys ‘ssh-keygen -t rsa’. The default location should be something like ‘/home/client-user/.ssh/’.

Login to the relay server ‘ssh relay-user@relay-server-fqdn’ – this will add the relay-server fingerprint to your client-user’s ‘known_hosts’ file – then paste your client-user’s public key into the file ‘/home/relay-user/.ssh/authorized_keys’.

Logout and then log back in to the relay server. You should no longer be prompted for a password.

Note: Validate appropriate permissions on your client-user’s private key ‘id_rsa’, and relay-user’s ‘authorized_keys’. (chmod 600 filename)

Final Connection

Choose a relay port, e.g. 12345

Server: ‘ssh -N -R 12345:localhost:22 relay-user@relay-server-fqdn’

Client: ‘ssh server-user@ relay-server-fqdn -p 12345’

If you don’t want the client to be prompted for a password when logging in to the server then add the following:

Copy the contents of the client-user public key ‘id_rsa.pub’. This should start with ‘ssh-rsa’ and end with ‘client-user@client-hostname’. Paste the contents into the server’s ‘/home/server-user/.ssh/authorized_keys’.

Note: Validate appropriate permissions on your server-user’s ‘authorized_keys’. (chmod 600 filename)

Secure Relay

By default the web server on relay-server port 80 is accessible. Enter the following as root@relay-server.fqdn to disable it (because we previously disabled root logins, login as relay-user and then su).

iptables -A INPUT -p tcp –destination-port 80 -j DROP

service iptables save

The save will appear to fail, but should actually succeed. Reboot the server and the run ‘iptables -L’ port 80 should be blocked.

 

Leave a Reply

Your email address will not be published. Required fields are marked *