can't ssh out; seahorse-agent seems dead
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| seahorse (Ubuntu) |
New
|
Undecided
|
Unassigned | ||
Bug Description
Binary package hint: seahorse
Running uptodate feisty i386, i have a problem with seahorse-agent (1.0.1-0ubuntu1). This bug may be related to the following, but doesn't quite look like a duplicate:
https:/
https:/
and I am also having a problem with gnome-session:
https:/
i'm currently working around this issue using the "run valgrind on it and the problem disappears" fix detailed in that bug report. I haven't noticed any other session-related issues persisting, but this ssh issue did first appear around the same time that my session started acting out, so there may still be some connection.
symptoms: when i try to ssh out from this machine, ssh hangs waiting for authentication:
~$ ssh -vv localhost
OpenSSH_4.3p2 Debian-8ubuntu1, OpenSSL 0.9.8c 05 Sep 2006
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to localhost [127.0.0.1] port 22.
debug1: Connection established.
debug1: identity file /home/matt/
debug2: key_type_from_name: unknown key type '-----BEGIN'
debug2: key_type_from_name: unknown key type '-----END'
debug1: identity file /home/matt/
debug1: identity file /home/matt/
debug1: Remote protocol version 2.0, remote software version OpenSSH_4.3p2 Debian-8ubuntu1
debug1: match: OpenSSH_4.3p2 Debian-8ubuntu1 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-
debug2: fd 3 setting O_NONBLOCK
debug1: An invalid name was supplied
Configuration file does not specify default realm
debug1: An invalid name was supplied
A parameter was malformed
Validation error
debug1: An invalid name was supplied
Configuration file does not specify default realm
debug1: An invalid name was supplied
A parameter was malformed
Validation error
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit: diffie-
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-
debug2: kex_parse_kexinit: aes128-
debug2: kex_parse_kexinit: hmac-md5,
debug2: kex_parse_kexinit: hmac-md5,
debug2: kex_parse_kexinit: none,<email address hidden>,zlib
debug2: kex_parse_kexinit: none,<email address hidden>,zlib
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: kex_parse_kexinit: diffie-
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-
debug2: kex_parse_kexinit: aes128-
debug2: kex_parse_kexinit: hmac-md5,
debug2: kex_parse_kexinit: hmac-md5,
debug2: kex_parse_kexinit: none,<email address hidden>
debug2: kex_parse_kexinit: none,<email address hidden>
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: mac_init: found hmac-md5
debug1: kex: server->client aes128-cbc hmac-md5 none
debug2: mac_init: found hmac-md5
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: SSH2_MSG_
debug1: expecting SSH2_MSG_
debug2: dh_gen_key: priv key bits set: 125/256
debug2: bits set: 522/1024
debug1: SSH2_MSG_
debug1: expecting SSH2_MSG_
debug1: Host 'localhost' is known and matches the RSA host key.
debug1: Found key in /home/matt/
debug2: bits set: 539/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_
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_
-------
the workaround for this behaviour is to su - <username>, and the issue seems to be the ssh-agent environment variables:
matt@gont:~$ env | grep -i ssh
SSH_AGENT_PID=6136
SSH_AUTH_
matt@gont:~$ su - matt
Password:
matt@gont:~$ env | grep -i ssh
matt@gont:~$ ssh localhost
matt@localhost's password:
-------
unsurprisingly, seahorse doesn't seem to actually be running:
matt@gont:~$ ps aux | grep seahorse
matt 6037 0.0 0.0 2664 644 ? S May01 0:00 /usr/bin/
matt 16313 0.0 0.0 2884 772 pts/3 S+ 09:02 0:00 grep seahorse
matt@gont:~$ ps aux | grep 6136
matt 16320 0.0 0.0 2880 760 pts/3 S+ 09:02 0:00 grep 6136
matt@gont:~$
-------
so apparently seahorse is crashing and not informing the session that it's crashed. can i look anywhere for log information to find out when and how it's crashed? and is there a known workaround? thanks,
matt
| Dan Lenski (lenski) wrote Ditto. | #1 |
| Jesse Hallett (hallettj) wrote | #2 |
| Dan Lenski (lenski) wrote | #3 |
I have the same problem here. Sometimes seahorse crashes, and then ssh seems not to work. My workaround is to blank out the ssh-agent variables on the command line:
$ SSH_AGENT_PID= SSH_AUTH_SOCK= ssh wherever
It's a really frustrating bug, because ssh doesn't work and gives no indication why unless you do ssh -v. Otherwise it just waits forever. I wish there was a way to tell GNOME that seahorse has crashed, and to restart it and update the environment variables for new shells.