This is a discussion on Re: Segmentation fault on public key authentification - openssh ; Daniel Khan wrote: > Darren Tucker wrote: >> 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 ...
Daniel Khan wrote:
> Darren Tucker wrote:
>> 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..
No, OpenSSL the library, not OpenSSH. You may want to compare
/usr/lib/libcrypto* with your working machine.
>> 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
> Program received signal SIGSEGV, Segmentation fault.
> 0x0000002a9615274d in ?? ()
> (gdb) backtrace
> #0 0x0000002a9615274d in ?? ()
> #1 0x00000000fbad8000 in ?? ()
Hmm, that's not very helpful. You can try disabling reexec (add "-r" to
the args gdb passes to sshd) but if the problem is because of the
breakpoint thing gdb is complaining about then it's possible that won't
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.
openssh-unix-dev mailing list