CentOS 5 SSH+SFTP for remote access and secure file transfers [OpenSSH]

This how-to will show you how to configure:

  • Remote access over SSH via OpenSSH
    • Secure, password-less authentication
    • Optional: OpenSSH 5.4p1 to allow restrict shell access and jail users by group
  • Secure file transfers over SFTP

Configuring OpenSSH

openssh-server is already installed by default, it just needs to be configured. We will disable root logins as well as all password-based logins in favour of the more secure public key authentication. If you do not already have a SSH key, you should take the time to create one now by running ssh-keygen on the computer you will be using to access the server remotely.

The following will configure SSH as described above:

cat << EOF >> /etc/ssh/sshd_config
## Customizations ##
# Some of the settings here duplicate defaults, however this is to ensure that
# if for some reason the defaults change in the future, your server's
# configuration will not be affected.

# Do not allow root to login over SSH. If you need to become root, login as your
# regular use and use su - instead.
PermitRootLogin no

# Disable password authentication and enable key authentication. This will
# force users to use key-based authentication which is more secure and will
# protect against some automated brute force attacks on the server. As well,
# this section disables some unneeded authentication types. If you wish to use
# them, modify this section accordingly.
PasswordAuthentication no
PubkeyAuthentication yes
ChallengeResponseAuthentication no
KerberosAuthentication no

# Do not allow TCP or X11 forwarding by default.
AllowTcpForwarding no
X11Forwarding no

# Why give such a large window? If the user has not provided credentials in 30
# seconds, disconnect the user.
LoginGraceTime 30s

Let's make sure SSH starts on boot, restart the service immediately and finally add the firewall exception for port 22:

chkconfig sshd on
service sshd restart
iptables -I RH-Firewall-1-INPUT 4 -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT
service iptables save

Because we have disabled root access over SSH, it is time to create a regular user that you can used to login over ssh and then gain root access:

useradd myusername
passwd myusername
su - myusername
mkdir -m 0700 .ssh
touch .ssh/authorized_keys
chmod 600 .ssh/authorized_keys
restorecon -v -r /home/myusername

Now add the contents of your ~/.ssh/id_rsa.pub file to .ssh/authorized_keys on the server.

Optional (but recommended): Rebuilding OpenSSH 5.x

Although SSH will function perfectly fine with this bare configuration, it is not the most secure possible. CentOS 5 comes with OpenSSH version 4.3p2 which is rather outdated. Instead of using 4.3p2, OpenSSH version 5.4p1 (from Fedora 13) can be rebuilt which offers a slew of new features such as access control via user/group matching and SFTP jailrooting.

yum install fedora-packager
su - myusername
cd ~/rebuilds
fedpkg clone -a openssh
cd openssh
fedpkg switch-branch f13

Before the package can be rebuilt, a few changes need to be made to make it work on CentOS 5. Edit openssh/F-13/openssl.spec and find the line BuildRequires: tcp_wrappers-devel at approximately line number 142. Simply remove the -devel so that the line now reads BuildRequires: tcp_wrappers. Just below, you will also notice a statement BuildRequires: openssl-devel >= 0.9.8j.
Remove the version requirement so that the line reads BuildRequires: openssl-devel. Lastly, near line 178 find the line Requires: pam >= 1.0.1-3 and once again, remove the version requirement so that the line reads Requires: pam.

Now that the RPM spec file has been modified, we also need to change the PAM configuration file as the one from Fedora 13 uses some modules that are not present in CentOS 5:

cat << EOF > sshd.pam
auth       include      system-auth
account    required     pam_nologin.so
account    include      system-auth
password   include      system-auth
# pam_selinux.so close should be the first session rule
session    required     pam_selinux.so close
session    required     pam_loginuid.so
# pam_selinux.so open should only be followed by sessions to be executed in the user context
session    required     pam_selinux.so open env_params
session    optional     pam_keyinit.so force revoke
session    include      system-auth

The package is ready to be rebuild for CentOS 5. Execute the following to rebuild and install OpenSSH 5.4p1:

yum install gtk2-devel libX11-devel autoconf automake zlib-devel audit-libs-devel pam-devel fipscheck-devel openssl-devel krb5-devel libedit-devel ncurses-devel libselinux-devel xauth
fedpkg local
rpm -Uhv /home/myusername/rebuilds/openssh/[arch]/openssh-{5,server,clients}*.rpm
rm -f /etc/ssh/sshd_config.rpmnew

Remember to replace [arch] in the second to last command with the appropriate value (most probably i686 for 32-bit machines or x86_64 for 64-bit machines). We can take now advantage of the new features to harden SSH! The configuration segment below will restrict access for members of the serv_sftponly group such that only SFTP access is permitted and those users are jailed to the "web" folder in their home directory (so that they can only upload/download files from their website). Members of the serv_sshall group have full SSH and SFTP access, as well as X11 and TCP forwarding.

mkdir /srv/sftp
groupadd serv_sftponly
groupadd serv_sshall
usermod -a -G serv_sshall myusername
sed -i'' 's|Subsystem\tsftp\t/usr/libexec/openssh/sftp-server|#Subsystem\tsftp\t/usr/libexec/openssh/sftp-server|' /etc/ssh/sshd_config
cat << EOF >> /etc/ssh/sshd_config
## Access control ##
# We need to use the internal sftp subsystem
Subsystem       sftp    internal-sftp
# Allow access if user is in these groups
AllowGroups serv_sftponly serv_sshall

# We can't use a path relative to ~ (or %h) because we make the user homes
# /public_html in order to get the chroot above working properly. As a result,
# we need to set an absolute path that will make SSH look in the usual place
# for authorized keys.
AuthorizedKeysFile /home/%u/.ssh/authorized_keys

# Give tunnelling + X11 access to users who are members of group "serv_sshall"
Match group serv_sshall
    X11Forwarding yes
    AllowTcpForwarding yes

# Restrict users who are members of group "serv_sftponly"
Match group serv_sftponly
    # Some settings here may duplicate the global settings, just to be safe.
    #PasswordAuthentication yes
    X11Forwarding no
    AllowTcpForwarding no
    # Force the internal SFTP subsystem and jailroot the user in their home.
    # %u gets substituted with the user name, %h with home
    ForceCommand internal-sftp
    ChrootDirectory /srv/sftp/%u
service sshd restart

The /srv/sftp/username folder is used instead of the user's entire home because it prevents the user from making any potentially unwanted configuration changes (such as authorizing additional ssh public keys) as well as accidentally deleting files, such as the mail folder which holds all of that domain's emails. One now simply needs to link /srv/sftp/username to the appropriate web folder to jail the user there. For example:

ln -s ../../home/username/web /srv/sftp/username

You do not need to do this manually, as the user setup script will run this for you.

As well, note that the configuration includes the commented line #PasswordAuthentication Yes in the serv_sftponly MatchGroup section. If you so wish, you can uncomment this line to have password authentication enabled ONLY for users of the serv_sftponly group. While password authentication is less secure than public key authentication, it is much more convenient for your clients if you are building a shared hosting machine and if a hacker does gain access because a user had an easy to guess password, they only gain access to a single jailed SFTP client.


You may be wondering why I haven't included any information about software that can block repeated SSH intrusions such as denyhosts... I have placed this information, along with other server security tips, in the security tutorial (coming soon). Please see it for more information.

Administering the server

Setting up the scripts

The following code will setup the "hosting_user_add" script which can be used to add new hosting users on your server:

mkdir -p /root/bin
cat << EOF > /root/bin/hosting_user_add
# "chown root.root"s are implied, but kept to be safe

if [ -z \$1 ];then
  echo "Usage: \$1 user1 [user2]"
  exit 1

for username in "\$@";do
  read -p "Restrict \$username (make member of serv_sftponly)? [Y/n] " -t 60 -n 1 response
  if [ "\$response" == "n" ] || [ "\$response" == "N" ];then
    echo "*** Creating normal user \$username"
    useradd -G serv_sshall \$username
    echo "*** Creating restricted user \$username"
    useradd -G serv_sftponly -s /sbin/nologin \$username
  chown \$username.apache /home/\$username
  chmod 710 /home/\$username
  # Set password
  passwd \$username
  # Initialize mail storage folder
  mkdir -m 0700 /home/\$username/mail
  chown \$username.\$username /home/\$username/mail
  # Initialize web folders
  mkdir -p -m 0755 /home/\$username/web
  chown root.root /home/\$username/web
  # Web: logs
  mkdir -p -m 0750 /home/\$username/web/logs
  chown root.\$username /home/\$username/web/logs
  # Web: offline/private storage
  mkdir -p -m 0755 /home/\$username/web/storage
  chown \$username.\$username /home/\$username/web/storage
  # Web: docroot
  mkdir -m 0755 /home/\$username/web/public_html
  ln -s public_html /home/\$username/web/www
  # make it so they can't remove the symlink
  chown -h root.root /home/\$username/web/www
  chown \$username.\$username /home/\$username/web/public_html
  # Web: PHP error log
  touch /home/\$username/web/php_error_log
  chown \$username.\$username /home/\$username/web/php_error_log
  chattr +u /home/\$username/web/php_error_log

  # Initialize session folder
  mkdir -m 0770 /var/lib/php/session/\$username
  chown root.\$username /var/lib/php/session/\$username

  # SSH: SFTP login
  ln -s ../../home/\$username/web /srv/sftp/\$username

  # SSH: Authorized keys dir
  mkdir -m 0700 /home/\$username/.ssh
  chown \$username.\$username /home/\$username/.ssh
  # Key description here
  echo "your_key_here" >> /home/\$username/.ssh/authorized_keys

  chmod 600 /home/\$username/.ssh/authorized_keys
  chown \$username.\$username /home/\$username/.ssh/authorized_keys
  restorecon -v -r /home/\$username
chmod +x /root/bin/hosting_user_add

You will need to edit /root/bin/hosting_user_add later and replace your_key_here with your own SSH key so that you can login to the account should you ever need to test or do administration work.

Adding a new system account

/root/bin/hosting_user_add new_username

If you are adding many accounts, you can optionally specify more than one username to have each account be created at once. For each user specified, you will be prompted if for both their password and restricted status. Passwords can and should be set randomly because with key-based authentication, they should never have to enter it anyways.

Resources and further reading