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

[Darren Tucker]

On Wed, Aug 3, 2016 at 7:42 AM, rl <***@t-online.de> wrote:
[...]

Post by rl
/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?

Post by rl
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.

[rl]

Post by Darren Tucker
[...]

Post by rl
/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?

Post by rl
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 <***@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.

[rl]

Post by Darren Tucker
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 <***@t-online.de> wrote:
[...]

Post by rl
I'll run again and add the relevant unedited texts as attachments.

Thanks.

Post by rl
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]

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

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

Post by Darren Tucker

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

https://anongit.mindrot.org/openssh.git/commit/?id=1a31d02b
wherein
- buffer_put_int(&m, 0);
+ if ((r = sshbuf_put_u32(m, 1)) != 0)
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]

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

Post by Darren Tucker

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

https://anongit.mindrot.org/openssh.git/commit/?id=1a31d02b
wherein
- buffer_put_int(&m, 0);
+ if ((r = sshbuf_put_u32(m, 1)) != 0)
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)

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