As befits its detail- and variation-rich subject, this book comprises many specialised sections, each dealing with some specific aspect of use or configuration (setting up access control at the account level, for example, or generating keys for a particular SSH server). The writing is both informative and fun to read; the authors switch back and forth between text and entry-and-response listings from SSH machines. They often run through a half-dozen or more variants on the same command in a few pages, providing the reader with lots of practical information. The discussion of how SSH fits into a Kerberos Public Key Infrastructure (PKI) is great, as is the advice on defeating particular kinds of attacks. --David Wall
- The Secure Shell (SSH) for installers, administrators, and everyday users
- SSH design and operation
- Server setup
- SSH agents
- Client configuration
- Public Key Infrastructure (PKI) integration
- OpenSSH for Unix
- SSH1 and SecureCRT for Microsoft Windows
- NiftyTelnet SSH for Mac OS
From the Publisher
About the Author
Dan Barrett has been immersed in Internet technology since 1985. Currently working as a software engineer, Dan has also been a heavy metal singer, Unix system administrator, university lecturer, web designer, and humorist. He has written several O'Reilly books, as well as monthly columns for Compute! and Keyboard Magazine. Dan and his family reside in Boston.
Richard E. Silverman has a B.A. in computer science and an M.A. in pure mathematics. Richard has worked in the fields of networking, formal methods in software development, public-key infrastructure, routing security, and Unix systems administration. He is the co-author of SSH, The Secure Shell: The Definitive Guide.
Excerpt. © Reprinted by permission. All rights reserved.
In this chapter:
Limits of This Technique
Public Key-Based Configuration
Trusted-Host Access Control
The User rc File
We've seen two techniques for controlling the SSH server's behavior globally: compile-time configuration (Chapter 4) and serverwide configuration (Chapter 5). These techniques affect all incoming SSH connections to a given server machine. Now it's time to introduce a third, finer-grained method of server control: per-account configuration.
As the name implies, per-account configuration controls the SSH server differently for each user account on the server machine. For example, a user account sandy can accept incoming SSH connections from any machine on the Internet, while rick permits connections only from the domain verysafe.com, and fraidycat refuses key-based connections. Each user configures his or her own account, using the facilities highlighted in Figure 8-1, without needing special privileges or assistance from the system administrator.
We have already seen a simple type of per-account configuration. A user may place a public key into her authorization file, instructing the SSH server to permit logins to her account by public-key authentication. But per-account configuration can go further, becoming a powerful tool for access control and playing some fun tricks with your account. Accepting or rejecting connections by particular keys or hosts is just the beginning. For instance, you can make an incoming SSH connection run a program of your choice, instead of the client's choice. This is called a forced command, and we'll cover quite a few interesting applications.
Per-account configuration may control only incoming SSH connections to your account. If you're interested in configuring outgoing SSH connections by running SSH clients, refer to Chapter 7.
Limits of This Technique
Per-account configuration can do many interesting things, but it has some restrictions that we will discuss:
It can't defeat security measures put in place by compile-time or serverwide configuration. (Thank goodness.)
It is most flexible and secure if you use public-key authentication. Trusted-host and password authentication provide a much narrower range of options.
Overriding Serverwide Settings
SSH settings in a user's account may only restrict the authentication of incoming connections. They can't enable any SSH features that have been turned off more globally, and they can't permit a forbidden user or host to authenticate. For example, if your SSH server rejects all connections from the domain evil.org, you can't override this restriction within your account by per-account configuration.
This limitation makes sense. No end-user tool should be able to violate a server security policy. However, end users should be (and are) allowed to restrict incoming connections to their accounts.
A few features of the server may be overridden by per-account configuration. The most notable one is the server's idle timeout, which may be extended beyond the serverwide setting. But such features can't coerce the server to accept a connection it has been globally configured to reject.
If you are an end user, and per-account configuration doesn't provide enough flexibility, you can run your own instance of the SSH server, which you may configure to your heart's content. Be cautious, though, since this is seldom the right thing to do. The restrictions you're trying to circumvent are part of the security policy defined for the machine by its administrators, and you shouldn't run a program that flouts this policy just because you can. If the machine in question is under your administrative control, simply configure the main SSH server as you wish. If not, then installing and running your own sshd might violate your usage agreement and/or certainly annoy your sysadmin. And that's never a wise thing to do.
To make the best use of per-account configuration, use public-key authentication. Password authentication is too limited, since the only way to control access is with the password itself. Trusted-host authentication permits a small amount of flexibility, but not nearly as much as public-key authentication.
If you're still stuck in the password-authentication dark ages, let this be another reason to switch to public keys. Even though passwords and public-key passphrases might seem similar (you type a secret word, and voilà, you're logged in), public keys are far more flexible for permitting or denying access to your account. Read on and learn how.