Top White Papers
O'Reilly: Top Ten Secure Shell FAQsJan 28, 2001, 19:07 (0 Talkback[s])
(Other stories by Richard Silverman)
"SSH, the Secure Shell, is a set of protocols and software that provide secure, remote terminal sessions between networked computers. In addition to a simple remote command prompt, most SSH implementations also provide secure forwarding of X Window traffic as well as forwarding of connections to arbitrary TCP ports. These features can protect otherwise insecure protocols such as POP, IMAP, SMTP, and so on. An SSH session applies cryptographically assured privacy and integrity protection as well as mutual authentication to the data passing through it. Used properly, SSH is an extremely valuable tool that helps users more safely navigate today's Internet and helps system administrators secure their networks or perform remote administration."
"1) I just installed OpenSSH, but password authentication is not working!
Many modern flavors of Unix use "PAM" for password authentication. PAM stands for Pluggable Authentication Modules. It is an abstract framework for performing accounting, authentication, and authorization (AAA). The idea is that programs can be written to use PAM instead of particular AAA methods. The system administrator can then customize AAA for different programs by changing the host's PAM setup. Existing services can use new AAA methods, without change, simply by reconfiguring PAM or adding a new PAM module to the system. For example, an IMAP server daemon might log its actions to /var/log/imapd.log, and authenticate clients via the Unix passwd map. If the daemon uses PAM for this, the system administrator can direct that PAM instead log its actions via syslog, and employ Kerberos for user authenticatation. The IMAP server software need not have been written with explicit support for either of these features, so long as it uses PAM. ..."
"2) I use particular combinations of SSH command-line options all the time when connecting to various server hosts. Is there a way to automate this, other than using shell-command aliases?
Yes. Use labeled sections in the SSH client-configuration file. For instance:
# ~/.ssh/config (SSH1 or OpenSSH) Host foo.bar.com User slade PasswordAuthentication no LocalForward 2143 localhost:143With this bit of configuration, if you give the command ssh foo.bar.com, SSH will behave as if you had instead typed:
ssh -l slade -L 2143:localhost:143 -o PasswordAuthentication=no foo.bar.comNote that the labeled section is only used if the label matches the hostname you give to SSH on the command line, verbatim."
0 Talkback[s] (click to add your comment)