I don't think this is a new problem, but I can't find a solution anywhere, and it's quite annoying:
In the office, I have a workstation running Debian Lenny with Gnome, and I've copied my ssh key to some other machines for secure and easy login without havin' to remember all the passwords.
Of course, my key is protected by a passphrase, so, when I try to login to one of the other machines, a window pops up, and asks me for the passphrase.
So far, so good, as long as I'm sitting at my desk this works perfectly well - but, sometimes I have to work remotely, so, I login (also by ssh) to my office workstation, and here's the problem:
I can't unlock my ssh key from remote, it seems that something (ssh-agent? Gnome keyring?) "controls" the key and prevents unlocking. The ssh client even asks me to enter the passphrase, but it's not accepted...
Any ideas? Can it be because I'm always logged in at work, and only locking the screen when I leave my desk?
Usually the ssh-agent shouldn't block access, as it should only be enabled for processes started from within GNOME.
Could you give a more detailed description of your setup? Location and name of SSH keys, relevant connection commands, whether or not X11 forwarding is enabled, ...
and finally, here's a trace of a try to establish the connection from the office system:
hhuseman@bofh:~/.ssh$ ssh -v hhuseman@frodo
OpenSSH_4.7p1 Debian-2, OpenSSL 0.9.8g 19 Oct 2007
debug1: Reading configuration data /home/hhuseman/.ssh/config
debug1: Applying options for frodo
debug1: Applying options for *
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to frodo.dh9dat.de [85.214.78.129] port 22.
debug1: Connection established.
debug1: identity file /home/hhuseman/.ssh/identity type -1
debug1: identity file /home/hhuseman/.ssh/id_rsa type 1
debug1: identity file /home/hhuseman/.ssh/id_dsa type 2
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.1p1 Debian-5
debug1: match: OpenSSH_5.1p1 Debian-5 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_4.7p1 Debian-2
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'frodo.dh9dat.de' is known and matches the RSA host key.
debug1: Found key in /home/hhuseman/.ssh/known_hosts:1322
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Trying private key: /home/hhuseman/.ssh/identity
debug1: Offering public key: /home/hhuseman/.ssh/id_rsa
debug1: Authentications that can continue: publickey
debug1: Offering public key: /home/hhuseman/.ssh/id_dsa
debug1: Server accepts key: pkalg ssh-dss blen 434
debug1: PEM_read_PrivateKey failed
debug1: read PEM private key done: type <unknown>
Enter passphrase for key '/home/hhuseman/.ssh/id_dsa':
debug1: read PEM private key done: type <unknown>
Enter passphrase for key '/home/hhuseman/.ssh/id_dsa':
debug1: PEM_read_PrivateKey failed
debug1: read PEM private key done: type <unknown>
Enter passphrase for key '/home/hhuseman/.ssh/id_dsa':
(The system is first trying the RSA-key which is blacklisted on the target server 'cause is vulnerable - but I'm still using it on some internal systems, so I can't remove it. And, it should be harmless AFAIK, as the "right" DSA-key is tried afterwards).
I hope these informations help to bring some more light into the dark,
Yes, it's helpful, especially the last few lines in the debug output. It's asking for the passphrase protecting the private key ~/.ssh/id_dsa. If it shouldn't do that, there are 2 possible problem sources: you're using a different key pair (the .bofh key maybe), in which case you can specify it with the -i option.
Or you've used special characters when you entered the passphrase, in which case it might get ugly. Check that your terminals language settings are the same as in your GNOME environment, and that the connection program you're using supports that input method (probably UTF-8)
thanks again for the reply, I've checked your suggestions:
First, id_dsa is the right key, the others are backups I've made during my tests since I suspected a problem with the key.
I've copied the DSA key pair again from my private machine, to ensure it's the right one - the result is the same, I can't unlock the key.
And, there are no special characters in the passphrase, I've typed it on the remote machine's console, and it's shown okay - so, I think the problem is not related to character sets or key encoding...
Nevertheless, here's a debug output of a successful login from my private system:
hhuseman@gimli:~$ ssh -v frodo
OpenSSH_5.1p1 Debian-5ubuntu1, OpenSSL 0.9.8g 19 Oct 2007
debug1: Reading configuration data /home/hhuseman/.ssh/config
debug1: Applying options for frodo
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to frodo [85.214.78.129] port 22.
debug1: Connection established.
debug1: identity file /home/hhuseman/.ssh/identity type -1
debug1: identity file /home/hhuseman/.ssh/id_rsa type 1
debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048
debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048
debug1: identity file /home/hhuseman/.ssh/id_dsa type 2
debug1: Checking blacklist file /usr/share/ssh/blacklist.DSA-1024
debug1: Checking blacklist file /etc/ssh/blacklist.DSA-1024
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.1p1 Debian-5
debug1: match: OpenSSH_5.1p1 Debian-5 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.1p1 Debian-5ubuntu1
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'frodo' is known and matches the RSA host key.
debug1: Found key in /home/hhuseman/.ssh/known_hosts:20
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Offering public key: /home/hhuseman/.ssh/id_dsa
Here, a window pops up asking for the passphrase of the DSA key
debug1: Server accepts key: pkalg ssh-dss blen 434
debug1: Authentication succeeded (publickey).
debug1: Local connections to LOCALHOST:2812 forwarded to remote address 127.0.0.1:2812
debug1: Local forwarding listening on ::1 port 2812.
debug1: channel 0: new [port listener]
debug1: Local forwarding listening on 127.0.0.1 port 2812.
debug1: channel 1: new [port listener]
debug1: channel 2: new [client-session]
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug1: Requesting X11 forwarding with authentication spoofing.
debug1: Sending environment.
debug1: Sending env LANG = de_DE.UTF-8
debug1: Remote: No xauth program; cannot forward with spoofing.
Linux h1685471.stratoserver.net 2.6.18-028stab064.7 #1 SMP Wed Aug 26 13:11:07 MSD 2009 i686
The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
You have new mail.
Last login: Sun Apr 4 16:23:35 2010 from p5b0130f3.dip0.t-ipconnect.de
hhuseman@h1685471:~$ debug1: client_input_channel_req: channel 2 rtype keepalive@openssh.com reply 1
hhuseman@h1685471:~$
the debugger says you are not in the group
make the user part of the group and try
and the success connection is from the same machine if i am not wrong?
Sorry, but the only way I could repeat your problem was by entering the wrong passphrase for the key when asked. Loading the key into the authentication agent (gpg-agent) didn't lock it in any way (it wasn't even opened, checked with lsof).
hm, well, now that's interesting: I have generated a new key, and now I can unlock it with my passphrase on the office system...
So, I will replace my key, and I think this will solve the problem. But, why can I use the passphrase to unlock the key when the Gnome agent asks for it??
Nevertheless, I think we can close this thread, :-).
Thanks to all who answered, and kind regards from Germany,