SlideShare a Scribd company logo

Cent os 5 ssh

•Download as DOCX, PDF•
•
A
Alejandro Besne

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.

Related slideshows

How to Configure OpenFiler for NFS Share
How to Configure OpenFiler for NFS ShareHow to Configure OpenFiler for NFS Share
How to Configure OpenFiler for NFS Share
 
How to installation and configure apache2
How to installation and configure apache2How to installation and configure apache2
How to installation and configure apache2
 
Actividad configuración de cisco asa vpn
Actividad configuración de cisco asa vpnActividad configuración de cisco asa vpn
Actividad configuración de cisco asa vpn
 
1 of 6
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
# 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:
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
# 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
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
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.

More Related Content

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.