Latest revision as of 12:20, 31 May 2015

Note: This article is provided as a courtesy to our customers. SSH is a network service included with most Linux distributions. If you have specific questions or problems with SSH or using key based authentication please contact your OS vendor.

SSH is not provided by, nor is it part of any Atomicorp product and therefore is not supported by Atomicorp.

[edit] Discussion

The Secure Shell Service, or SSH for short, is a replacement service for the telnet and rsh services. These two services while in widespread use across all UNIX variants, industrial control systems, VMS systems and even Windows based systems provide no meaningful security to prevent an attacker from either hijacking sessions with these services, or simply stealing credentials as they are sent to the server. The SSH protocol was developed to rememdy the short comings in these protocols by providing both session encryption and integrity protections to ensure that an attacker could not hijack an SSH session, or steal credentials sent over the protocol.

As a modern protocol, SSH also supports a number of different mechanisms for authentication mechanisms of increasing strength. One of the most popular strong authentication systems in SSH is key based authentication. This allows a user to associate a cryptographic key with their account, which requires the user to prove they have custody of the key. Keys can also have passwords applied to them, and when this is used this provides for a two factor mechanism of authentication:

1. What you have (the key)
2. What you know (the password for the key)

Unlike password only based authentication, where you simply have to know the password, this added factor makes password guessing attacks impossible against the users account on the server (if and only if password authentication is disabled, if password authentication is not disabled then password guessing attacks are still possible).

[edit] How to disable SSH password authentication with ASL

Step 1) Define Admin user(s)

See this configuration setting and documentation:

https://www.atomicorp.com/wiki/index.php/ASL_Configuration#ADMIN_USERS

Note 1: If an Admin User is not defined, by default ASL will not allow any SSH configurations to be made and will also try to prevent other applications from changing these settings as well. This is an important failsafe to prevent users from accidentally disabling password authentication without a working account with working SSH keys. We do not recommend you disable this. Defining an Admin User is a good thing to do.

Note 2: as explained at the link above, if the Admin Users account either does not exist, or SSH keys are not configured correct (as explained at the URL above), ASL will not allow password authentication to be disabled. This means the SSH keys may not work for that user, which will of course prevent that user from being able to log in.

Step 2) Disable password authentication

See this configuration setting and documentation:

https://www.atomicorp.com/wiki/index.php/ASL_Configuration#SSH_PASSWORD_AUTH

Note: As explained above, if an Admin User is not defined, by default ASL will not allow any SSH configuration changes to be made.

[edit] How to create and install keys

[edit] Linux

To use key based authentication with SSH you will need to generate a key and you will need to protect the key.

Note: Do not generate your key on the server. You should only generate your key on your workstation, laptop, etc. and then protect the key with both a strong password, and we also recommend you use drive based encryption to ensure the key can not be stolen from your hard drive should you lose physical custody of the drive.

Step 1)

Become the user you want to login into the server as.

su - yourusername

Note: We do not recommend you do this as root.

Step 2)

Generate a strong key.

ssh-keygen -b 4096

This may take a long time. Please be patient.

The software will then ask where you want to store the key pair, we recommend you use the defaults.

The software will then ask you to put a password on the key. ALWAYS put a password on your ssh keys. Otherwise, if they are stolen, anyone will be able to log into your server without any password required. Pick a strong passphrase for your key. We recommend you use a sentence you will remember. For example, "In 2014 I Will Take a Walk Every Day!".

Note: The strength of cryptographic algorithms is an ongoing science and as weaknesses are found in algorithms the risk of continuing to use them should be careful analyzed, and new keys using new and proven stronger algorithms may need to be generated. We also recommend you replace your keys periodically, this helps to ensure if they are stolen that they will be no use to an attacker.

Step 3) Copy your public key to the server

Your public key is stored in a file that ends with .pub. By default this will be named:

id_rsa.pub

Step 3a) Login into your server

ssh -l yourusername servername

Step 3b) Create the .ssh directory

mkdir .ssh

chmod og-rwx ~/.ssh

touch ~/.ssh/authorized_keys

chmod og-rwx ~/.ssh/authorized_keys

Step 3c) Log out of your server

exit

Step 3d) Copy your ssh public key to the remote server

scp ~/.ssh/id_rsa.pub yourusername@yourserver:.ssh/authorized_keys

Note: Do not copy your secret key to the server! By default your secret key will be named id_rsa

Step 3e) Test the login

ssh yourusername@yourserver

[edit] Windows

Please see the video tutorials at the URL below:

https://www.atomicorp.com/Tutorials/