My pc runs Scientific Linux release 6.8 (Carbon), Kernel 2.6.32-642.3.1.el6.i686, all patches applied. After unpacking, running ' -/configure ' (just that, no other params), then ' make; make install DESTDIR=`pwd`/DESTDIR ' and running sshd from there: the call ' DESTDIR/.../bin/ssh host102 ' succeeds ( authentication with id_rsa ; host 102 is localhost where the new sshd runs). But running ' ./configure --with-ssh1 ' in a fresh unpacked openssh-7.3p1 directory, then the same as above: the sshd starts, but calling the ssh does not succeed. I see the following: sshd: /Data/openssh-7.3p1/DESTDIR/usr/local/sbin/sshd -p 222 -f \n DESTDIR/usr/local/etc/sshd_config ssh: ./ssh -vvv -p 222 -F DESTDIR/usr/local/etc/ssh_config host102 OpenSSH_7.3p1, OpenSSL 1.0.1e-fips 11 Feb 2013 debug1: Reading configuration data DESTDIR/usr/local/etc/ssh_config debug2: resolving "host102" port 222 debug2: ssh_connect_direct: needpriv 0 debug1: Connecting to host102 [192.168.2.102] port 222. debug1: Connection established. debug1: permanently_set_uid: 0/0 debug1: identity file /root/.ssh/id_rsa type 1 ... debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_7.3 ssh_exchange_identification: read: Connection reset by peer /var/log/messages: Aug 2 17:35:07 host102 sshd[7449]: Server listening on 0.0.0.0 port 222. Aug 2 17:35:07 host102 sshd[7449]: Server listening on :: port 222. Aug 2 17:36:03 host102 sshd[7455]: error: buffer_get_bignum_ret: \n incomplete message Aug 2 17:36:03 host102 sshd[7455]: fatal: buffer_get_bignum: buffer \n error The code after line 1111 in sshd.c (buffer_get_bignum) seems to be not adequate any more. I suppose the error will also show up on Centos. Best regards Rainer
On Wed, Aug 3, 2016 at 7:42 AM, rl <rainer.laatsch at t-online.de> wrote: [...]> /Data/openssh-7.3p1/DESTDIR/usr/local/sbin/sshd -p 222 -f \n > DESTDIR/usr/local/etc/sshd_configIt looks like you have an embedded newline in the config file name you're passing to sshd. If that's the case I'm surprised it starts at all. Exactly how are you starting sshd?> Aug 2 17:35:07 host102 sshd[7449]: Server listening on 0.0.0.0 port 222. > Aug 2 17:35:07 host102 sshd[7449]: Server listening on :: port 222. > Aug 2 17:36:03 host102 sshd[7455]: error: buffer_get_bignum_ret: \n > incomplete messagethat might be the newline confusing the re-exec protocol although I'm not sure. Please including complete debug logs for both client and server. -- Darren Tucker (dtucker at zip.com.au) GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860 37F4 9357 ECEF 11EA A6FA (new) Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement.
On 08/03/16 02:12, Darren Tucker wrote:> On Wed, Aug 3, 2016 at 7:42 AM, rl <rainer.laatsch at t-online.de> wrote: > [...] >> /Data/openssh-7.3p1/DESTDIR/usr/local/sbin/sshd -p 222 -f \n >> DESTDIR/usr/local/etc/sshd_config > > It looks like you have an embedded newline in the config file name > you're passing to sshd. If that's the case I'm surprised it starts at > all. Exactly how are you starting sshd? > >> Aug 2 17:35:07 host102 sshd[7449]: Server listening on 0.0.0.0 port 222. >> Aug 2 17:35:07 host102 sshd[7449]: Server listening on :: port 222. >> Aug 2 17:36:03 host102 sshd[7455]: error: buffer_get_bignum_ret: \n >> incomplete message > > that might be the newline confusing the re-exec protocol although I'm not sure. > > Please including complete debug logs for both client and server. >The newlines are *not* in the real calls, but are all inserted by me into the email to indicate that my mail program does a wrap-around at these places. I also started the sshd with flags ' -ddd ' ,but that did not give more errors than those I mailed. This sshd is still running, ps -eaf shows the one-liner (i dont insert \n here): root 7449 1 0 17:35 ? 00:00:00 /Data/openssh-7.3p1/DESTDIR/usr/local/sbin/sshd -p 222 -f DESTDIR/usr/local /etc/sshd_config The current working directory is /Data/openssh-7-3p1 , so i could abbreviate the names of the config files after the flags -f resp. -F I could run all that again with full debug logs again,but the omissions in my mail indicated by ' ... ' are in my opinion insignificant. Should I? Best regards, Rainer