Workbook 10 Chapter 8. Remote Shell Commands

1. Workbook 10Chapter 8.  Remote Shell Commands Pace Center for Business and Technology

2. Chapter 8.  Remote Shell Commands Key Concepts • Remote shell applications allow users to execute arbitrary commands on remote machines, and have standard out returned locally. Alternately, an interactive shell can be started. • The Secure Shell application provides a remote shell, where all transactions are encrypted, and users can be authenticated by traditional passwords or using a public key authentication scheme. • In order to use the public key authentication scheme, a public- private key pair must be generated with the ssh-keygen command. • Because Secure shell servers have their own public-private key pairs, servers can be authenticated to clients as well as clients authenticated to servers.

3. The Original Remote Shell: rsh and Rhosts Authentication Remote Shells with rsh Linux (and Unix) shells are intentionally designed with simple interfaces: they read input from the standard in stream, and deliver output to the standard out stream. As a result, the interfaces are easily implemented over network connections. By simply substituting a TCP socket for a terminal device, a shell can operate on a remote machine as easily as the local machine. In Linux (and Unix), applications which provide this functionality are referred to as remote shells. The first commonly used Unix remote shell was the simple rsh application. If a remote machine is properly configured (i.e., it is running the RSH server), users can use a rsh command to invoke a remote shell.

4. The Original Remote Shell: rsh and Rhosts Authentication Translating, this command says "as the user elvis on the host server1, run the command ls /tmp". The command executes on the remote machine (server1), but standard out is delivered to the local machine (station). When the command completes, elvis's prompt implies that he is still on the host station. If elvis does not specify a command to run, the rsh utility would opens an interactive shell on the remote host server1. By paying close attention to the bash prompt in the following excerpt, note which commands execute on which machine.

5. Rhosts Authentication: ~/.rhosts In each case, elvis did not need issue a password. Before he could access his remote account using rsh, however, elvis needed to configure the account to allow him access from his local machine. For rsh, access control configuration is as trivial as adding a line to a file. On the remote account, elvis created the file ~/.rhosts, and added one line containing the hostname and username for each external account which he wanted to grant access. Additionally, the RSH server requires that the file's permissions prohibit anyone but the user owner from reading the file. As the following commands illustrate, elvis has already configured his .rhosts file on the remote machine. Authentication which relies on a properly configured ~/.rhosts configuration file is commonly called rhosts authentication.

6. The Secure Shell The rhosts authentication method is pitiful. At its essence, it relies on DNS (Domain Name Service) to authenticate a user. In order to exploit elvis's ~/.rhosts configuration, all someone would have to do is detach the real host station from the network, and bring up another machine configured with station's IP address. The fault is not elvis's, but the design of the rhost authentication protocol. Additionally, rsh is a plaintext protocol. Exchanging data over a network in plaintext is essentially the equivalent to sending mail on postcards: anyone handling the data between here and there is privy to its contents. The Secure Shell was developed to address both of these shortcomings of the rsh command, and add significant new capabilities, while still providing all of rsh's convenience. Assuming the remote machine is running the ssh service (i.e., the sshd daemon), elvis could invoke a shell on the remote machine with the following.

7. The Secure Shell The ssh command's new syntax for specifying the username of the remote account is slightly easier than is rsh's, although the -l command line switch is also implemented (in order to be fully backwards compatible). In the above example, elvis is authenticated by providing a password instead of configuring a ~/.rhosts file. In the next section, we find that the Secure Shell can use a more mature public key technique to grant users "password free" access to an account. When public key authentication is not implemented, however, ssh falls back to traditional password authentication. [2]

8. Secure Shell Public Key Authentication In addition to traditional password authentication, the Secure Shell application can use public key cryptography to authenticate users. Public key encryption algorithms relate two large numbers, referred to as "keys", so that information encrypted with one key can only be decrypted with the other. Anyone who wants to use public key cryptography must first generate a pair of keys. Most public key protocols call one key a public key, and the complementary key a private key. Your public key you treat like your phone number: you share it with anyone with whom you are willing to communicate, and may choose to list it in public directories. Your private key, on the other hand, you share with no one. All of the security provided by public key protocols relies on the fact that only you know the contents of your private key.

9. Generating a Public-Private Key Pair: ssh-keygen When using ssh, a user's public-private key pair can be generated with the ssh-keygen command. In the following example, elvis uses ssh-keygen to generate a ssh public-private key pair. The user elvis was first prompted for the new (private) key's filename, to which elvis simply hit RETURN to accept the default filename: ~/.ssh/id_rsa. Next, elvis was given the opportunity to attach a passphrase to his private key. By hitting RETURN again (twice), elvis chose not to. (We will discuss passphrases in more detail later.)

10. Generating a Public-Private Key Pair: ssh-keygen When the command returns, elvis has two new files in his (perhaps newly created) ~/.ssh directory. The first is his private key, which he shares with no one. (He certainly doesn't publish it in an online text). He is free to share his second key (the public key) with anyone whom asks.

11. Allowing Account Access: ~/.ssh/authorized_keys SSH access to an account is granted by obtaining a copy of the public key of the person who is to be granted access, and storing it in the account's ~/.ssh/authorized_keys file. Like the ~/.rhosts file, the ~/.ssh/authorized_keys file, and the whole ~/.ssh directory, must only be readable by the user. How the copy of the public key is obtained does not matter. It could be emailed, scped (as discussed in a moment), or transferred from one terminal to another using the mouse's cut and paste buffer.

12. Allowing Account Access: ~/.ssh/authorized_keys When handling public keys, however, care must be taken to ensure that the key is placed in the file with no embedded whitespace, including newlines. Although too long to be displayed as such, SSH public keys are always stored as a single line of text. More people can be granted access to an account by simply appending their public keys to the ~/.ssh/authorized_keys files, one public key per line.

13. Allowing Account Access: ~/.ssh/authorized_keys In the following example, elvis uses ssh, redirection, and some carefully placed quotes to append his public key (on the host station) to the authorized_keys file in his account on the host serer1. Okay, so we need to make the .ssh directory first. Why the quotes? With no quotes, the output of the cat command would have been appended to the file .ssh/authorized_keys on the local machine. The quotes serve to pass the redirection syntax "into" the remote shell.

14. Allowing Account Access: ~/.ssh/authorized_keys Having placed his public key in the ~/.ssh/authorized_keys file on the remote machine, elvis now expects to be able to examine the contents of the file without having to issue a password. Something is amiss, because elvis was again prompted for his password. Recalling that only the user should be able to access the ~/.ssh directory and read the ~/.ssh/authorized_keys file, elvis implements the appropriate chmod command on the remote machine. Afterwords, he is able to observe the new permissions without having to issue a password. Success.

15. Public Key Authentication Details In order to develop an appreciation for the robustness of public key authentication, we will spend a few moments discussing the protocol. When the secure shell application implements public key authentication, it uses a procedure similar to the following. In our discussion, the following symbols will be used.

16. Public Key Authentication Details First, the ssh client on the host station requests a connection to the sshd daemon on the host server1. Upon receiving the connection request, the sshd daemon looks for a registered public key in the destination account's ~/.ssh/authorized_keys file. If a relevant public key is discovered, the sshd daemon initiates public key authentication by generating a random string R. It then encrypts the random string with elvis's public key P (which it obtains from the ~/.ssh/authorized_keys file), and delivers the encrypted random string P(R) over the network to the ssh client.

17. Public Key Authentication Details Upon receiving the encrypted random string P(R), the ssh client uses elvis's private key S to decrypt it. Once the original random string R is recovered, the ssh client returns it to the sshd daemon.

18. Public Key Authentication Details If the sshd daemon receives from the ssh client the same random string with which it started, the client is authenticated, and the connection is allowed to continue.

19. Public Key Authentication Details A couple of aspects of this algorithm deserve mentioning. The ssh client is authenticated not by a hostname or IP address, and not by a password, but solely by the possession of the private key. (If the client could not access the appropriate private key, it would not have been able to decrypt the encrypted random string passed to it.) The only information passed over the network is an encrypted random string, and a random string (the symbols colored red in the accompanying figures). Anyone eavesdropping on the conversation would not learn anything useful. In practice, the actual algorithm used is more complicated. But the protocol outlined above illustrates the most important features of the public key authentication protocol

20. Transferring Files Securely and Easily: scp As the previous discussion illustrates, files can be transferred from one machine to another using ssh with the cat command and careful redirection. Fortunately, there is an easier and less error prone way: scp. The scp command uses a syntax almost identical to the cp command, but either the source file(s) or the destination file can be on a remote machine, accessed through a specified account. [3] When referring to a file on a remote machine, the following syntax is used. The user and host are simply enough the host where the file resides, and the user whose account is used to access the file. If the file's path begins with a “/”, it is considered an absolute reference. If not, it is considered relative to the user's home directory. If no path is supplied, the user's home directory is assumed. As an example, the following command line would transfer the /etc/services file from server1 into the ~/cfg/server1/etc/ directory in elvis's home directory.

21. Transferring Files Securely and Easily: scp Because elvis has a properly configured public key authentication with his account on server1, he is able to transfer the file without issuing a password. What happens if he tries to transfer the file /etc/shadow? The user elvis on the host server1 does not have permissions to read the file /etc/shadow, so the file can naturally not be transferred. If the user elvis knows the password to the root account on the remote machine, however, the file could be accessed through it. Because elvis does not have public key authenticated access to the root account on server1, ssh used traditional password authentication.

22. Transferring Files Securely and Easily: scp The -r command line switch (for "recursive") must be specified when copying an entire directory (and its subdirectories). In the following, elvis recursively copies the /etc/sysconfig directory from his local machine (station) to the machine server1's /tmp directory. As the scp command performs the transfer, it displays transfer timing information for each file.

23. Secure Shell Host Authentication The first time the ssh (or scp) client is used to connect to a sshd Secure Shell server, a message similar to the following is displayed. If the user answers yes (the only answer which will allow the connection to continue), the connection proceeds, with the following warning. On subsequent connections, the message is no longer seen.

24. Secure Shell Host Authentication The Secure Shell not only authenticates clients to servers, but also servers to clients, using public key authentication. Just as users can create public-private key pairs with the ssh-keygen command, the sshd daemon maintains its own public-private key pair, known as its host key. The first time a ssh client connects to a sshd daemon, it appends a copy of the remote daemon's public host key to the local file ~/.ssh/known_hosts. As the client is used to connect to various machines, the ~/.ssh/known_hosts file grows, recording one public key for each machine contacted. The next time the client connects to a host, it silently uses the same public key protocol used to authenticate users, reversed, to authenticate the host to which it is connecting.

25. Secure Shell Host Authentication What if the remote host does not posses the same identity which complements the public key stored in the client's ~/.ssh/known_hosts file? The client refuses to connect, and instead issues the following warning.

26. Secure Shell Host Authentication Often, there is a very reasonable explanation why the server has changed identity. For example, the server might have been upgraded with a more recent version of its operating system, and as a result, generated a new host public-private key pair. If a reasonable explanation for the change in identity is available, the ssh client can be convinced to connect by removing the offending line from the ~/.ssh/known_hosts file, and "starting over" by collecting a new key for the host.

27. Secure Shell Host AuthenticationLAB http://csis.pace.edu/adelgado/rha-030/labs/workbook10/chapter-8/ssh-no-keys.htm