This chapter is from the book
This chapter is from the book
This chapter is from the book
SSH (Secure Shell)
As mentioned at the beginning of the chapter, the Telnet protocol sends passwords and data in clear text and shouldn’t be trusted for important sessions and tasks. The Secure Shell (SSH) suite includes a protocol, a daemon, and client utilities that make your host-to-host shell sessions much more secure—about as secure as being at the physical console.
One of the features that makes SSH desirable as a remote protocol is its end-to-end encryption, which encrypts not only the username and password but also all communications.
The SSH suite replaces telnet, as well as rsh, rexec, rcp, and other unsecure utilities. You can use SSH to connect for a shell session, or you can use the scp command to remotely transfer files through the secure pipe that SSH builds between the hosts.
SSH Components
SSH includes a number of programs and files:
ssh: Used for remote shell sessions on another host, it replaces the telnet, rsh, and rexec commands.
scp: Used for remote copying operations, it replaces the rcp command.
sshd: The SSH daemon.
ssh-agent: Runs as a wrapper to the user’s session and provides authentication when requested.
ssh-add: Loads the user’s key(s) into the agent.
The SSH package configuration files are somewhat scattered. SSH daemon and global configuration files are kept in the /etc/ssh directory, and local or user-specific configuration files are kept in the ~/.ssh directory for each user.
The global configuration files include
/etc/ssh/sshd_config: This is the main configuration for the sshd daemon.
/etc/ssh/ssh_host_[dr]sa_key: These files, the ssh_host_dsa_key file and the ssh_host_rsa_key file, are in the same directory and are the private parts of the host’s key structure and should be protected from public view. The permissions for these files are 600 or rw for the root user and no permissions for anyone else.
/etc/ssh/ssh_host_[dr]sa_key.pub: These files, the ssh_host_dsa_key.pub file and the ssh_host_rsa_key.pub file, are in the same directory and are the public parts of the host’s key structure. These must be world-readable and write-only by the root user or set to 644.
/etc/nologin: This isn’t a part of SSH. However, if it’s present, no one can log in via SSH except the root user. Non-root users see the contents of the /etc/nologin file and then are denied access to the system.
A couple of special file pairs affect how SSH works, particularly the /etc/ssh/ssh_known_hosts and ~/.ssh/known_hosts files. The global file (/etc/ssh/ssh_known_hosts) is used to check the public key of a host attempting to attach via SSH. The local file (~/.ssh/known_hosts) is the file from which the client gets the public key of the remote server. If a new connection is begun to a previously unknown host, the user sees a message saying that the host is unknown and asking whether the user wants to store the host’s key in his known hosts file. If the user answers in the affirmative, the host’s public key is added to the ~/.ssh/known_hosts file.
The /etc/ssh/ssh_known_hosts file should be world-readable and root-writable. The ~/.ssh/known_hosts file must be owned by and writable for the user.
A file of interest, the ~/.ssh/authorized_keys file, affects only a particular user’s environment. This file is used to store the public keys that can be used for logging in as this user. These keys are matched with the keys presented by an ssh or scp client upon login request.
The SSH client utilities are versatile, with a number of options available to customize the experience. You just need to know the basics for the Linux+ exam, but this section includes a few fun options.
The SSH client command is used to replace the RSH and Telnet programs specifically. Its syntax is as follows:
# ssh -l username remotehost
If you don’t specify a username with the -l option, the ssh command assumes that you want to use the name of the account with which you are locally logged in. For example, if you are logged in as the user ross and you execute the ssh command without the -l option, the command attempts to log you in as ross on the remote system.
For example, I could attach to the host mp3server as the user snuffy with this command:
# ssh -l snuffy mp3server
If I have not connected to this server before, I get a message similar to what’s shown here:
The authenticity of host 'mp3server (192.168.33.44)' can't be established. RSA key fingerprint is 73:4f:fa:b0:42:a4:3a:a8:64:2c:ad:26:1 d:b1: 21:e0. Are you sure you want to continue connecting (yes/no)?
If I answer yes, the host’s public key is added to my ~/.ssh/known_hosts file and looks something like this:
192.168.3.44 ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAIEA1gFIB9VQpFKWAZUzNM+ac/U81Tk9R8OCFfUkegVJXw j6nqCISPyV2iJwaukcVVaVAQ+JR3EhvOvh4PhoSg4yzBSUkJ8aUBYoRSGj7PCD+vyWyi19 22HGxWbWooMBAO/Was8I7N0zQ6jxDO9qNOHcrIFeU7qbOCrKjQDM08HQjk0=
Rather than work with RCP or FTP for file transfer work, I tend to use SCP. The scp command uses the SSH protocol and encrypts the files sent from one host to another host. For example, if I wanted to transfer file1 from my root user’s home directory on my machine to the same location on a host named remotehost, I could use the following command:
# scp /root/file1 root@remotehost:/root/file1
The system would prompt me with the RSA key question (as shown in the previous ssh example) if I have not connected to this system previously from this account. I would be prompted for the password, and then the system would transfer the files. The output from a file transfer looks like this:
# root@192.168.1.73's password: mypubkey.txt 100% |**********************| 1379 00:00
You can copy files from your host to another host, as shown previously, or copy files from a remote host to your system by reversing the source and target specifications.
You can even copy files from one remote system to another remote system. For example, the following command recursively copies the /data directory and all its contents from the remote1 host to the remote2 host after prompting you for the password for both hosts:
# scp -r root@remote1:/data root@remote2:/data
Another use of the SSH protocol is to log in to a host and use SSH to forward the output from an X client back to your display. This feature, which can be specifically invoked with the -x option, is referred to as an X11 tunnel.
SSH allows for skipping the password prompt when signing on between computers, which can be convenient if you use the ssh or scp command frequently and don’t mind the possibility that someone could sit down at your accidentally unlocked station and have her way with your network!
NOTE
There has been a lot of talk about why it’s important to delete .rhosts files from user directories. Basically, if you have a user who has a hostname in her .rhosts file and that host also has the user’s hostname in its /etc/hosts_equiv file, that user can log in without a password by using the rlogin command. This would be a security risk, so my advice is to delete these files with the following command:
# find /home -iname .rhosts -exec rm -f {} \;
This deletes all .rhosts files it finds in users’ home directories and does not prompt you for each deletion.
The following example shows the steps required to enable SSH use without a password. In this example I have two machines, fattyre and murphy, both of which are Linux workstations with the necessary SSH software loaded, as per the defaults. This demonstration assumes that fattyre and murphy are both in each other’s /etc/hosts files or resolvable via DNS.
Here’s how you can enable SSH use without passwords:
Step 1. Log in to fattyre as the root user.
Step 2. For this example, create a new user named user1:
useradd -m user1
Step 3. Set user1’s password with the passwd command to whatever you want:
passwd user1
Step 4. Switch to the user1 user account:
su - user1
Step 5. Create and set the permissions for the .ssh directory:
mkdir .ssh ; chmod 700 .ssh
Step 6. Generate an RSA key by using the ssh-keygen command:
ssh-keygen -b 1024 -t rsa
Step 7. When prompted for the location for the file, press Enter to accept the default.
Step 8. When prompted for a passphrase, enter
seatec astronomy
Step 9. Reenter the passphrase when prompted.
Step 10. Change to the .ssh directory and set the permissions on the id_rsa.pub file:
cd .ssh ; chmod 644 id_rsa.pub
Step 11. Copy the id_rsa.pub file to a new file called authorized_keys:
cp id_rsa.pub authorized_keys
Step 12. From the host murphy, ensure that you can contact the host fattyre with a ping:
ping fattyre
Step 13. Sign on to the host murphy as the root user.
Step 14. Add a user named user2:
useradd -m user2
Step 15. Set the password for user2:
passwd user2
Step 16. Enter the password twice to confirm it.
Step 17. Switch to the user2 account:
su - user2
Step 18. Make a directory and set its permissions with the following command:
mkdir .ssh ; chmod 700 .ssh
Step 19. From the host fattyre, connect to the murphy host as user2:
ssh -l user2 murphy
Step 20. When prompted about the RSA key, answer yes and then enter user2’s password.
Step 21. While logged in as user2 on the host murphy via SSH, copy the authorized_keys file from the fattyre host with the following command:
scp user1@fattyre:~/.ssh/authorized_keys ~/.ssh
The output of the scp program should look similar to this:
authorized_keys 100% |************************| 236 00:00
Step 22. Exit user2 on the host murphy and return to being user1 on fattyre.
Step 23. On fattyre as user1, invoke the ssh-agent as a wrapper to your shell:
ssh-agent $SHELL
Step 24. Add your key to the agent:
ssh-add
Step 25. When prompted for the passphrase, enter the following:
no more tears
You then see output similar to this:
Identity added: /home/ssha/.ssh/id_rsa (/home/ssha/.ssh/ id_rsa)
Step 26. Try to log in as user2 on murphy and watch what happens:
ssh -l user Murphy
You shouldn’t see any password prompt; you should see only the confirmation of where you last logged in from:
Last login: Wed May 26 13:46:55 from fattyre
Step 27. If you do see a prompt for the passphrase, enter no more tears as you did before.
This is all it takes to get two accounts and machines set up to use SSH utilities without having to enter anything but the ssh-agent command along with the passphrase. Remember that ssh-agent resides in memory and wraps a security blanket around your shell session, answering any SSH-related security requests for you. The ssh-add utility is for adding key information into the agent and doesn’t have to be run again as long as your key information remains the same.
Tunneling
One of the greatest features of SSH is that it can tunnel—provide a conduit from inside one network, and even behind a firewall, through to another network. In many cases, using tunneling can enable you to do things that either your network administrator doesn’t want you to do or you need to do because of an overly restrictive policy, such as at a coffee shop or Internet cafe.
Let’s talk about some of the various scenarios where tunneling can come in handy.
X11 Forwarding
X is complex and hard to set up sometimes, and it might seem that tunneling X from another machine to show on yours would be hard too, but X11 forwarding is fairly straightforward due to the magical properties of ssh tunneling.
Let’s say you have a Linux system named cygnusx1 on which you want to run an application in the GUI environment, but you want that application that runs on the remote host to display on your local system.
Here’s a possible set of steps you might take:
Step 1. On a Mac, download and install XQuartz (https:/www.xquartz.org).
Step 2. Run the command ssh -X ursulak@cygnusx1.
Step 3. After a shell opens in the terminal on the remote host (cygnusx1), run the app.
Step 4. In a second or two, the remote application, running as a process on the remote host, will display on your system as if it were being run locally.
This is just an example of how forwarding X11 applications from the host they are running on to your local system would work. All sorts of things could go wrong, but that topic is beyond the scope of the Linux+ exam. The main thing is to understand the concept of X11 forwarding, which we have more than adequately covered.
Port Forwarding
Port forwarding is typically used in scenarios in which there is a need to get around some overly strict or controlling network or firewall. Keep in mind, though, that often there are very good reasons for those restrictions and rules being in place, so be responsible and don’t willingly cause issues using port forwarding.
Using SSH to forward ports takes several paths, but the main concept is the same: you are using the ssh client on one system to tunnel out to the ssh server on another system and cause services that are represented by a port on the latter system to be mapped, or to appear to be connected, to the other system.
In general, port forwarding occurs in three main ways:
Local port forwarding: This enables you to cause a remote port to be mapped to, and to appear as if it were on, your local system. Kind of like mounting an NFS share locally, mapping a port from a remote system to yours locally effectively makes your local system appear as if it is providing that service.
Remote port forwarding: Flip the scenario around and allow your local system resources to be used by a remote machine. For example, I might map a remote system’s port 8080 to my local 5500 port, and anyone connecting to that remote server on the 8080 port will get transported to my local port and service.
Dynamic port forwarding: The term dynamic port forwarding, also known as dynamic SOCKS proxying, is a method used to securely tunnel network traffic through a remote server or proxy. Sometimes you don’t want to explicitly assign ports and just want the SOCKS proxy on your system to use dynamically assigned local ports and handle all the details. Think of a situation where you need to access ports and protocols that are not allowed through a convention center’s network setup. You can use what is effectively a VPN/proxy to drill through the local restrictive network stack and connect to and communicate freely with your desired target hosts, services, and ports.