There is one exception to this rule: trusted-host authentication. A user's ~/.shosts file may override a restriction placed by the system administrator in /etc/shosts.equiv. [Section 8.3, "Trusted-Host Access Control "][Section 126.96.36.199, "Trusted-host authentication (Rhosts and RhostsRSA)"]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. [Section 5.2.2, "Running as an Ordinary User"] 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.
|7.6. Summary||8.2. Public Key-Based Configuration|
Copyright © 2002 O'Reilly & Associates. All rights reserved.