In IDS, a user is only allowed to manage his own SSH authorized keys. The ability for an Administrator to manage the SSH authorized key lists for all users on the sensor has been suggested (CSCeg30182) and will be implemented in a future release.
A user of any privilege level can manage his own SSH authorized keys. Since the authorized key only grants access to the account in which it is created, it is functionally equivalent to the password of the account.
The private key is equivalent to a password, but has the advantage that it can be used without ever being transmitted over the network. The most significant security improvement in using an SSH authorized key is that if your client ends up connecting with an attacker SSH server that is impersonating the IDS sensor, it does not divulge the credential. The attacker will not be able to use any information gleaned from the attack to log into the real IDS sensor.
I understand your concern about users distributing their private key to unauthorized persons. I do not think that a user deserving of trust will intentionally share their private key; but it is much easier to intentionally share a password than a private key -- so I do not see how preventing said user from using SSH authentication adds any security.
There are numerous ways a private key might be unintentionally revealed if the owner fails to properly safeguard it. There are some protections in various SSH agents that make it more difficult for a user to store their private keys insecurely. For example, SSH clients that work with private keys stored in ~/.ssh/authorized_keys enforce the Unix file permissions on the file itself and the containing directory. OpenSSH clients won't use authorized keys if the permissions of the file are not 0600 (user read-write, no group or other access).
In many organizations, user home directories are NFS mounted. This means that private keys stored in NFS exported directories are exposed to any user with root on any trusted host. To work around this, users should create symbolic links from ~/.ssh to a directory in local storage on the hosts where SSH authorized keys are used.
Users should encrypt the private keys with passphrases; however, this is not enforceable. With passwords, we at least have cracklib and other means to enforce your organization's security policy. I frequently suggest that users use a passphrase identical to the password the SSH RSA authentication replaces. This makes the passphrase easier to remember, retains the same entropy level as enforced for passwords and does not increase the assets exposed if the passphrase should later be stolen. However, there are information security professionals who would argue against using the same passphrase for more than one purpose under any circumstances.
Windows users have a bit more difficulty protecting their private keys. PuTTY provides the puttygen tool, which encrypts the private keys it generates when they are stored. However, it provides no enforcement of the passphrase's length or entropy.
Additionally, users must be aware that for optimum security, a private key must never be transmitted over a network or written to removable media.
Therefore, if you use PuTTY as your SSH client, use puttygen -- the bundled SSH keypair generator -- on the same host. If you use OpenSSL, use ssh-keygen. Never copy a private key to a different host from the one on which it was generated.
To summarize, information security staff continue to rely on end users to voluntarily participate. My suggestion is to publish a detailed policy for the proper creation, use and handling of private keys; train end users; and perform random audits to monitor compliance. I welcome your suggestions for enhancements that make the system more secure.
Thanks for pointing out the discrepancies in the user documentation. These will be corrected in a future release.
