SSH, The Secure Shell: The Definitive Guide, 2nd Edition

Scalable Authentication for SSH

One of the main strengths of SSH is easy setup. Install an SSH server on one host and a client on another, and you immediately have secure login via password. Generate a key pair and put the public key on the server, and you immediately have even better authentication, and single-signon. This lightweight approach is one of the main reasons for the initial popularity of SSH.

No solution fits all situations, however, and this simplicity becomes a liability as the number of users and hosts grows. In large installations, managing both server and user authentication becomes difficult. Every time you add an SSH server host, or change its name, or add an alias for it, you must update the global known-hosts list. This by itself may be a practically impossible task, because there are no standards for representing these lists. OpenSSH uses one format, Tectia another; some Windows-based clients keep them in a file, some in the registry. Even if you had a means to generate lists for all your SSH clients in their various native formats, many of the actual client machines may be unreachable for updates (remote machines, laptops, etc.).

At all too many companies, the difficulty of managing SSH server keys leads to a very lax approach to server verification. Users frequently see warning messages about missing or changed keys, and the IT staff tells them to “just accept the new key.” Very soon, these messages are completely ignored by everyone—or worse, just made to ...