 |  |
| |
telnet was the original application for connecting to a remote machine via the Internet. (rsh was developed as a quick hack because telnet wasn't quite ready, and so became popular enough to be included in distributions going forward, but telnet was always supposed to be the "real" application.) In its normal mode, telnet connects to an inetd (Section 46.5)-managed daemon called telnetd, which manages the login process.
Unfortunately, the login process happens entirely in cleartext, as does all interaction with the remote shell program. Anyone tapping into the connection could get access to the user's password and thus gain illicit access to the remote system. To prevent this, Secure Shell (SSH) was developed. SSH uses Secure Sockets Layer (SSL), the same security mechanism that web browsers use. All interactions between your machine and the remote machine are encrypted, thus protecting your passwords and any other sensitive information. Its syntax is much like rsh's:
% ssh gabriel Logs into gabriel using your local username. % ssh [email protected] Logs into bits.oreilly.com using the login name deb. % ssh michael ls /tmp Runs ls /tmp on michael. % ssh deb@eli grep deb /etc/passwd Runs grep deb /etc/passwd on eli, using the login name deb.
SSL uses public key encryption, which means that connections are protected with operations based on a public/private key pair. Information encrypted with the public key can be decoded with the private key and vice versa. A server runs sshd, which, much like telnetd, accepts connections and manages the login process. (Unlike telnetd, sshd is generally not managed by inetd, because sshd's startup is complex and thus too slow to do every single time a connection is created. Because of this limitation, sshd has access rules much like tcp_wrappers' built in -- generally by just linking with tcp_wrappers.) Each server has its own public/private key pair, allowing a user connecting to that server to verify its identity. This allows you to be sure that someone hasn't managed to redirect your connection to their machine instead (where they could collect your password, for example).
You can also set up your own keypair using ssh-keygen, which will create an identity for you. Usually this identity is stored in $HOME/.ssh/identity (for the private key) and $HOME/.ssh/identity.pub (for the public key). Some newer versions of SSH have different keytypes and so use id_rsa/id_rsa.pub, and id_dsa/id_dsa.pub instead. The advantage to having an identity set up is that you can then allow that identity to log in to other machines without a password, much like .rhosts allowed with rsh, only more securely. Simply add your public key to the $HOME/.ssh/authorized_keys file on the remote host.
SSH also provides a simple file copy mechanism, scp. Login is the same as with ssh; identities are used if available, or password exchanges are encrypted. scp's syntax is much like cp's, except that an account specification can be prepended to a filename:
% scp gabriel:buffoon.txt . % scp frobnitz deb@michael:/tmp
The first command copies buffoon.txt from my home directory on gabriel into the current directory. The second copies frobnitz in the current directory into michael's /tmp directory, logging in as deb.
I configure my machines to disallow telnet and rsh access, and I use SSH exclusively.
-- DJPH
|  | |
| 46.5. The Director of Operations: inetd |  | 46.7. Configuring an Anonymous FTP Server |
Copyright © 2003 O'Reilly & Associates. All rights reserved.