You might be able to get a working shell with something like "ssh $MACHINE sh -i"; you won't have job control, but it might be enough to find out something useful. Or perhaps it will work to do "ssh $MACHINE $COMMAND"? A poor substitute for a real shell, but a lot better than nothing.
I don't ever get to the point where I'm asked for a password.
I'm having trouble coming up with a failure mode that will let the pty driver work enough to accept ^T-generated output, pass it to sshd, and have sshd work enough to get the data out over the network, but have enough things wedge to give the symptoms you're seeing. Maybe exit() is what's wedging? Depending on your shell startup files, this may stop even "ssh $MACHINE $COMMAND" from working....
The shell startup files are the default NetBSD ones with a setenv for CVSROOT, so I doubt it's them. In the past, while NetBSD 4 was still pre-release, I saw this problem a few times, and while I have no idea whether it's the same or even related, it was interesting: non-I/O programs such as top continued to run even though all other programs and all other ssh sessions would lock when they'd try to touch disk. For instance, hitting return on an empty shell would give me a prompt, but the first (non-built-in) command I'd try to run would hang that ssh session.
I'll see if it happens again after using the system for a while. This time, the ADB keyboard will be left plugged in, though.
John