Thursday, 4 Dec, 2008

If you're keen on searching for the most secure SSH access method, then this post is not about it.

For everyday use, I've simply made the choice to stick to 4096 bit RSA keys + complex passhphrases (considered as secure and slightly paranoid nonetheless).

This post is about you having two Ubuntu boxes you'd like to SSH into (I am assuming SSH is installed and enabled on both your client and your server - "sudo apt-get install ssh" on both, just in case it isn't installed).

OpenSSH

OpenSSH

 

Normally, what you want to do is gain access to the server from a terminal launched on your client.

On the client's terminal type:

ssh-keygen -b 4096

Now, when asked, insert your desired passhphrase (use letters, numbers, and commas - just don't forget your passphrase!), then:

less .ssh/id_rsa.pub

Once you open id_rsa.pub with the "less" command, you may select (and therefore copy) the whole file's content.

 

Now, still on your client, open _another_ terminal window then SSH into your server (if it's Ubuntu, login with your ordinary user, ie. the one that you're going to authorize for the server access).

Opening another terminal window is recommended for ease of copy-paste.

So, on the secondary terminal window, type:

ssh user@server_IP 
vi ~/.ssh/authorized_keys

Now, in order to grant access to your client's user into the server, you'll have to paste the content of your client's id_rsa.pub file within the server's "authorized_keys" file (TIP: if that doesn't work, make sure that what you're pasting is a single line - in other words, the content of the id_rsa.pub has got to be a single-very-very-very-long-(as-in-4096-bit-long)-string-of-random-chars-with-a-single-beginning-and-end-Test-it-with-your-Home-and-End-Keyboard-Buttons).

Once you've pasted and saved your id_rsa.pub file content into authorized_keys, you should be able to gain access to your server from your client.

To test your simply paranoid SSH access (on your client), open a new ssh session to your server - you'll be prompted to supply your passphrase. Ff that works, this is it (otherwise start all again from scratch)!

 

THEORY: SSH can authenticate users with differents methodology, the ones I know of are:

  1. user + password.
  2. user + key (rsa private/public key exchange - no pwd asked).
  3. user + key + passphrase (a passphrase is similar to a password, but its role is different).

The "user+password" is the standard method that "just works".

The second "user + key"-method is more secure - this is useful when you can trust your client enough.

The third "user + key + passphrase"-method appends a passphrase to the key (ie. an authorisation to utilise such key). This method is useful when your trust in your client is 99% and you'd still wish to retain control of the remaining 1%.

 

OPTIONAL - how to further secure your SSH server.

Here's some interesting tweaks you may wish to apply to your SSH server - just edit your Server's "/etc/ssh/sshd_config" and configure as per below:

# Change to "no" to DISABLE tunnelled clear text passwords - 
# PAY ATTENTION TO THE FOLLOWING OPTION!!! IT MAY PREVENT ACCESS TO YOUR SERVER.
 # BEFORE APPLYING, MAKE SURE YOU HAVE DIRECT ACCESS TO YOUR SERVER IN THE FIRST PLACE (or "ensure your server sits next to you")
PasswordAuthentication no

# Maximum Login Attempts
MaxAuthTries 3

# root can't login via SSH
# Useful on Ubuntu (you can sudo afterwards)
 PermitRootLogin no

# if you are logging-in, a reminder of what to expect maybe useful.
# Hint: you may place into "issue.net" some commands that you normally type soon after logging-in.
 Banner /etc/issue.net

# keeps some brute force attacks off
MaxStartups 10:50:20

I'm assuming above tweaks are self-explanatory, so take care and have fun 🙂

Rate this post