Configure option '--with-ssh1' breaks openssh-7.3p1

[rl]

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
_______________________________________________
openssh-unix-dev mailing list
openssh-...@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

[Darren Tucker]

On Wed, Aug 3, 2016 at 7:42 AM, rl <rainer....@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.

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

[rl]

On 08/03/16 02:12, Darren Tucker wrote:
> On Wed, Aug 3, 2016 at 7:42 AM, rl <rainer....@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

[Darren Tucker]

On Wed, Aug 3, 2016 at 11:12 AM, rl <rainer....@t-online.de> wrote:
[...]

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

If your mailer is corrupting information please open a bug at
bugzilla.mindrot.org and use "add attachment" to attach the
unadulterated logs instead.

[...]

> I could run all that again with full debug logs again,but the
> omissions in my mail indicated by ' ... ' are in my opinion insignificant.

If you are certain what is and is not significant then you should be
able to figure out the problem on your own.

> Should I?

Yes. Debugging something on a system you can't interact with is hard
enough without having information withheld.

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

[rl]

On 08/03/16 03:19, Darren Tucker wrote:
>
> Yes. Debugging something on a system you can't interact with is hard
> enough without having information withheld.
>

I'll run again and add the relevant unedited texts as attachments.
There is nothing in /var/log/secure.
Also a diff between the config.h 's without and with --with-ssh1 is
attached.
I have a centos-6.7 under VirtualBox. I could do the same there to check
if --with-ssh1 also breaks openssh-7.3p1, but not at once now
(my localtime is 04:30 in the morning ...)

I hope the attachments are sufficient; let me know if I could do better.
Darren: I am grateful for your quick responses

Best regards, Rainer

[Darren Tucker]

On Wed, Aug 3, 2016 at 12:34 PM, rl <rainer....@t-online.de> wrote:
[...]

> I'll run again and add the relevant unedited texts as attachments.

Thanks.

> There is nothing in /var/log/secure.
> Also a diff between the config.h 's without and with --with-ssh1 is
> attached.
> I have a centos-6.7 under VirtualBox. I could do the same there to check
> if --with-ssh1 also breaks openssh-7.3p1, but not at once now
> (my localtime is 04:30 in the morning ...)
>
> I hope the attachments are sufficient; let me know if I could do better.
> Darren: I am grateful for your quick responses

I'm not sure why but output from sshd is missing everything after the
re-exec. If you add "-e" to sshd command line to force it to continue
to write to stderr after it re-execs itself. I don't know why that
happened (I have not been able to reproduce that or the original
problem on a recent Fedora).

[Darren Tucker]

OK, with this additional information I can now reproduce it.

Based on some quick experiments it seems to be triggered when sshd is
built --with-ssh1 and the config does not *load* a Protocol 1 host
key.

Works:
Protocol=1,2 + Hostkey not specified
Protocol=1,2 + Hostkeys for both protocols specified.

Doesn't work:
Protocol=2 + Hostkey not specified.
Protocol=1,2 + Hostkeys specified only for Protocol 2.
Protocol=2 + Hostkeys specified for both protocols.

[Darren Tucker]

On Wed, Aug 03, 2016 at 01:38:15PM +1000, Darren Tucker wrote:
> OK, with this additional information I can now reproduce it.
>
> Based on some quick experiments it seems to be triggered when sshd is
> built --with-ssh1 and the config does not *load* a Protocol 1 host
> key.

Looks like it was introducted here:
https://anongit.mindrot.org/openssh.git/commit/?id=1a31d02b
wherein

- buffer_put_int(&m, 0);
+ if ((r = sshbuf_put_u32(m, 1)) != 0)

This patch should fix it:

diff --git a/sshd.c b/sshd.c
index 799c771..8f2b322 100644
--- a/sshd.c
+++ b/sshd.c
@@ -1071,7 +1071,7 @@ send_rexec_state(int fd, struct sshbuf *conf)
fatal("%s: buffer error: %s", __func__, ssh_err(r));
} else
#endif
- if ((r = sshbuf_put_u32(m, 1)) != 0)
+ if ((r = sshbuf_put_u32(m, 0)) != 0)
fatal("%s: buffer error: %s", __func__, ssh_err(r));

#if defined(WITH_OPENSSL) && !defined(OPENSSL_PRNG_ONLY)

[rl]

Darren: your patch worked for me, thanks a lot for your analysis!
Best regards, Rainer

On 08/03/16 05:51, Darren Tucker wrote:
> On Wed, Aug 03, 2016 at 01:38:15PM +1000, Darren Tucker wrote:
>> OK, with this additional information I can now reproduce it.
>>
>> Based on some quick experiments it seems to be triggered when sshd is
>> built --with-ssh1 and the config does not *load* a Protocol 1 host
>> key.
>
> Looks like it was introducted here:
> https://anongit.mindrot.org/openssh.git/commit/?id=1a31d02b
> wherein
>
> - buffer_put_int(&m, 0);
> + if ((r = sshbuf_put_u32(m, 1)) != 0)
>
> This patch should fix it:
>
> diff --git a/sshd.c b/sshd.c
> index 799c771..8f2b322 100644
> --- a/sshd.c
> +++ b/sshd.c
> @@ -1071,7 +1071,7 @@ send_rexec_state(int fd, struct sshbuf *conf)
> fatal("%s: buffer error: %s", __func__, ssh_err(r));
> } else
> #endif
> - if ((r = sshbuf_put_u32(m, 1)) != 0)
> + if ((r = sshbuf_put_u32(m, 0)) != 0)
> fatal("%s: buffer error: %s", __func__, ssh_err(r));
>
> #if defined(WITH_OPENSSL) && !defined(OPENSSL_PRNG_ONLY)
>

[Jeff Wieland]

I was having the same problem, and this fixes it for me as well.
Thanks!

--
Jeff Wieland | Purdue University
Network Systems Administrator | ITIS UNIX Platforms
Voice: (765)496-8234 | 155 S. Grant Street
FAX: (765)496-1380 | West Lafayette, IN 47907