![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](https://image.slidesharecdn.com/centos5ssh-131031184048-phpapp02/85/Cent-os-5-ssh-1-320.jpg)
![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](https://image.slidesharecdn.com/centos5ssh-131031184048-phpapp02/85/Cent-os-5-ssh-3-320.jpg)
![# 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](https://image.slidesharecdn.com/centos5ssh-131031184048-phpapp02/85/Cent-os-5-ssh-4-320.jpg)
![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](https://image.slidesharecdn.com/centos5ssh-131031184048-phpapp02/85/Cent-os-5-ssh-5-320.jpg)
Cent os 5 ssh
- 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.