Secure Shell Basics

SSH or Secure Shell, is a tool used for secure remote access and administration of computers. If you are using ChunkHost, or any remote server, you will likely be using ssh as your primary method of administering commands to the server. If you are curious how this is done, there are many better articles explaining it elsewhere on the internet. This article will focus on setting up ssh for basic use. This information should be applicable to any Linux distro available on ChunkHost, items specific to a particular distro will be noted as such.

Getting started with Secure Shell

If you are not familiar with SSH, it is a huge suite of tools, but we will focus on the ssh command itself with occasional help from scp, the secure copy command.

In order to use ssh, you must have the program installed on both the server and your local machine. ChunkHost servers have secure shell installed and configured even on a fresh image.

For Windows users

The easiest way to use ssh is most likely the PuTTy program, available for download here.

For Mac OS X

You have ssh installed already.

For Linux

You must have an ssh implementation installed. The easiest way is to use your system's package manager. The package can likely be found by searching for ssh or openssh. OpenSSH is an excellent and popular ssh implementation favored by Linux and BSD users.

From here on, the guide will assume you are using ssh and scp from a command line as you would in Mac OS X, GNU/Linux, or BSD. If there is demand, I can write a Windows-specific guide as well.

Login details

To access your chunk via ssh, use the following details:

host: use the domain name for your chunk or the chunk IP
username: root
password: the root password we emailed to you when your chunk was created (it's different than your chunkhost account password)

Using SSH Keys

Introduction

Secure Shell uses a username and password to authenticate by default. While this method is valid for some setups, there are some times when it is not suitable. For example:

• A team of people, all connecting to the same user account.
• An automated or scripted connection where having a plain text or no password is insecure.
• A system which would otherwise require frequent password rotation.

SSH can use another method of authentication called private-key authentication. There are more in-depth explanations of how this works elsewhere, but basically it relies on two related files, a public-key and a private-key. As the names suggest, the public key can be given freely to anyone you wish. Many developers and systems administrators display theirs prominently as a mark of pride. The private-key, as the name implies, should be kept to yourself and not given out or shared. A private-key is like a digital fingerprint, it is used by anyone with your public-key to verify that you are, in fact, you. Keep it safe and backed up!

Generating Your Keys

From your home directory, on your local machine, create or change to your $HOME/.ssh directory. If you don't have one or aren't sure, this bash one-liner will do exactly that without changing the folder if it already exists.

[[ -d ~/.ssh ]] && cd ~/.ssh || mkdir ~/.ssh && cd ~/.ssh

The ssh-keygen command is used to generate keys. If all you plan to do with it is use Secure Shell, you can use a standard DSA key:

 ssh-keygen -t dsa

It will ask you what to call the key, the default id_dsa is perfectly adequate. You will then be asked to enter and confirm a password. Make sure it is a good, strong one that is difficult to guess. This is your last line of defense if your key is put somewhere insecure.

This will then display some output and generate two files, named id_dsa and id_dsa.pub provided you did not change anything.

Next, you need to change the permissions on your private key to protect it from snooping users. Use the chmod command as below to do this.

chmod 600 id_dsa

Adding your public key to the server

Now you must copy your public-key to your remote server. Do this using scp:

scp id_dsa.pub your_username@your.remote-server.com:

replace your_username with the username you've been logging in with and your.remote-server.com with the fully qualified domain name assigned to your server. In place of the domain name, the IP Address assigned to your chunk will work. Also note the : at the end.

Now log into your remote server using password authentication for the last time:

ssh your_username@your.remote-server.com

Change to or create a .ssh directory in the home folder of your remote user. If you want, use the same script as before. Then concatenate the public-key to the ~/.ssh/authorized_keys file:

cat ~/id_dsa.pub >> authorized_keys

Now that you've completed this, go ahead and remove the public key from your home directory.

rm ~/id_dsa.pub

Testing the New Method

In a new terminal window (in case something goes horribly wrong, you want to keep the other session open), run the ssh command again with the exact same options:

ssh your_username@your.remote-server.com

Instead of being prompted for the password of the remote user, you should instead see a prompt for the passphrase you chose earlier. Enter it now, and you should be logged in. If not, check to ensure the permissions are correct on your ~/.ssh/id_dsa on your local machine. You need not restart ssh in order to make use of this.

Disabling Password Authentication (Optional)

This step is an additional security measure for those who know that they will have their private-key available at every system they use to log into the remote machine. It prevents users from logging in without first having a public/private key pair.

Using sudo and replacing $EDITOR with your preferred text editor, if you don't know of any, nano is a suitable editor for a task this small.

sudo $EDITOR /etc/ssh/sshd_config

Find the line containing PasswordAuthentication. Replace:

#PasswordAuthentication yes

with

PasswordAuthentication no

Make sure you remove the # at the beginning of the line, if any. Then restart your SSH Daemon with:

sudo /etc/init.d/sshd restart

Note: This will not affect your current session.

Disabling SSH for Root

Warning!!! Before attempting this, make sure you have another user account with SSH enabled. Otherwise you will be unable to access your system without the Chunkhost recovery console!

Running directly as root is becoming less and less common, with sophisticated tools like sudo, there is often little to no need to do so. Additionally, allowing root to log in via ssh means an attacker knows a valid username on your system. The username with all of the power no less! By logging in as a different user and elevating to root using su, or doing so only as needed with the sudo command, you add one more layer of protection to your system.

Disabling ssh for root is fairly simple, you only need to edit one line of your sshd configuration file. Replace $EDITOR below with the command for your preferred text editor. If you don't know of any, nano is a simple one to use for something this small.

$ sudo $EDITOR /etc/ssh/sshd_config

or on some systems,

$ sudo $EDITOR /etc/openssh/sshd_config

Find the line of the file with PermitRootLogin, change the yes to no, if there is a # character in front of the line, remove it.

...
 # Authentication:

  #LoginGraceTime 2m
  #PermitRootLogin yes
  #StrictModes yes
  #MaxAuthTries 6
  #MaxSessions 10
...

Change

#PermitRootLogin yes

to

PermitRootLogin no

All that is left is to restart the SSH Daemon. On CentOS, this can be done as root with the command:

service sshd restart

On most systems the following will suffice:

sudo /etc/init.d/sshd restart

Note: neither of these commands will interrupt your current ssh session but be aware that if you've been connecting to your server as root, you now need to use a different username in the future.