Secure Shell
Secure shell plays an essential part in allowing field systems to transfer data securely back to ATD from remote locations and from outside the NCAR firewall. This section gives a basic overview of how it works and gives some hints on troubleshooting.
Besides being used for secure data transfers, secure shell is also now the only way to login into the ISS workstation remotely. telnet and rsh have been disabled along with all other inetd services. Use ssh -l iss hostname instead.
Overview of Secure Shell
 | Parts of this section have been adapted from the PPP configuration memo by Charlie Martin. |
Secure shell is both a secure networking protocol and a set of tools (for example the ssh command) which implement remote login shells and other utilities using a secure protocol. The protocol provides for encryption of all data, such as login passwords, and it can use publickey cryptography for authorization and authentication. Publickey cryptography uses a pair of keys which are related by a complicated mathematical computation. The keys are large numbers and randomly generated. One key cannot be derived from the other, and data encrypted by one key can then be decrypted only by the other key. One key is kept private and the other, called the public key, is available publically.
Secure shell is very easy to use. First a user creates a pair of keys using the ssh-keygen program. The keys are stored in the .ssh directory under the user's home directory. The private key is kept in the file identity, while the public key resides in the file identity.pub. Remote users can be given permission to login to a local account by adding the remote user's public key to the local account's authorized_keys file. Once a public key has been authorized in the authorized_keys file, the owner of the matching private key may login to the local machine using secure shell without password authentication. The login is authenticated using the keys, and all traffic between the machines is encrypted. Remote command execution, similar to rsh, can be executed securely and non-interactively as well. The syntax of the ssh is nearly identical to rsh, and secure shell provides a similar secure replacement for rcp called scp. The ISS uses the scp command to transfer data files.
The ISS workstation uses secure shell to perform all data transfers. The ISS workstation in each facility is essentially a copy of the same system, so the iss account at each site uses the same keys. The public key from the iss account on the field machines has been added to the authorized_keys file for the iss account on the ATD network. This allows the field systems to login remotely, transfer data, and then run a script at home to receive the new data, all from scripts run periodically in the background without user interaction or passwords.
Troubleshooting Secure Shell
One of the best tools for troubleshooting ssh is its verbose option, -v. With -v, ssh gives many helpful messages about the kinds of authentication it is attempting and which are succeeding or failing. A successful ssh login from an iss field account generates the output included below. Other successful logins should look similar to this one.
131 iss2:/iss/etc/init.d> id uid=6000(iss) gid=100(iss) 132 iss2:/iss/etc/init.d> ssh -v atd SSH Version 1.2.26 [sparc-sun-solaris2.6], protocol version 1.5. Standard version. Does not use RSAREF. iss2: Reading configuration data /etc/local/ssh_config iss2: ssh_connect: getuid 6000 geteuid 0 anon 0 iss2: Connecting to atd [128.117.80.208] port 22. iss2: Allocated local port 1023. iss2: Connection established. iss2: Remote protocol version 1.5, remote software version 1.2.27 iss2: Waiting for server public key. iss2: Received server public key (768 bits) and host key (1024 bits). iss2: Host 'atd' is known and matches the host key. iss2: Initializing random; seed file /iss/home/iss/.ssh/random_seed iss2: Encryption type: idea iss2: Sent encrypted session key. iss2: Installing crc compensation attack detector. iss2: Received encrypted confirmation. iss2: Trying rhosts or /etc/hosts.equiv with RSA host authentication. iss2: Remote: Rhosts/hosts.equiv authentication refused: client user 'iss', server user 'iss', client host 'iss2.atd.ucar.edu'. iss2: Server refused our rhosts authentication or host key. iss2: No agent. iss2: Trying RSA authentication with key 'iss@iss2' iss2: Received RSA challenge from server. iss2: Sending response to host key RSA challenge. iss2: Remote: RSA authentication accepted. iss2: RSA authentication accepted by server. iss2: Requesting pty. iss2: Failed to get local xauth data. iss2: Requesting X11 forwarding with authentication spoofing. iss2: Requesting shell. iss2: Entering interactive session. |
One possible message is that the destination account has incorrect file permissions. ssh requires strict permissions in the destination account to ensure security. For example, a user's account cannot be secure if someone besides the user can edit the authorized_keys file. Likewise what is the point of a private key if someone other than the user can read it? The required permissions are mostly common sense: make sure the identity file can only be read by the user (mode 0400) and the authorized_keys file can only be read and written by the user (mode 600). Further, the .ssh directory itself, as well as the user's home directory, can only be writable by the user, otherwise other users could rename and replace the .ssh directory or its files.
Other problems may arise due to host keys. Besides authenticating with the publickey pair of keys, ssh also generates and keeps track of keys for each host. This allows authentication based on trusted hosts, similar to the use of root .rhosts or hosts.equiv files. It also provides some protection against host masquerading. The host key on the ATD exposed host is not supposed to change, but sometimes system administration scripts break or the host key is accidentally regenerated. When this happens, ssh from the field machines will be interrupted because the ATD host suspiciously no longer has the same key as it did the last time ssh logged into it. In this case, the systems group needs to be informed of the problem. If the ATD host key has not changed, then there may be a bigger, security-related problem.
Security Concerns
It needs to be noted that even though ssh and scp are vast improvements over the older methods of cleartext password authentication and batch ftp with .netrc, secure shell is still insecure. The field machines are very exposed and dozens of people know the password for the iss account and hence have access to the private key. The private key is all that is needed to log into the ATD iss account.
For these reasons, it is a good idea to frequently regenerate the secure shell keys for the ISS workstations, remembering to update the authorized_keys in the ATD account with the new public key before the machines go to the field. Do not forget to remove the older keys from the authorized_keys file, else the key regeneration is useless!
Though not yet implemented, it would probably be a good idea to run data transfers as root. Root account access on the ISS workstation is still widespread, but not nearly as widespread as for the iss account. Also, the root account password can be changed without affecting operators who have already learned the iss password.