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 0.0.0.0.
Server listening on 0.0.0.0 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

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

_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
http://www.mindrot.org/mailman/listi...enssh-unix-dev