A public key is public. Anyone can know it. I think you mean that you
want their private key on their own machine to be password protected.
No, that is on their own machine. They can do as they wish. There is
nothing in the negotiations between your machine and theirs which has
anything to do with the encryption or not of their private key on their
own system.
It's a long-standing problem and one of the user interaction flaws of
many password setting programs. They will, by default, allow you to
set a blank password. In theory, SSH and OpenSSH's client binaries
such as ssh-keygen could be modified to enforce password setting. But
as things stand, unless you have access to review and test their
private keys, there is no protection against this.
This is a particularly deadly problem with NFS shared or backup tape
stored private keys. As a matter of course, I tell backup systems
*not* to save ssh_rsa and ssh_dsa keys from people machines that I
backup, so that we're not confronted with having private keys without
passphrases on backup tapes, and not confronted with some weasel
grabbing them from backup tapes or NFS shares with a laptop blugged
into the network where "we trust the people we work with", and using
different SSH keys for different uses.
A more thorough solution is to get Kerberos enabled on both ends: Many
versions of OpenSSH and some clients now support Kerberos
authentication, quite effectively, and this does force a challenge
response with the Kerberos servers (or designated hosts), allows
authentication sharing across the Kerberos domain to provide the same
effect as SSH public keys. Doesn't work for the default version of
Putty (which does not yet suport GSSAPI) or with Subversion and svn
+ssh, darn it. But it does work well with git and SSH.
Thank you all for your responses. I had figured this was probably the
case but wanted to make sure I wasn't just overlooking something.