This document provides instructions for configuring remote access and secure file transfers using OpenSSH on CentOS 5. It describes how to configure SSH for password-less authentication using public key authentication. It also explains how to optionally rebuild OpenSSH 5.4p1 to enable additional access restrictions and features. Scripts are provided to help administer user accounts and setup file structure for hosting users.

1. CentOS 5 SSH+SFTP for remote
access and secure file transfers
[OpenSSH]
Submitted by firewing1 on Wed, 05/04/2011 - 18:42
This how-to will show you how to configure:
Remote access over SSH via OpenSSH
o Secure, password-less authentication
o 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

2. # Why give such a large window? If the user has not provided credentials in 30
# seconds, disconnect the user.
LoginGraceTime 30s
EOF
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
exit
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_wrappersdevel at approximately line number 142. Simply remove the -devel so that the line now
readsBuildRequires: 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 lineRequires: 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:

3. cat << EOF > sshd.pam
#%PAM-1.0
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
EOF
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 pamdevel fipscheck-devel openssl-devel krb5-devel libedit-devel ncurses-devel libselinuxdevel xauth
fedpkg local
exit
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|Subsystemtsftpt/usr/libexec/openssh/sftpserver|#Subsystemtsftpt/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

4. # 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
EOF
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 mailfolder
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.
Denyhosts
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
#!/bin/sh
# "chown root.root"s are implied, but kept to be safe
if [ -z $1 ];then
echo "Usage: $1 user1 [user2]"
exit 1
fi
for username in "$@";do

5. read -p "Restrict $username (make member of serv_sftponly)? [Y/n] " -t 60 -n 1
response
echo
if [ "$response" == "n" ] || [ "$response" == "N" ];then
echo "*** Creating normal user $username"
useradd -G serv_sshall $username
else
echo "*** Creating restricted user $username"
useradd -G serv_sftponly -s /sbin/nologin $username
fi
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
done
EOF
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

6. 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.