Toll-Free: 877-314-0319
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.
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…
<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>
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
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
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'
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) "
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 [email protected]
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 http://mirror.kerkhofftech.ca/craftypenguins_rsa.pub >> /root/.ssh/authorized_keys
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 207.81.246.81/32 -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.
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:
curl ipv4.icanhazip.com
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.
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.