ssh are using ssh-userauth but ignores private key

Works for me, using ssh-agent:
debug1: Next authentication method: publickey
debug1: Offering public key: meuh-rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Server accepts key: pkalg ssh-rsa blen 277
debug2: input_userauth_pk_ok: fp <snipp>
debug3: sign_and_send_pubkey
debug1: Authentication succeeded (publickey).

Jaunty ssh-client ssh-server 1:5.1p1-5ubuntu1

I have 2 systems with this problem and 1 where it works as expected.

I have a system running Jaunty Beta AMD64 with ssh 1:5.1p1-5ubuntu1.

I have two private keys, both of which are valid in a number of remote servers. If I copy one of the keys to ~/.ssh/id_rsa everything works correctly. If I copy the other key to ~/.ssh/id_rsa it does not work within gnome using seahorse and ssh-agent, but it does work from a non-Gnome session. Both keys work correctly in Intrepid. Both keys were originally generated using PuttyGen on Windows. Looking at the trace at the end of this response, does seahorse have an issue if the key is only 1023 bits instead of 1024?

It works from a non-Gnome session:
Ctrl-Alt-F2
Login using Username/Password,
$ ssh server.example.com
<Enter passphrase for key /home/user/.ssh/id_rsa>
Connects correctly.

But it doesn't work within Gnome:
Start Gnome Terminal
$ ssh server.example.com
<Gnome dialog box pops up asking for passphrase>
Permission denied (publickey,gssapi-with-mic).

$ ssh -vvv server.example.com
<snip>
debug1: Offering public key: /home/user/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Server accepts key: pkalg ssh-rsa blen 148
debug2: input_userauth_pk_ok: fp ed:<snip>
debug3: sign_and_send_pubkey
debug1: Authentications that can continue: publickey,gssapi-with-mic
debug1: Trying private key: /home/user/.ssh/identity
debug3: no such identity: /home/user/.ssh/identity
debug1: Trying private key: /home/user/.ssh/id_dsa
debug3: no such identity: /home/user/.ssh/id_dsa
debug2: we did not send a packet, disable method
debug1: No more authentication methods to try.
Permission denied (publickey,gssapi-with-mic).

For comparison, using the same key in the terminal session (i.e. no ssh-agent, no seahorse):
debug1: Offering public key: /home/user/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Server accepts key: pkalg ssh-rsa blen 148
debug2: input_userauth_pk_ok: fp ed:<snip>
debug3: sign_and_send_pubkey
debug1: PEM_read_PrivateKey failed
debug1: read PEM private key done: type <unknown>
Enter passphrase for key '/home/user/.ssh/id_rsa':
debug1: read PEM private key done: type RSA
debug1: Authentication succeeded (publickey).

Also, using the same key in the terminal session but using ssh-agent (still no seahorse):
$ eval `ssh-agent`
Agent pid 25343
$ trap "kill $SSH_AGENT_PID" 0
$ ssh-add ~/.ssh/id_rsa
Enter passphrase for /home/user/.ssh/id_rsa:
Identity added: /home/user/.ssh/id_rsa (/home/user/.ssh/id_rsa)
$ ssh -vvv server.example.com
<snip>
debug1: Offering public key: /home/user/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Server accepts key: pkalg ssh-rsa blen 148
debug2: input_userauth_pk_ok: fp ed:<snip>
debug3: sign_and_send_pubkey
debug1: Authentication succeeded (publickey).

Finally, using the "good" key that works inside Gnome:
In Gnome, start Gnome Terminal
$ ssh -vvv server.example.com
<snip>
debug1: Offering public key: /home/user/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Server accepts key: pkalg ssh-rsa blen 149
debug2: input_userauth_pk_ok: fp <snip>
debug3: sign_...

@rancor

Can you try your key that doesn't work using ssh-agent in a non-Gnome session, either by switching to a different TTY or by ssh'ing into the Jaunty box from elsewhere (without Agent Forwarding: ssh -a ...)?

It might be that the problem is with seahorse rather than openssh-client, given my key works outside Gnome but not inside it, regardless of whether I use ssh-agent or ssh -i

Roger

Reading https://bugs.launchpad.net/ubuntu/+source/gnome-keyring/+bug/339097 it looks like gnome-keyring is acting as the ssh-agent, so maybe the problem is with that rather than seahorse.

Roger

Duplicate of what??

@rancor: Bug #353759 was marked as being a duplicate of this (your) bug.

@andol, ah :p tnx

@Roger Hunwicks: "ssh-agent bash", then "ssh-add <private key>" works from a new tty

Not an ssh bug, but rather a seahorse or gnome-keyring regression, opening related tasks and marking regression-potential.

Thank you for taking the time to report this bug and helping to make Ubuntu better. Please answer these questions:

 * Is this reproducible?
 * If so, what specific steps should we take to recreate this bug?

 This will help us to find and resolve the problem.

@Sebastien Bacher: I don't know how to create this issue. I just upgraded 8.10 to 9.04 on three machines and two of them have this problem, the other works fine. I haven't tweaked anything manually. The only thing I can think of is that the machines has been upgraded several times. 8.04 -> 8.10 -> 9.04

I will be happy to answer and make other changes to test what's wrong if somebody gives me questions or instructions

Regards rancor

it would be nice if somebody having the issue could open the bug on bugzilla.gnome.org where the people writting the code will actually read it, there is no ubuntu triager knowing that code well enough to debug that easily

the ssh agent is gnome-keyring

I will now open a new bug on bugzilla.gnome.org

Posted a new bug: http://bugzilla.gnome.org/show_bug.cgi?id=577842

Thank you for your sending the bug there

Thank you for sending the bug to GNOME

Seems this is not triaged at all, since there's no reproduction recipe and it does not happen for a lot of people. Robert, could you please have a look at this and try to find a reproducer/solution? Thanks!

rancor: Do you still have the same setup that you used to generate the keys? If possible could you try and generate some new keys (ideally one that fails and one that works) and attach them to this bug?

I think, but I am not sure, that this is reported upstream already at http://bugzilla.gnome.org/show_bug.cgi?id=576700

Also (just for tracking) Debian bug http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=524018

I have not read all post, but I think I have found the reason of this.
I have two keys. One works without problems, the other don't work.
The correct working key is a dsa key. The rsa key don't work.

I hope this will help a little bit.

The reported workaround by taking the ssh agent out of the loop by putting this in your .bashrc :

export SSH_AUTH_SOCK=

at least makes my keys usable again. Still annoying that I have to type my passphrase every time now, but at least I can access my machines again.

@Robert Ancell: I haven't tried SSH since the problem started, I must do some test and return to you

I can reproduce the behavior reported by rancor, but using an RSA 1023-bit key. I have never had problems with ssh-agent before I upgraded to Jaunty. I can still login using "ssh -i mykey", but never with ssh-agent.

When I tried to generate a new RSA 2048-bit key, ssh-agent worked without a problem for it. However, when I generated a 1023-bit key by using "ssh-keygen -b 1023", ssh-agent fails again. I am attaching an example key (without a passphrase). It would be great if someone can confirm the problem for this key.

Attaching the public key corresponding to the private key above

could you also comment on the GNOME bug?

My experiences are as follows:
Ubuntu 9.04
Logged into GNOME as a user
copy existing id_rsa file to ~/.ssh/ and do a chmod 700 on it.
(Keyfile being used here is 4096 bit RSA)
open terminal and issue the following:
$ ssh-add
Returns: "Enter passphrase for /home/<me>/.ssh/id_rsa:" (or something to that effect)
I enter the proper passphrase, then issue:
$ ssh root@192.168.0.1
I am then prompted for the passphrase to open /home/<me>/.ssh/id_rsa again. Every time.

In the past, issuing ssh-add meant the key's passphrase would no longer be required for that session (That's how it worked in Debian Etch). In Ubuntu 8.10, I actually never needed to issue ssh-add... the gnome password manager just asked for it the first time and that's it. I don't know much more about it or what more logs I can pull, but if somebody would post the locations of any applicable logs I would be happy to post them. Also, in case it is relevant, I upgraded to 9.04 from an existing 8.10 system, so I don't know if this occurs on new builds, but it definitely occurs after an upgrade. Also I've tried this as multiple users and have the same results. Thanks.

Trifon, thanks for the keys. I've tried the following:

1. Create two new user accounts on my machine (up-to-date Jaunty) for users test1 and test2
2. Copy rsa1023.pub to /home/test1/.ssh/authorized_keys2
3. Copy rsa1023 to /home/test2/.ssh/id_rsa and set permissions to 600
4. Open GNOME session as test2 and ssh to test1

Result:
The SSH login completes successfully without prompting for a password

Is this what you have tried?

Explicitly the commands I've used are:
test1@localhost$ mkdir ~/.ssh
test1@localhost$ cp rsa1023.pub ~/.ssh/authorized_keys2
test2@localhost$ mkdir ~/.ssh
test2@localhost$ cp rsa1023 ~/.ssh/id_rsa
test2@localhost$ chmod 600 ~/.ssh/id_rsa
test2@localhost$ ssh test1@localhost

Thank you Robert for taking the time to test this. The sequence you described works correctly for me as well. However, I don't think this goes through ssh-agent, I think ssh looks in ~/.ssh/id_rsa without using the agent at all.

Here's the sequence that doesn't work for me (using your notation)

test1@localhost$ mkdir ~/.ssh
test1@localhost$ cp rsa1023.pub ~/.ssh/authorized_keys2
test2@localhost$ cp rsa1023 ~
test2@localhost$ chmod 600 ~/rsa1023
test2@localhost$ ssh-add rsa1023
test2@localhost$ ssh test1@localhost

I copied my ~/.ssh/id_rsa to ~/.ssh/identity and this problem suddenly disappeared. I upgraded from 8.04->8.10->9.04 recently.

I looked at the debug output and it was sending the key over, but for some reason it wasn't working.

@ Robert Ancell :
Curious, was this RSA key you used password-protected? Because I see the same results as you saw with a non-protected key, but this problem still persists with all users on my 9.04 system with a protected key.

Jon, I agree the upstream bug is a duplicate and have now marked it as such. The correct upstream bug is:
http://bugzilla.gnome.org/show_bug.cgi?id=576700
Trifon, thanks - the steps you have given reproduce it perfectly for me. I have updated the upstream bug with this test case
sideshowmel, I used the keys as provided by Trifon - they are not password protected.

To recreate the problem that I am seeing, you MUST use a password-protected private key. Mine is 4096-bit RSA, but I've done a bit of searching and see this is happening for users with 1024 and 2048 bit RSA keys as well.

sideshowmel: I'm not sure of the difference between your case and Trifon's case. If it is different please generate keys and instructions that reproduce it and post those to the upstream bug. Thanks.

This bug was fixed in the package gnome-keyring - 2.26.3-0ubuntu1

---------------
gnome-keyring (2.26.3-0ubuntu1) karmic; urgency=low

  * New upstream version:
    - Fix problem with RSA key sizes that are not a multiple of 8.
      This affected use of SSH keys in particular. (lp: #348126, #347860)

 -- Sebastien Bacher <email address hidden> Fri, 10 Jul 2009 14:41:12 +0200