Instead of typing in a password, you can generate an encrypted key pair that is used to authenticate you when logging in. The server will look to see if you have this key file on your computer instead. There is a good little overview of the process from cPanel here.

This is a great security measure to implement as it allows you to control which systems can access your server. You can also turn password authentication off and your server will be immune to SSH password attacks. This is major step in security hardening and is highly advised.

Generating the Keys

To get started, we are going to need to generate a Key pair on your computer (the public and private key). Load up a terminal and run:

ssh-keygen -t rsa -b 4096

It will ask where to save the key file. You can leave it at the default location.

Enter file in which to save the key (/Users/jacob/.ssh/id_rsa): id_rsa

Next, it will ask for a passphrase.

Enter passphrase (empty for no passphrase):

You can leave this blank if you simply want to leave the private key unlocked. This will make logins quite easy as you won’t have to type anything in and you will “auto-login”. However, for an added layer of security, you can set a password to unlock the private key.

It will ask for the passphrase again. Press ener to leave it blank.

Enter same passphrase again:

Finally, it will output confirmation of the keys’ location and the fingerprint:

Your identification has been saved in id_rsa.
Your public key has been saved in id_rsa.pub.
The key fingerprint is:
7b:2d:25:c2:2e:2a:1a:ea:76:3a:96:ed:1a:29:8b:9b

Copying the Public Key

Now you will need to get a copy of the public key you just made. Simply cat the file:

cat ~/.ssh/id_rsa.pub 
ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAwsIU0uzZVu6uf2GgM9B4Z7sNn5jMEs1yDrjvdI4ChXrkADegfltv0CESXknoU4NI57Dw0kyc3eJ7bADyI0uBH0PxDTZAOSKKyogsnRtgXbFLKHXpOOyiG51M9tjobObNo6SDmzbeVD5GzlmnPpgMMUoqpjYe3P45g6ouw/3Gcwt+BwZG5loSknk9lkndbyTmhb5gc4jAMYIQ3QAWCtPES04jyUWMFZ/oUn5bMaTKG2aHCgn0wTYR8ih3Ewptp0XV2z77WUmGnJV6t5wE1kZqltdh52aHTeRLoYAFoFWPt4i6sUjhFPufjeyxdXsSR5dsdqUFZRX1dsCJkGWZzfLb3w== user@computer.local

Importing Key to the Server

We’ll add the key to the server and authorize it (we have to tell the server that this particular key is allowed to access the server). Log into WHM and navigate to: Main >> Security Center >> Manage root’s SSH Keys. Click on ‘Import Key’

On the next screen, you will want to scroll down and look for the last box that says “Paste the Public Key in this box:”. Paste your public key into that box. Leave the other boxes blank. It will automatically fill in the name. Hit ‘Import’.

On the next screen it will tell you the import was successful. Click on “Return to SSH Manager”. This brings you back to the Key management screen. You will click on “Manage Authorization”

Finally, click on the button for “Authorize”.

You are done! Try logging into SSH and it should look for your key.

Server Hardening – Disable Password Authentication

Now, you can take your security one step further and completely disable password logins for SSH. You will have no more fears of hackers trying to guess your SSH passwords.

To set this up, while still in WHM, navigate to: Main >> Security Center >> SSH Password Authorization Tweak. Click on “Disable Password Auth”

And that is that. As cPanel so eloquently puts it: Now, sit back and relax as hackers will no longer be able to gain ssh access through password cracking. They will, instead, receive errors like:

Permission denied (publickey,gssapi-keyex,gssapi-with-mic).

Notes

The encryption method used for this was ‘RSA’. RSA is natively implemented in more places (it is the default key type on most generators and commercial RSA certificates are much more widely deployed) and it defaults to 2048 bit key length. At the time of this writing, for DSA to be compliant, it has to be exactly 1024 bit, which is less secure. The general consensus is that both DSA and RSA are pretty equal in security quality and speed when used merely for authentication. Either you choose will be fine as long as you follow safe security practices: use higher bit key encryption, only use SSH v2, keep your software up to date, and protect your private key.

References:
http://security.stackexchange.com/questions/5096/rsa-vs-dsa-for-ssh-authentication-keys/5100#5100

http://encryptme.wordpress.com/2011/05/25/ssh-keys-rsa-vs-dsa/

http://www.linuxforums.org/forum/security/48093-openssh-user-host-authentication-rsa-versus-dsa-provides-stronger-security.html#post498142

Note about this article

This article is one I had written for the ServInt blog as part of the ‘Tech bench’ series. You can view it on the ServInt blog here. They are using my article with my permission.

When you visit a website, your computer has to look up the IP address for that site so that it knows where to go. Before your computer goes out to find the IP address, it will first check the local hosts file. The hosts file on your computer is a plain text file that contains a map of hostnames to IP addresses.

If you wanted to override the actual IP address of a site, you could ‘trick’ your computer by manually setting the IP address for a website and telling it where to go to find a website. This is extremely common and useful to do when testing a website that you are transferring to a new serer.

Imagine you are moving your website to a new powerful system. However, you do not want the existing site to go down; you want it to stay up at all times. You can copy the site and all it’s contents to the new server, but how do you test it without changing the DNS? You want to make sure that the site is going to work on the new server without any errors before you start sending traffic over to it. The best method to do this is to change your computer’s hosts file. You can send only your computer to the new server without affecting the live site at all.

The process for modifying the hosts file varies depending on what Operating System you are running. With the help of my good buddy Colin, we have developed a handy utility that will tell you how to modify your hosts file no matter you are running Linux, Mac, or Windows. The following section of this page will detect your OS and print instruction specific to you. Hope you enjoy!

Note about this article

This utility is one I had written for the ServInt blog as part of the ‘Tech bench’ series. You can view it on the ServInt blog here. They are using my article with my permission.

suPHP and FastCGI require files and folders to have a specific set of permissions/ownership from other handlers. Without these permissions set you will see a lot of errors such as: “403 Forbidden”, “500 Internal Server Error”, or simply generic errors that commonly have the word ‘permission’ in them.

It can be very time consuming to track down and check file permissions across a whole server. Luckily, fixing this on a cPanel box can be scripted. This gives us a quick and very easy script you can wget to any cPanel server. Simply run the ‘fixperms’ script, specifying the user (or all users), sit back and watch the errors just disappear. I use this script daily in my administrative work and it never fails! It is simply a good generic fix if you cannot find your permission problem, or if you have just switched your handler and need a quick way to change every user account on the server.

Credit does not go to me though. A good buddy of mine, Colin R., wrote this for ServInt. Thanks Colin for making lives easier!

***WARNING!!! The following scripts are intended for suPHP or FastCGI. If you are not running either of these two handlers, be aware of how the script works and the changes it makes. The code is posted at the end of this article; please take a moment to review it. For example, when running DSO, some files/folders may need to be owned by ‘nobody’ in order to function properly (such as in certain WordPress functions or PHP based file uploads). Running this fixperms will set everything to USER:USER. Under DSO, this is potentially not a problem for most sites, except a few core functions may not work. You can always change specific files later if any errors pop up.

Furthermore, it is highly recommended that you run a full backup of your server before running fixperms or any other script that makes changes to multiple files.

This ‘fixperms’ script is intended for cPanel servers only. It is dependent on cPanel’s internal scripts and file structure. If you’re on anything else (such as Plesk), it will simply fail to run. It won’t be able to do anything.

I know that criteria sounds very specific, but those two conditions cover a large number of the reseller/multi-user hosting servers out there. And that’s really the crowd that would benefit most from an automated script such as this.

That all being said, if you are running suPHP or FastCGI, press on; for this script will work flawlessly for you and potentially save you a TON of time & hassle.

Fixperms – for one single user

To use the fixperms script, simply log into your server as root, wget the file from our server, then run it. Type in the cPanel username and it will run only for that particular account.

It does not matter which directory you are in when you run fixperms. You can be in the user’s home directory, the server root, etc. The script will not affect anything outside of the particular user’s folder.

wget boomshadow.net/tools-utils/fixperms.sh
sh ./fixperms.sh -a USER-NAME

Fixperms – for all of the users

If you would like fix the permissions for every user on your cPanel server, simply use the ‘-all’ option:

wget boomshadow.net/tools-utils/fixperms.sh
sh ./fixperms.sh -all

Verbosity of Fixperms

By default, the script runs in a ‘quiet’ mode with minimal display. However, if you’re like me, you may want to see everything that is happening. You can turn on verbosity and have the script print to the screen everything that is being changed. I find this extremely useful when fixing large accounts that have many files. You can watch the changes as a sort of ‘progress bar’ of completion. The ‘-v’ option can be used per account or with all accounts.

For one single account:

sh ./fixperms.sh -v -a USER-NAME

For all accounts:

sh ./fixperms.sh -v -all

The code itself, what’s in it?

I understand that it can be a big security concern to simply ‘wget’ a file from a website you found, and then blindly run it on a production server. I understand your fear; I’m right there with you and would likewise be leery and very hesitant. However, I promise you that there is no malicious intent in this or anything you will ever get from my site. I have pasted the content of the file below for your examination.

#! /bin/bash
#
# Date: Jan 26th 2012
# Author: Colin R.
# Revisions: Jacob "Boom Shadow" Tirey (boomshadow.net)
# Fixperms script for ServInt
#
#   Fixperms script for cPanel servers running suPHP or FastCGI.
#   Written for ServInt.net
#   Copyright (C) 2012 Colin R.
#
#   This program is free software: you can redistribute it and/or modify
#   it under the terms of the GNU General Public License as published by
#   the Free Software Foundation, either version 3 of the License, or
#   (at your option) any later version.
#
#   This program is distributed in the hope that it will be useful,
#   but WITHOUT ANY WARRANTY; without even the implied warranty of
#   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
#   GNU General Public License for more details. http://www.gnu.org/licenses/


# Set verbose to null
verbose=""


#Print the help text
helptext () {
    tput bold
    tput setaf 2
    echo "Fix perms script help:"
    echo "Sets file/directory permissions to match suPHP and FastCGI schemes"
    echo "USAGE: fixperms [options] -a account_name"
    echo "-------"
    echo "Options:"
    echo "-h or --help: print this screen and exit"
    echo "-v: verbose output"
    echo "-all: run on all cPanel accounts"
    echo "--account or -a: specify a cPanel account"
    tput sgr0
    exit 0
}

# Main workhorse, fix perms per account passed to it
fixperms () {

  #Get account from what is passed to the function
  account=$1

  #Check account against cPanel users file
  if ! grep $account /var/cpanel/users/*
  then
    tput bold
    tput setaf 1
    echo "Invalid cPanel account"
    tput sgr0
    exit 0
  fi

  #Make sure account isn't blank
  if [ -z $account ]
  then
    tput bold
    tput setaf 1
    echo "Need an account name!"
    tput sgr0
    helptext
  #Else, start doing work
  else
    tput bold
    tput setaf 4
    echo "Fixing perms for $account:"
    tput setaf 3
    echo "------------------------"
    tput setaf 4
    echo "Fixing website files...."
    tput sgr0
    #Fix individual files in public_html
    find /home/$account/public_html -type d -exec chmod $verbose 755 {} \;
    find /home/$account/public_html -type f | xargs -d$'\n' -r chmod $verbose 644
    find /home/$account/public_html -name '*.cgi' -o -name '*.pl' | xargs -r chmod $verbose 755
    chown $verbose -R $account:$account /home/$account/public_html/*
    find /home/$account/* -name .htaccess -exec chown $verbose $account.$account {} \;

    tput bold
    tput setaf 4
    echo "Fixing public_html...."
    tput sgr0
    #Fix perms of public_html itself
    chown $verbose $account:nobody /home/$account/public_html
    chmod $verbose 750 /home/$account/public_html

    #Fix subdomains that lie outside of public_html
    tput setaf 3
    tput bold
    echo "------------------------"
    tput setaf 4
    echo "Fixing any domains with a document root outside of public_html...."
    for SUBDOMAIN in $(grep -i document /var/cpanel/userdata/$account/* | awk '{print $2}' | grep home | grep -v public_html)
    do
	tput bold
	tput setaf 4
	echo "Fixing sub/addon domain document root $SUBDOMAIN...."
	tput sgr0
	find $SUBDOMAIN -type d -exec chmod $verbose 755 {} \;
	find $SUBDOMAIN -type f | xargs -d$'\n' -r chmod $verbose 644
  	find $SUBDOMAIN -name '*.cgi' -o -name '*.pl' | xargs -r chmod $verbose 755
    chown $verbose -R $account:$account $SUBDOMAIN
    find $SUBDOMAIN -name .htaccess -exec chown $verbose $account.$account {} \;
    done

	#Finished
    tput bold
    tput setaf 3
    echo "Finished!"
	echo "------------------------"
	printf "\n\n"
    tput sgr0
  fi

  return 0
}

#Parses all users through cPanel's users file
all () {
    cd /var/cpanel/users
    for user in *
    do
	fixperms $user
    done
}

#Main function, switches options passed to it
case "$1" in

    -h) helptext
	;;
    --help) helptext
	    ;;
    -v) verbose="-v"

	case "$2" in

		-all) all
		       ;;
		--account) fixperms "$3"
			   ;;
		-a) fixperms "$3"
		    ;;
		*) tput bold
     		   tput setaf 1
		   echo "Invalid Option!"
		   helptext
		   ;;
	esac
	;;

    -all) all
	  ;;
    --account) fixperms "$2"
      	 	;;
    -a) fixperms "$2"
	;;
    *)
       tput bold
       tput setaf 1
       echo "Invalid Option!"
       helptext
       ;;
esac

So there you have it. An effective permissions fix for your cPanel account. When you run this, people will think you’re a hero! So, go forth and save your users from the evils of site errors!

Note about this article

This article is one I had written for the ServInt blog as part of the ‘Tech bench’ series. You can view it on the ServInt blog here. They are using my article with my permission.

Change Log: