can not login using ssh anymore

Bug #328277 reported by Christian Roessner
46
This bug affects 4 people
Affects Status Importance Assigned to Milestone
GNOME Keyring
Unknown
High
gnome-keyring (Fedora)
Fix Released
Medium
gnome-keyring (Ubuntu)
Fix Released
Low
Ubuntu Desktop Bugs

Bug Description

Hi,

I do not know, what happened today, but some upgrades seem to have broken my ssh client. I can not use ssh to login to my remote server from jaunty client to jaunty server. Both sides are up-to-date.

croessner@desktop ~/.ssh $ cat config
#
# Default settings
#
Host *
    Compression yes
    ForwardAgent yes
    ForwardX11Trusted yes
    ServerAliveInterval 30
    Ciphers aes256-cbc
    MACs hmac-sha1
    ControlMaster auto
    ControlPath /home/croessner/.ssh/%h:%p

ssh -v roessner1.roessner-net.de
OpenSSH_5.1p1 Debian-5ubuntu1, OpenSSL 0.9.8g 19 Oct 2007
debug1: Reading configuration data /home/croessner/.ssh/config
debug1: Applying options for *
debug1: Applying options for roessner1.roessner-net.de
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: auto-mux: Trying existing master
debug1: Control socket "/home/croessner/.ssh/roessner1.roessner-net.de:216" does not exist
debug1: Connecting to roessner1.roessner-net.de [85.10.196.195] port 216.
debug1: Connection established.
debug1: identity file /home/croessner/.ssh/identity type -1
debug1: identity file /home/croessner/.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/croessner/.ssh/id_dsa type 2
debug1: Checking blacklist file /usr/share/ssh/blacklist.DSA-2048
debug1: Checking blacklist file /etc/ssh/blacklist.DSA-2048
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.1p1 Debian-5ubuntu1
debug1: match: OpenSSH_5.1p1 Debian-5ubuntu1 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 aes256-cbc hmac-sha1 <email address hidden>
debug1: kex: client->server aes256-cbc hmac-sha1 <email address hidden>
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<4096<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 '[roessner1.roessner-net.de]:216' is known and matches the RSA host key.
debug1: Found key in /home/croessner/.ssh/known_hosts:462
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
buffer_get_ret: trying to get more bytes 4 than in buffer 0
buffer_get_int: buffer error

I also have a intrepid laptop. From there I still can login, so it is not a problem on the server.

I tried to kill seahorse-* and ssh-agent, but this does not solve the problem. This is critical for me.

Revision history for this message
In , John (john-redhat-bugs) wrote :

Description of problem:
Some rawhide update today broke ssh, but I can't work out what! I tried backing down openssh to an earlier release, but that didn't fix it. Reporting against openssh anyway.

As a regular user, ssh fails with:
   buffer_get_ret: trying to get more bytes 4 than in buffer 0
   buffer_get_int: buffer error

(Really helpful error message, NOT! Try googling for:
  "buffer_get_ret: trying to get more bytes 4 than in buffer 0"
to see how common it is!)

As root, ssh to the same target works.

Version-Release number of selected component (if applicable):
openssh-5.1p1-6.fc11.x86_64

How reproducible:
100%

Steps to Reproduce:
1.ssh -vvv bock
2.
3.

Actual results:
...
debug1: Host 'bock' is known and matches the RSA host key.
debug1: Found key in /home/ellson/.ssh/known_hosts:57
debug2: bits set: 514/1024
debug1: ssh_rsa_verify: signature correct
debug2: kex_derive_keys
debug2: set_newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug2: set_newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
buffer_get_ret: trying to get more bytes 4 than in buffer 0
buffer_get_int: buffer error

Expected results:
1. Working ssh.
2. Greatly improved errors messages!

Additional info:

Revision history for this message
In , John (john-redhat-bugs) wrote :

The problem seems to be caused by my id_dsa key ??? Removing that and the id_rsa key works fine.

I use that dsa key in a lot of places, so I don't want to remove it permanently.
Whats going on?

A working rsa public key:

debug1: ssh_rsa_verify: signature correct
debug2: kex_derive_keys
debug2: set_newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug2: set_newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: /home/ellson/.ssh/id_rsa (0x2880550)
debug3: input_userauth_banner

Same site, with the id_dsa & id_dsa.pub restored into .ssh/

debug1: ssh_rsa_verify: signature correct
debug2: kex_derive_keys
debug2: set_newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug2: set_newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
buffer_get_ret: trying to get more bytes 4 than in buffer 0
buffer_get_int: buffer error

Revision history for this message
In , Tomas (tomas-redhat-bugs) wrote :

What have you upgraded - client or server? What is the openssh version on the other end? What happens if you do 'unset SSH_AUTH_SOCK' before running the ssh client?

Revision history for this message
In , Tomáš (tom-redhat-bugs-1) wrote :

Same here, today's rawhide, cannot connect from client to server.

client:
openssh-5.1p1-6.fc11.x86_64
openssl-0.9.8j-7.fc11.x86_64
glibc-2.9.90-3.x86_64
gcc-4.4.0-0.16.x86_64

server:
openssh-5.1p1-6.fc11.i386
openssl-0.9.8j-6.fc11.i686
glibc-2.9.90-3.i686
gcc-4.3.2-7.i386

Removing ~/.ssh/known_hosts didn't help.

Unsetting SSH_AUTH_SOCK helped.

$ echo $SSH_AUTH_SOCK
/tmp/keyring-c543Ad/socket.ssh

So... this looks like gnome-keyring error :-/

Revision history for this message
In , Tomas (tomas-redhat-bugs) wrote :

Yes, if unsetting SSH_AUTH_SOCK helps and it points to gnome-keyring and not regular ssh_agent it is gnome-keyring bug.

Revision history for this message
In , John (john-redhat-bugs) wrote :

Using ssh from a ssh login session, without a desktop and with no SSH_AUTH_SOCK
set, works ok. When I get back home tonight I'll see if SSH_AUTH_SOCK
is set and if unsetting it helps me, but that seems likely based on Comment #4.

Revision history for this message
In , John (john-redhat-bugs) wrote :

Oh yes, only my client was updated to fc11 rpms. The servers are all fc10
or less.

Revision history for this message
In , John (john-redhat-bugs) wrote :

Confirming "unset SSH_AUTH_SOCK" fixes the issue for me too.

Revision history for this message
Christian Roessner (christian-roessner-net) wrote :

Interesting thing is that I can use the root user to login to remote:

desktop ~ # ssh roessner1.roessner-net.de
Enter passphrase for key '/root/.ssh/id_rsa':

0 packages can be updated.
0 updates are security updates.

Last login: Thu Feb 12 10:07:38 2009 from ip-81-210-196-220.unitymediagroup.de
roessner1 support@roessner1 ~ $ logout
Connection to roessner1.roessner-net.de closed.

desktop ~ # cd .ssh/
desktop ~/.ssh # l
insgesamt 44
drwx------ 2 root root 4096 2009-02-12 10:07 ./
drwxr-xr-x 25 root root 4096 2009-02-09 21:05 ../
-rw-r--r-- 1 root root 1001 2009-02-12 10:07 config
-rw------- 1 root root 1264 2008-07-18 10:39 id_dsa
-rw-r--r-- 1 root root 1718 2008-07-18 10:39 id_dsa.keystore
-rw-r--r-- 1 root root 1119 2008-07-18 10:39 id_dsa.pub
-rw------- 1 root root 1743 2008-07-18 10:39 id_rsa
-rw-r--r-- 1 root root 630 2008-07-18 10:39 id_rsa.keystore
-rw-r--r-- 1 root root 393 2008-07-18 10:39 id_rsa.pub
-rw-r--r-- 1 root root 4420 2009-01-25 11:45 known_hosts

desktop ~/.ssh # diff -Naur id_rsa /home/croessner/.ssh/id_rsa
desktop ~/.ssh # diff -Naur id_rsa.pub /home/croessner/.ssh/id_rsa.pub
desktop ~/.ssh # diff -Naur id_dsa.pub /home/croessner/.ssh/id_dsa.pub
desktop ~/.ssh # diff -Naur id_dsa /home/croessner/.ssh/id_dsa

So, why is the root user able to use the rsa-Key and the "normal" user not?

By the way: With the normal user I can not login to any remote machine anymore.

Revision history for this message
Christian Roessner (christian-roessner-net) wrote :

This is one of the last upgraded packages. Maybe there is a bug inside

Revision history for this message
Christian Roessner (christian-roessner-net) wrote :

So, right after posting this, I rebooted the machine. After that I did use tty1 to login as croessner. I _could_ login to my machine.

After that I used gdm to login into Gnome, opened a terminal and it produced the given bug. So there really seems to be something inside the Gnome-environment that causes problems.

Revision history for this message
Christian Roessner (christian-roessner-net) wrote :

printenv | grep -i ssh
SSH_AGENT_PID=5056
SSH_AUTH_SOCK=/tmp/keyring-YC9x5B/socket.ssh

ssh roessner1.roessner-net.de
buffer_get_ret: trying to get more bytes 4 than in buffer 0
buffer_get_int: buffer error

export SSH_AUTH_SOCK=/tmp/ssh-HHLwWQ4999/agent.4999

ssh-add
Enter passphrase for /home/croessner/.ssh/id_rsa:
Identity added: /home/croessner/.ssh/id_rsa (/home/croessner/.ssh/id_rsa)
Identity added: /home/croessner/.ssh/id_dsa (/home/croessner/.ssh/id_dsa)

After that ssh roessner1.roessner-net.de works.

Revision history for this message
Sebastien Bacher (seb128) wrote :

Thank you for your bug report, the error is similar to http://bugzilla.gnome.org/show_bug.cgi?id=571060

Changed in gnome-keyring:
assignee: nobody → desktop-bugs
importance: Undecided → Low
status: New → Triaged
Revision history for this message
Adamson H (adamson) wrote :

I have this problem with my Jaunty (both local sshd and remote sshd).

$ ssh localhost
buffer_get_ret: trying to get more bytes 4 than in buffer 0
buffer_get_int: buffer error

However, I don't have such a problem with Places -> Connect to Server -> SSH ...

Revision history for this message
Stefan Lesicnik (stefanlsd) wrote :

I am also affected. Seems to be a problem with gnome-keyring or similar as the problem does not occur from the console.

The steps listed above by Christian also resolved it temporarily for me.

Removing the .ssh directory also does it. (although you probably don't want to delete you private key).

Revision history for this message
Eugene Crosser (crosser) wrote :

I am affected, too, cannot ssh to anywhere from gnome session. The problem is apparently in gnome-keyring-daemon that has been recently updated. ssh does work if I break its connection with the agent:

SSH_AUTH_SOCK= ssh localhost
Enter passphrase for key '/home/crosser/.ssh/id_rsa':
Linux pccross 2.6.28-7-generic #20-Ubuntu SMP Mon Feb 9 15:42:34 UTC 2009 x86_64

In case it helps somebody, I am attaching strace of the gnome-keyring-daemon when it ssh command is issued.

Eugene

Revision history for this message
Sebastien Bacher (seb128) wrote :

there is no need to keep adding comment there, the bug has been confirmed and sent to GNOME

Revision history for this message
In , Matthias (matthias-redhat-bugs) wrote :

What version of gnome-keyring ?
What arch ?

Revision history for this message
In , John (john-redhat-bugs) wrote :

gnome-keyring-2.25.90-4.fc11

x86_64

I can't reproduce this bug on a similarly equipped i386 box.

Revision history for this message
In , John (john-redhat-bugs) wrote :

Reverting to gnome-keyring-2.25.5-1.fc11.x86_64 make ssh work again, although
it gives an error message:

ellson@ontap:Desktop> ssh penguin
Error reading response length from authentication socket.
Last login: Fri Feb 13 20:43:53 2009 from ontap.ellson.com
ellson@penguin:~>

Revision history for this message
In , Matthias (matthias-redhat-bugs) wrote :

Can you retry with 2.25.91 ?
It contains some more 64bit fixes.

Revision history for this message
In , John (john-redhat-bugs) wrote :

Everything seems to work with gnome-keyring-2.25.91-1.fc11.x86_64

Thanks

Revision history for this message
Timo Aaltonen (tjaalton) wrote :

apparently fedora has a fixed package, so I hope the fix is pulled in soon :)

Changed in gnome-keyring:
status: Unknown → Fix Released
Revision history for this message
Sebastien Bacher (seb128) wrote :

the bug should be fixed in the new 2.25.91 version uploaded to jaunty, closing the bug, reopen if that's still an issue for you though

Changed in gnome-keyring:
status: Triaged → Fix Released
Changed in gnome-keyring:
status: Unknown → Incomplete
Revision history for this message
Eugene Crosser (crosser) wrote :

Subsequent update fixed the problem for me (jaunty).

Revision history for this message
In , Einer (einer-redhat-bugs) wrote :

Hey Guys, the bug is back in version gnome-keyring-2.26.1-1.fc11.x86_64

Symptoms/process same as above postings.

Fedora 11 x86_64

Einer

Revision history for this message
L.D. Paniak (ldpaniak) wrote :

I am seeing this bug in Karmic (2.6.31-16-generic #53 AMD64) just after a recent upgrade. The problem and workaround(s) are exactly as described above. It looks like this bug is back.

Changed in gnome-keyring:
importance: Unknown → High
status: Incomplete → Unknown
Changed in gnome-keyring (Fedora):
importance: Unknown → Medium
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.