New To Linode? Starting Out Right…

Big thanks to the great reps of Linode for turning me on to their hosting at PyCon last week. Since I’m starting with a fresh Ubuntu server, I wanted to do it right, so I spent some time learning how to properly do public/private keys for logins and to disable remote root logins…

Your First Log-In

The first time ssh’ing to your new instance a warning will appear letting you know that you haven’t seen this hostname and/or IP before and asks you if you really want to connect (i.e. do you trust this server):

The authenticity of host ' (' can't be established.
ECDSA key fingerprint is xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '' (ECDSA) to the list of known hosts.'s password: 
Welcome to Ubuntu 11.10 (GNU/Linux 3.0.18-linode43 i686)

 * Documentation:

The programs included with the Ubuntu system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Ubuntu comes with ABSOLUTELY NO WARRANTY, to the extent permitted by
applicable law.


If you answer in the affirmative and supply the correct password, your new server’s public key will be stored under two possible entries in your local ~/.ssh/known_hosts file: one for the IP address and the other for the hostname (if used). FYI: you can delete an entry by using:

$ ssh-keygen -R 

Create a new user

In later steps we’re going to disallow remote logins by the root user, so this step is CRITICAL!

$ sudo adduser NEWUSERNAME

... lots of easy steps here ...

Add you’ll probably want to add this new user to the sudoers list so they can do things like install system-wide packages and perform upgrades. Edit (as root) the file /etc/sudoers and add your new username to the list under User privilege specification:

# User privilege specification

Go Password-Less!

Create a private/public key pair on the client machine. The default type is ‘rsa’, but let’s use the -t option for demonstration purposes. Also, to stop a default email address from getting into the comment, we’ll be specific and use a good email (doesn’t have to be an email, could be a location like “mylaptop”, etc…):

$ ssh-keygen -t rsa -b 4096 -C

... answer the questions 

When asked to enter the filename, you can accept the default or go with a custom name. I’ll use “MYKEY_rsa” for this workflow. Also, I’ve NOT used a passphrase. You may add a passphrase for added security…

Transfer your public key to the remote machine

The remote machine needs your public key to decrypt the data you send it that’s encrypted with your private key. Below are steps to do this both manually and then quickly with the ssh-copy-id program.


Create the ~/.ssh directory on the server and protect it:

$ mkdir ~/.ssh
$ chmod 700 ~/.ssh

Transfer your public key from the client to remote machine:

$ cat ~/.ssh/ | ssh 'cat >> ~/.ssh/authorized_keys''s password: XXXXXX

Using ssh-copy-id

This method is a lot more bullet-proof.

$ ssh-copy-id -i ~/.ssh/'s password: XXXXXX
Now try logging into the machine, with "ssh ''", and check in:


to make sure we haven't added extra keys that you weren't expecting.

Make yourself known to ssh-agent

You’ve given your public identity to the remote server and you’ve added it to your known_hosts. Now, if you attempt an ssh connection, you’ll see this error if you’ve used a non-default name for your keys:

Agent admitted failure to sign using the key.

This is because ssh didn’t know which identity you to use. To remedy this, let the ssh agent know about your new identity so it can provide the correct credentials behind the scenes when needed.

$ ssh-add ~/.ssh/MYKEY_rsa

FYI: to delete all your identities, use this command:

$ ssh-add -D

Ubuntu will prompt you for the password, if the private key has one (I didn’t supply one in this workflow).

Disallow Keyboard-based And Remote Root Logins:

Now that authentication can happen using public/private keys, we can now safely disable standard keyboard password authentication on the server. On the server machine, open the file /etc/ssh/sshd_config and make the following changes:

PasswordAuthentication no
ChallengeResponseAuthentication no

ONLY if you’ve created a new user and given them sudo permissions should you modify this line:

PermitRootLogin no

Reload your sshd config file (using Ubuntu’s upstart):

$ sudo service ssh reload

Now (just to test things) back on the client, tell our agent to forget our key, and attempt a regular ssh connection. You should get a ‘Permission denied’ error:

$ ssh
Agent admitted failure to sign using the key.
Permission denied (publickey).

Add the key back to the agent, and all should be good!

$ ssh-add MYKEY_rsa
Identity added: MYKEY_rsa (MYKEY_rsa)

$ ssh

Try Something!

Now to test your new user and their sudo permissions, try installing a cool database!

$ sudo apt-get install redis-server

Leave a Reply