Linux Home Server HOWTO

Home

Chapter 16 - Secure Shell

Version:

- openssh 4.3p2

SSH Daemon
Using SSH
Secure File Transfers

One of the most important aspects of any networked computing system is the ability to fully administer it from a remote location as though you were sitting at the actual terminal. This saves an administrator any travel time to and from a site, where the time needed to complete a simple task may only be a minute or two; this is just not time effective. There are older style applications like telnet, rcp, and rlogin that addressed these issues, however these applications send all of the users authentication details and commands to the remote host in plain text, this is a major security risk.

OpenSSH is a suite of replacement applications that provides an encrypted link between the administrators workstation and the remote host, this ensures that any login details and commands remain confidential. This chapter will explore some of the configuration settings for the SSH daemon and SSH client applications. It will also provide some information and commands for secure copy (scp) and sftp (secure ftp) which runs as a subsystem to the OpenSSH daemon.

SSH Daemon

The SSH daemon acts as the 'server' that listens for, and handles incoming client connections. In its default configuration the daemon handles all the requirements for cryptographic key generation and rotation, so we are only going to be adjusting the operational parameters of the server here and not the keys. As with all our configuration files we need to make our backups before we proceed.

[bash]# cp /etc/ssh/sshd_config /etc/ssh/sshd_config.original
[bash]# vi /etc/ssh/sshd_config

SSH operates on port 22 by default and listens on all networking devices, they can be adjusted here if you need to change them. The openssh daemon also supports versions 1 and 2 of the ssh protocol which are both normally loaded by default.

Version 1 of the SSH protocol is vulnerable to a known security exploit where an attacker may be able to insert malicious data into a secure link, it is therefore suggested that only protocol 2 be used for sshd, while protocol 1 be disabled.

Port 22
Protocol 2
#AddressFamily any
AddressFamily inet
#ListenAddress 0.0.0.0
#ListenAddress ::

The following details are where the public and private cryptographic keys are stored for sshd, these are the default values and should not be adjusted unless you really know what you are doing.

# HostKey for protocol version 1
#HostKey /etc/ssh/ssh_host_key
# HostKeys for protocol version 2
#HostKey /etc/ssh/ssh_host_rsa_key
#HostKey /etc/ssh/ssh_host_dsa_key

The ssh daemon automatically regenerates its cryptographic key pairs every hour if they have been used, this ensures the keys are 'fresh' and prevents replay attacks from any captured data packets. The default key strength is 786 bits.

KeyRegenerationInterval 1h
ServerKeyBits 1024

The daemon should be configured to log all access attempts, good or bad.

SyslogFacility AUTHPRIV
LogLevel INFO

By default the root account is allowed to use the ssh daemon for remote access, it is also the account that is the main focus of all external attacks against a site. It is highly advisable that you ban all root login privileges, particularly if the root password is weak and offers little protection. You would do better to create a single account for ssh access only, then switch to the root account after you have successfully authenticated with the server and gained access.

The LoginGraceTime directive is the amount of time that a connected user has to login after establishing a connection to the server. If the user has not successfully logged in during this time they will be disconnected (default is 120s).

PermitRootLogin no
LoginGraceTime 30s
MaxAuthTries 4

The following directives specify that only these users or groups are allowed to do remote logins. Only valid user and group names are permitted, while any numerical UID and GID representations will be ignored.

By specifying either of the two 'allow' directives, all other user access will be denied unless explicitly listed here, comment these to allow all users access.

AllowUsers sshconnect
AllowGroups sshusers

Similar to 'allow', the deny directives specify which accounts are not allowed to access the server.

DenyUsers alice bob
DenyGroups sshdeny

These specify that password authentication will be used, and empty passwords will be ignored. These are default settings.

PasswordAuthentication yes
PermitEmptyPasswords no

The AuthorizedKeysFile directive identifies the filename located in each users home directory which is used to store their public key when accessing the server. You can assist users by creating the empty "/etc/skel/.ssh/authorized_keys" file so that newly created accounts have this file available if they need it.

AuthorizedKeysFile .ssh/authorized_keys

When users attempt to connect to the server the banner is displayed before they attempt to log into the system, this should be used to inform connecting users that all access is logged and any other legal details. You can also configure the server so the "message of the day" (/etc/motd) is displayed to the user after successful access is granted.

Banner /etc/ssh/banner
PrintMotd yes

The sftp (SSH File Transfer Protocol) subsystem allows the copying of files between remote server and host workstation using the ssh daemons encryption system for security. Secure FTP and Secure copying are covered a little lower.

Subsystem sftp /usr/libexec/openssh/sftp-server

More configuration options and information can be obtained in the accompanying man pages, type "man sshd" and "man sshd_config" at the command prompt from further details.

The "AcceptEnv" option allows sshd to export a users enviroment variables and setting from the server to the remote ssh client, examples are listed below.

AcceptEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES
AcceptEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT
AcceptEnv LC_IDENTIFICATION LC_ALL

Starting The Server

The service can now be set to the appropriate runlevels and checked to ensure they are correct.

[bash]# chkconfig --level 2345 sshd on
[bash]# chkconfig --list sshd

Its time to start the service and ensure there are no initialisation errors with the daemon.

[bash]# /etc/init.d/sshd restart
[bash]# grep sshd /var/log/messages

Using SSH

The SSH client is obviously at the other end of the secure connection where the administrator (or general user) establishes the connection to log in from. Because this is only a home user howto, we will only look at the basics needed for logging in over the network. For further details on the SSH client type "man ssh" and "man ssh_config" at the command prompt. Remember if you need to log into your server from outside of your network (work etc..), you will need to open port 22 in your firewall.

The first time you login into a remote server you will be warned that the identity of the host could not be established. If you are certain of the hosts identity, you can accept the cryptographic certificate which a copy of gets placed into your "~/.ssh/known_hosts" file in case you access the site again.

[bash]# ssh [email protected]

The authenticity of host 'galaxy.example.com (192.168.1.1)' can't be established.
RSA key fingerprint is cd:3e:99:ef:5a:e6:6e:40:a4:25:79:a1:50:31:4b:7a.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'galaxy.example.com' (RSA) to the list of known hosts.
[email protected]'s password:

After you have successfully authenticated, you will be presented with a shell prompt for the remote host. You can now execute any command on the remote system as though you were sitting at the terminal. Be careful not to execute commands or change any firewall settings that may cause the remote system to close your connection.

There may be occasion where the private RSA keys for the remote server are replaced. If this is the case then the public key which was earlier stored in your "~/.ssh/known_hosts" file will cause a conflict with the new public key. This will result in the client suspecting the server of a possible security attack.

[bash]# ssh [email protected]

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the RSA host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
8e:ed:e3:45:50:5e:13:33:58:0e:d5:eb:e6:fc:ef:43.
Please contact your system administrator.
Add correct host key in /home/alice/.ssh/known_hosts to get rid of this message.
Offending key in /home/alice/.ssh/known_hosts:14
RSA host key for galaxy.example.com has changed and you have requested strict checking.
Host key verification failed.

The above warning message identifies the 'fingerprint' of the cryptographic keys has changed. You should always confirm any changes to a remote system before you fix this fault and continue to access the server.

When you connect using a remote ssh session it is easy to forget which terminal window is connected to the remote server. This should always be checked whenever in doubt to prevent the wrong commands being sent to the wrong hosts. The session can be checked with the following simple command.

[bash]# uname -n

galaxy.example.com

Type "exit" to close the remote connection.

Windows Client

The secure shell daemon provides platform independence, which means you are able to use a different type of operating system to access the server, assuming that the application supports the ssh protocols. PuTTY is a free SSH (and telnet) windows based client written and maintained by Simon Tatham, it provides similar functionality to the Linux client. The client and source code (if needed) are available for download here: http://www.chiark.greenend.org.uk/~sgtatham/putty.

I recommend you download a copy of PuTTY and make it available on your FTP server, because that day will come when you need access to your system and the windows based client may prove quite useful if you are outside of your standard environment.

Secure File Transfers

The SSH daemon is able to run a subsystem of other applications which can take advantage of the secure environment provided by the cryptographic protocols, one of these subsystems is sftp (SSH File Transfer Protocol). The sftp server provides the ability for users and administrators to log in from remote systems so they can copy files in a confidential manner. Many ISPs now provide their users with some form of secure ftp so that their user details are secure when they log in to upload their public webpages. The access controls are inherited from the main sshd_config file.

The sftp server should not be confused with FTPS available in vsftpd, which is the original FTP with security extensions as discussed in chapter 14. Both systems are capable of providing a secure service and both offer different advantages about how they can be implemented. There is nothing wrong with having both systems running at the same time, then you can simply use the one that suits your needs the best.

To start sftp in interactive mode, type the following at the command prompt. This command would open an interactive SSH FTP session to the galaxy.example.com server for alice's account. See "man sftp" for further details.

[bash]# sftp [email protected]

Secure copy (scp) is a replacement to the older remote copy (rcp) application that allows files to be copied from one system to another in the same fashion as though you were copying files between directories on your own filesystem. The secure copy application allows for quicker non-interactive commands.

[bash]# scp filename [email protected]:/home/alice

Copy "filename" into alice's home directory on the remote galaxy.example.com server

[bash]# scp [email protected]:/home/bob/* /officeusers/bob

Copy all the files from bob's home directory on the remote galaxy.example.com server, to the local "/officeusers/bob" directory

[bash]# scp -r /home/alice/public_html/* [email protected]:~/public_html

Recursively copy all of alice's public webpages on the local computer, to alice's public_html directory on the remote "myisp.com" server

[bash]# scp -r -P 1234 [email protected]:~/* /home/bob

Recursively copy all of bob's files from the remote.com server (on port 1234), to bob's home directory on the local computer

[bash]# scp -r [email protected]:/etc/* [email protected]:/etc/

Recursively copy the contents of /etc directory from workstation1 to workstation2 using a shared superuser account

Windows Client

Secure copy and SSH FTP also cater for platform independence as both allow for windows based applications to connect as the remote client. WinSCP is a freeware opensourced windows based SCP and SFTP client and allows for easy transfer between windows platforms and SSH servers. The WinSCP application is available for download at http://winscp.sourceforge.net.

Home