thr3ads.net - openssh unix dev - Segmentation fault on public key authentification [Mar 2005]

If this information is useful, please help other people find it:
Share via:

Daniel Khan

2005-Mar-15 10:23 UTC

Segmentation fault on public key authentification

Hello list,

after some weeks of operation and updates one server of mine needed a 
reboot.
Now authentification with public key causes a segfault.

System information:

2.6.8-gentoo-r4 x86_64 AMD Dual Opteron(tm) Processor 242 AuthenticAMD

Debugging information:

// ssh fom node2 to node1

# ssh -vvv node1
OpenSSH_3.9p1, OpenSSL 0.9.7d 17 Mar 2004
debug1: Reading configuration data /etc/ssh/ssh_config
debug2: ssh_connect: needpriv 0
debug1: Connecting to node1 [192.168.0.100] port 22.
debug1: Connection established.
debug1: permanently_set_uid: 0/0
debug3: Not a RSA1 key file /root/.ssh/identity.
debug2: key_type_from_name: unknown key type '-----BEGIN'
debug3: key_read: missing keytype
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug2: key_type_from_name: unknown key type '-----END'
debug3: key_read: missing keytype
debug1: identity file /root/.ssh/identity type 2
debug1: identity file /root/.ssh/id_rsa type -1
debug1: identity file /root/.ssh/id_dsa type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_3.9p1
debug1: match: OpenSSH_3.9p1 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_3.9p1
debug2: fd 3 setting O_NONBLOCK
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit: 
diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: 
aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc
at lysator.liu.se,aes128-ctr,aes192-ctr,aes25
debug2: kex_parse_kexinit: 
aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc
at lysator.liu.se,aes128-ctr,aes192-ctr,aes25
debug2: kex_parse_kexinit: 
hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at
openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: 
hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at
openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit: none,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-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: 
aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc
at lysator.liu.se,aes128-ctr,aes192-ctr,aes25
debug2: kex_parse_kexinit: 
aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc
at lysator.liu.se,aes128-ctr,aes192-ctr,aes25
debug2: kex_parse_kexinit: 
hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at
openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: 
hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at
openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit: none,zlib
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_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug2: dh_gen_key: priv key bits set: 134/256
debug2: bits set: 518/1024
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug3: check_host_in_hostfile: filename /root/.ssh/known_hosts
debug3: check_host_in_hostfile: match line 2
debug3: check_host_in_hostfile: filename /root/.ssh/known_hosts
debug3: check_host_in_hostfile: match line 2
debug1: Host 'node1' is known and matches the RSA host key.
debug1: Found key in /root/.ssh/known_hosts:2
debug2: bits set: 524/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
debug2: key: /root/.ssh/identity (0x556370)
debug2: key: /root/.ssh/id_rsa ((nil))
debug2: key: /root/.ssh/id_dsa ((nil))
debug1: Authentications that can continue: publickey,keyboard-interactive
debug3: start over, passed a different list publickey,keyboard-interactive
debug3: preferred publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering public key: /root/.ssh/identity
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
Connection closed by 192.168.0.100


// SSH Logfile on node1:
Mar 15 11:21:14 [sshd] debug1: rexec start in 4 out 4 newsock 4 pipe 6 
sock 7
Mar 15 11:21:14 [sshd] debug1: Forked child 1817.
Mar 15 11:21:14 [sshd] debug1: inetd sockets after dupping: 3, 3
Mar 15 11:21:14 [sshd] Connection from 192.168.0.200 port 37281
Mar 15 11:21:14 [sshd] debug1: Client protocol version 2.0; client 
software version OpenSSH_3.9p1
Mar 15 11:21:14 [sshd] debug1: match: OpenSSH_3.9p1 pat OpenSSH*
Mar 15 11:21:14 [sshd] debug1: Enabling compatibility mode for protocol 2.0
Mar 15 11:21:14 [sshd] debug1: Local version string SSH-2.0-OpenSSH_3.9p1
Mar 15 11:21:14 [sshd] debug1: PAM: initializing for "root"
Mar 15 11:21:14 [sshd] debug1: PAM: setting PAM_RHOST to "node2"
Mar 15 11:21:14 [sshd] debug1: PAM: setting PAM_TTY to "ssh"
Mar 15 11:21:14 [sshd] debug1: temporarily_use_uid: 0/0 (e=0/0)
Mar 15 11:21:14 [sshd] debug1: trying public key file 
/root/.ssh/authorized_keys
Mar 15 11:21:14 [sshd] debug1: restore_uid: 0/0
Mar 15 11:21:14 [sshd] debug1: temporarily_use_uid: 0/0 (e=0/0)
Mar 15 11:21:14 [sshd] debug1: trying public key file 
/root/.ssh/authorized_keys2


// Messagelog on node1:
Mar 15 11:21:14 [sshd] Connection from 192.168.0.200 port 37281
Mar 15 11:21:14 [kernel] sshd[1817]: segfault at 0000000000000003 rip 
0000002a9615274d rsp 0000007fbfffc290 error 6


// Public key file:
-rw-------  1 root root 2.4K Mar 15 11:02 /root/.ssh/authorized_keys2

Any ideas?

Thanks for your help.

greetings

-- 
Daniel Khan
Technische Leitung
Gesch?ftsf?hrender Gesellschafter

Ventigo
Werbung . IT . Marketing GmbH

Kornstrasse 10 4060 Leonding
T. +43 (0) 732 37 09 60 | F. +43 (0) 732 37 09 60 10
http://www.ventigo.com | office at ventigo.com

Darren Tucker

2005-Mar-15 11:21 UTC

head link

Segmentation fault on public key authentification

Daniel Khan wrote:> after some weeks of operation and updates one server of mine needed a 
> reboot.
> Now authentification with public key causes a segfault.
One of those updates didn't happen to be an openssl one, did it?  Since 
it's while reading keys that's a good place to start looking.

I vaguely recall a problem on amd64 (in the asm?), although it should 
not be in the current openssl.  (Found it in the list archives, it was a 
SIGFPE not SEGV so it's probably not related.
> // Messagelog on node1:
> Mar 15 11:21:14 [sshd] Connection from 192.168.0.200 port 37281
> Mar 15 11:21:14 [kernel] sshd[1817]: segfault at 0000000000000003 rip 
> 0000002a9615274d rsp 0000007fbfffc290 error 6[...]

Your best bet is to get a stack trace of sshd using gdb.  To do this, as 
root (I'm using port 2022 for this example):

# gdb /path/to/sshd
(gdb) set args -ddd -p 2022 -o useprivilegeseparation=no
(gdb) run
[now connect and wait for the failure]
(gdb) backtrace
> // Public key file:
> -rw-------  1 root root 2.4K Mar 15 11:02 /root/.ssh/authorized_keys2
That looks to have changed recently, does the problem persist if you 
remove the recent entries?
> Any ideas?
4.0p1 is out, you could try that.

-- 
Darren Tucker (dtucker at zip.com.au)
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4  37C9 C982 80C7 8FF4 FA69
     Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.

Possibly Parallel Threads

Search for more reasonably related threads

openssh unix dev - Mar 2005 - Segmentation fault on public key authentification

Segmentation fault on public key authentification

Segmentation fault on public key authentification

Possibly Parallel Threads