gnome-keyring upgrade
On nevada 99, you can get the new gnome-keyring 2.22 which supports ssh agent. This may cause a conflict with Solaris ssh-agent started in /usr/dt/config/Xsession.jds. A patch will be given to remove ssh-agent from Xsession.jds.
gnome-key-daemon is started by gnome-session when you log into the desktop, then some passwords of applications such as Evolution, pidgin can be managed by gnome-keyring. A master password can be used to protect the default keyring. That means you don't need to type any password for every application. After you type the master password, gnome-keyring can work for you to input those applications' passwords.
The sensitive information such as your passwords, login names etc. are not stored as plain texts. Instead, they are encrypted in AES with the key generated by MD5 on your keyring passwords. So it is safe when the file is transfered via NFS.
All keyrings are stored at $HOME/.gnome2/keyring. If you don't want to keep those key rings, you can remove these files.
The issue that I often thought about these days is that whether passwords are transfered in plain text in SSH. The answer is no. Three authentication ways are there in SSH --- "password", "public keys" and "host keys". For the "password", first Differ Hellman key-exchange is used so a session key is produced to encrypt the password. But for "password" authentication, it cannot prevent 'man-in-the-middle' attack. "public keys" can solve this problem because the method is based on PKI. When you ssh to a box, the public key of the host will be saved. When you log in a second time, the client will check the host keys so it knows whether it is the real host.
You are a little confused on the ssh authentication. SSH has two different layers of authentication. First there is authentication of the server by the client done at the transport layer an encrypted connection is then setup using the algorithms the pair negotiated. Normally this is a server public key (but could also be done using GSS-API with Kerberos creds). The ssh client stores the pubkey of the server in the known_hosts file to protect against man in the middle on subsequent connections. Authentication of the user then happens over the encrypted transport. This is SSH userauth. Users can be authenticated using either "password", "keyboard-interactive" (an interactive question answer - this is the default on Solaris to support PAM), "pubkey" or "gssapi" (there are actually two gssapi flavours depending on how the hostauth was done). There is not distinction on the man in the middle protection between the "password" or "pubkey" userauth methods. If an out of band secure mechanism for distributing system wide known_hosts files is used then even the initial connection is protected from a MiTM attack. Or if the host authentication is done using GSS-API since host Kerberos creds would be needed.
Posted by Darren Moffat on July 22, 2008 at 07:04 PM CST #