We often get asked when we on-board new clients, “What is the best way to give Crafty Penguins access to my servers?”

Since Crafty Penguins will be doing a deep dive into the system, we’ll need to have secure console access with SSH. This document should give you a good idea of how to set up SSH for our access. If you need help or run stuck, just reach out.

Requirements and Assumptions

There are a few assumptions made in these instructions. With all of the GNU/Linux distributions available, there are a number of variables in setting it up (package management, firewall software, init system, etc.).

We assume…

  • …that you have console access to the computer. This could be through your own existing SSH connection, IPMI, KVM, virtual browser console, etc. Whatever it takes for you to get in there to make the changes.
  • …that you have root privileges through the root user or ‘sudo’. All of the commands can be done by either using ‘sudo’ or elevating to root. These instructions will have ‘sudo’ pre-pended to every command. If you are already the root user, this isn’t needed.
<As a normal user with 'sudo' privileges>
sudo <command>

Elevating your privileges to root can be done by either:

sudo -i       # OR
su -
<enter password>
  • …that you can make the required changes with a text editor of your choice. The nano utility is a simple text editor if you’re not sure what to use.
  • …that your GNU/Linux distribution is either based on RPM or DEB packages. For example, CentOS, RHEL and SUSE use RPM; Ubuntu and Debian use DEB packages. These should already be configured during the installation process to point to the correct software repository.
  • …that your server’s networking has a public IP and direct access to the Internet. It is common for servers to have a firewall in front of them. In this situation, port forwarding will also need to be configured to send connections to the target server.

OpenSSH Installation

Go ahead and log into the console of your server and elevate your privileges to the root using or ‘su -i’ (or use sudo as below). First, lets make sure OpenSSH is already installed. If it’s already installed, these commands will upgrade it to the latest version.

Debian based:

sudo apt update
sudo apt install -v openssh-server

RPM based (one of):

sudo yum install openssh-server --refresh
sudo dnf install openssh-server --refresh

This will either install/upgrade openSSH server or tell you that it’s already at the latest version. If you receive an error, there is likely a problem with your package management.
OpenSSH Configuration

The main configuration file for OpenSSH server is at /etc/ssh/sshd_config. Our final goal is to access the server using SSH keys. When you open the file in a text editor, lines that begin with a ‘#’ are ignored. The remaining lines are settings. Confirm these settings by uncommenting or changing them to look like the following:

If you login with a password:

PasswordAuthentication yes
usePAM yes

Allow the use of keys:

PubkeyAuthentication yes

Allow root to log in using ONLY a key (no password):

PermitRootLogin prohibit-password

Start the OpenSSH Service

Starting the SSH server will depend on your distribution and version. The init system that manages services has changed over time and distributions might also name the SSH service differently. This could be an article in itself. All these commands should do the same thing and sometimes there is a compatibility layer in place so older commands work on newer distros. The goal is to start the SSH server and make sure that it will start after a reboot.

Older ‘SystemV’ based systems (Debian 6, Ubuntu 9.04, CentOS 5 and earlier):

sudo /etc/init.d/ssh start
[ OR ]
sudo /etc/init.d/sshd start

‘Upstart’ init system (CentOS 6, Ubuntu 9.10 to 14.10):

sudo initctl start ssh
[ OR ]
sudo initctl start sshd

Newer ‘systemd’ based systems (CentOS 7, Debian 7, Ubuntu 15.04 and newer):

sudo systemctl start ssh
[ OR ]
sudo systemctl start sshd

Set OpenSSH to always start

We also want to make sure that OpenSSH will be started after a reboot.

Older ‘SystemV’ and ‘Upstart’ based systems:

sudo update-rc.d ssh enable     # Debian based
sudo chkconfig sshd on          # CentOS 6 and earlier

Newer ‘systemd’ based systems:

sudo systemctl enable ssh       # or 'sshd'

Check the Status of OpenSSH

When you want to check the running status of SSH, use these commands (again depending on your init system):

Older ‘SystemV’ based systems (Debian 6, Ubuntu 9.04, CentOS 5 and earlier):

sudo chkconfig sshd status
sudo /etc/init.d/ssh status
sudo service ssh status

‘Upstart’ init system (CentOS 6, Ubuntu 9.10 to 14.10):

sudo initctl status mysql

Newer ‘systemd’ based systems:

sudo systemctl status ssh        # or 'sshd'

In the systemctl output, look for the line that says "Active: active (running) "

Add SSH Keys

Now that we have the service started and it will start after a reboot, public key based authentication should be added. Public key authentication uses a pair of keys to authenticate who you are to the server. The idea is that there is a private key that you hold close to you (ie. on your computer) and a public key that is placed on the server. When you use your private key to access the server, it will be mathematically compared to the public key. When it matches, you will be authenticated. The private key should always be protected with a passphrase. The public key files are freely accessible and can be distributed anywhere you’d like access. An example of a public key is:

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDAzMx0aXYykz9S2xkWOQ23fXG/xPrGYEmYWTqPakZTDhfcvIJauBZx/HieLdzmOIU8p958pMIomzAFZqVkRSd19IHJqx/AAdn8D42NnL/Ke8WUhsHkFJ40oUEQNGhgefEF6fRqrvuNZG7RtZwUAMXV1AnpKTp0/nK824msldZjTLP4sP/7Xx0kbdW1kchZ+Vz0lTkGcBJnCJDrq3e3D+UUobUCFMul8FFEYDr7ErSYShAfnRlE+itjgai+Yeyc0uveVcyVK+o7hzGosaudBsZErocDL5IUpgAmTukaVyiLZpZM4ngS5Y+6eeXbX5hL6j0OpSqlCHnbOpwwaFaVm1JH curtis@craftypenguins

This text is pasted into the authorized_keys file of any user on the server who you grant access to. Crafty Penguins will need root access to your server, so we’ll be pasting the keys into /root/.ssh/authorized_keys. The public key can be pasted manually in to the file, but for simplicity, this command will download and copy our public keys into your authorized_keys file. Only run this once, otherwise you’ll end up with extra copies of our public keys in the file.

mkdir /root/.ssh                      # create the directory if it isn't there
chmod 600 /root/.ssh                  # restrict the permissions of the folder
curl >> /root/.ssh/authorized_keys

Open a Firewall port

The next thing to check is the localhost firewall. How the firewall is managed on your server will again depend on your distribution. This is the most compatible way to allow us access through the localhost firewall.

iptables -I INPUT -s -p tcp --dport 22 -j ACCEPT

This inserts a rule right at the top of the ruleset to allow SSH access from one of our IP’s. Remember that it’s not uncommon for there to be another firewall in front of your server. Port Forwarding or some other access method will need to direct traffic to your server.

Find your Public IP

The last thing that we’ll need is the external IP address of the server. This is the IP that we use to connect. Find it with this command:


Special Remote Access Situations

There may be situations where your server is behind another firewall. Possibly a VPN needs to be set up, or Port Forwarding needs to be configured on the firewall in front of it. We can accommodate all of these situations, but it does take extra time and causes delays with starting the actual project work. If you need additional help with this, reach out to us.

Need more help?

We have clients with very different experiences or knowledge levels of Linux systems. We’re always happy to help. These instructions should get you going, but if you need some additional help, reach out to us. We can set up a screen sharing session and walk through the setup together.