Darren Tucker 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.

No - I don't know what I updated but it wasn't OpenSSH.
A mirror with pretty the "same" configuration works..

> 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):

// Here it comes - but it doesn't look to exiting I think:
Starting program: /usr/sbin/sshd -ddd -p 2022 -o useprivilegeseparation=no
warning: Unable to find dynamic linker breakpoint function.
GDB will be unable to debug shared library initializers
and track explicitly loaded dynamic code.
warning: shared library handler failed to enable breakpoint
debug2: load_server_config: filename /etc/ssh/sshd_config
debug2: load_server_config: done config len = 203
debug2: parse_server_config: config /etc/ssh/sshd_config len 203
debug1: sshd version OpenSSH_3.9p1
debug3: Not a RSA1 key file /etc/ssh/ssh_host_rsa_key.
debug1: read PEM private key done: type RSA
debug1: private host key: #0 type 1 RSA
debug3: Not a RSA1 key file /etc/ssh/ssh_host_dsa_key.
debug1: read PEM private key done: type DSA
debug1: private host key: #1 type 2 DSA
debug1: rexec_argv[0]='/usr/sbin/sshd'
debug1: rexec_argv[1]='-ddd'
debug1: rexec_argv[2]='-p'
debug1: rexec_argv[3]='2022'
debug1: rexec_argv[4]='-o'
debug1: rexec_argv[5]='useprivilegeseparation=no'
debug2: fd 3 setting O_NONBLOCK
debug1: Bind to port 2022 on
Server listening on port 2022.
socket: Address family not supported by protocol
debug3: fd 4 is not O_NONBLOCK
debug1: Server will not fork when running in debugging mode.
debug3: send_rexec_state: entering fd = 7 config len 203
debug3: ssh_msg_send: type 0
debug3: send_rexec_state: done
debug1: rexec start in 4 out 4 newsock 4 pipe -1 sock 7

Program received signal SIGSEGV, Segmentation fault.
0x0000002a9615274d in ?? ()
(gdb) backtrace
#0 0x0000002a9615274d in ?? ()
#1 0x00000000fbad8000 in ?? ()

>> // 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?

No - I was just playing around with this file after the problem occured.

>> Any ideas?

> 4.0p1 is out, you could try that.

I just want to find the cause. Maybe anything else is b0rked here na dI
don't want to wait till it really bites me..

Thanks a lot.

Daniel Khan
Technische Leitung
Geschäftsführender Gesellschafter

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@ventigo.com

openssh-unix-dev mailing list