Limits of This Technique

Per-account configuration can do many interesting things, but it has some restrictions that we will discuss:

Per-account configuration (highlighted parts)

Figure 8-1. Per-account configuration (highlighted parts)

  • 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. Hostbased and password authentication provide a much narrower range of options.

8.1.1 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.[118]

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 ...

Get SSH, The Secure Shell: The Definitive Guide, 2nd Edition now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.