Re: sshd whines & dies after releng/10 "freebsd-update" run

[David Wolfskill]

On Sun, Oct 16, 2016 at 05:32:57PM -0700, Kevin Oberman wrote:
> ...
> I believe sshd no longer supports ssh1 compatibility and it looks like you
> might still have an entry in /etc/sshd/sshd.config trying to touch v1.
> Check the file for any non-default entries. Compare your sshd_config with
> the default version in /usr/src/crypto/openssh.
> 

I used to explicitly disable v1 compatibility.

The machine that's a target of the "freebsd-update" attention has
no sources, so I copied sshd_config from it to /tmp on my laptop
(which does):

g1-252(11.0-S)[4] diff -u /S2/usr/src/crypto/openssh/sshd_config 
/tmp/sshd_config
--- /S2/usr/src/crypto/openssh/sshd_config  2016-03-13 04:13:31.32369 
-0700
+++ /tmp/sshd_config2016-06-05 06:37:55.0 -0700
@@ -1,5 +1,5 @@
-#  $OpenBSD: sshd_config,v 1.98 2016/02/17 05:29:04 djm Exp $
-#  $FreeBSD: stable/10/crypto/openssh/sshd_config 296781 2016-03-12 
23:53:20Z des $
+#  $OpenBSD: sshd_config,v 1.93 2014/01/10 05:59:19 djm Exp $
+#  $FreeBSD: stable/10/crypto/openssh/sshd_config 264692 2014-04-20 
12:46:18Z des $
 
 # This is the sshd server system-wide configuration file.  See
 # sshd_config(5) for more information.
@@ -120,7 +120,7 @@
 #MaxStartups 10:30:100
 #PermitTunnel no
 #ChrootDirectory none
-#VersionAddendum FreeBSD-20160310
+#VersionAddendum FreeBSD-20140420
 
 # no default banner path
 #Banner none
@@ -128,6 +128,18 @@
 # override default of no subsystems
 Subsystem  sftp/usr/libexec/sftp-server
 
+# Disable HPN tuning improvements.
+#HPNDisabled no
+
+# Buffer size for HPN to non-HPN connections.
+#HPNBufferSize 2048
+
+# TCP receive socket buffer polling for HPN.  Disable on non autotuning 
kernels.
+#TcpRcvBufPoll yes
+
+# Allow the use of the NONE cipher.
+#NoneEnabled no
+
 # Example of overriding settings on a per-user basis
 #Match User anoncvs
 #  X11Forwarding no
g1-252(11.0-S)[5] 


On the off-chance that the VersionAddendum might be confusing at
least one of us, I copied the stable/11 version of the file to the
appropiate place on the freebsd-update target machine, then rebooted.
Still no joy: other things work, but not ssh.

Thanks for the suggestion.  I'm a bit... perplexed.

[The machine in question would be the last machine I have still
running FreeBSD-10 -- I've migrated each of the others to stable/11.]

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Those who would murder in the name of God or prophet are blasphemous cowards.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: sshd whines & dies after releng/10 "freebsd-update" run

[Kevin Oberman]

On Sun, Oct 16, 2016 at 10:45 AM, David Wolfskill 
wrote:

> On Sun, Oct 16, 2016 at 10:29:00AM -0700, Xin Li wrote:
> > ...
> > On 10/16/16 09:26, David Wolfskill wrote:
> > > And over the last year or so, it's worked pretty well:  I have the
> > > machine set up (as is usually my approach) to be able to boot from
> > > either of a couple of slices.  I use a "dump | restore" pipeline
> > > to copy the / and /usr file systems from the "active" slice to the
> > > "inactive" slice, adjust /etc/fstab on the inactive slice to reflect
> > > reality for when it's the boot slice, then (while the file systemms
> > > from the other slice are still mounted -- e.g., on /S2) run
> > > "freebsd-update -b /S2 fetch install", then reboot from the
> > > newly-updated slice.
> > >
> > > In the past, that's Just Worked.
> >
> > Your usage probably worked because you were lucky for a few times in the
> > past.  (details below)
> >
> > > This weekend, though, I was planning to update my other systems tfrom
> > > stable/10 to stable/11, so I figured I'd try freebsd-update on this
> > > machine first.
> > >
> > [...]
> > > root@sisboombah:/tmp # `which sshd` -d
> > > Undefined symbol "ssh_compat13" referenced from COPY relocation in
> /usr/sbin/sshd
> > >
> > > Any clues?
> >
> > I think this is not going to work (stable/10 -> releng/10.3) due to ABI
> > incompatibility in a downgrade.
>
> I seem to have failed to commnunicate clearly:  The machine in question
> does not, and has not, run "stable".  It runs releng.
>
> At the moment (on the "old" slice), it reports:
>
> sisboombah(10.3-RELEASE-p7)[1] uname -a
> FreeBSD sisboombah.catwhisker.org 10.3-RELEASE-p7 FreeBSD 10.3-RELEASE-p7
> #0: Thu Aug 11 18:38:15 UTC 2016 r...@amd64-builder.daemonology.net:
> /usr/obj/usr/src/sys/GENERIC  amd64
> sisboombah(10.3-RELEASE-p7)[2]
>
> > Basically, freebsd-update is treating your stable/10 as a 10.3-RELEASE
> > installation and will fetch only changes from 10.3-RELEASE to the latest
> > patchlevel.
>
> I can see that... if the machine were running stable.
>
> > Because of a SSH vulnerability that affects 10.3, freebsd-update would
> > patch libssh (shared library used by sshd and friends), however the
> > change does not affect the main binary.  This worked by replacing your
> > existing libssh with the one shipped by freebsd-update (effectively
> > downgraded the library) and that would break sshd.
>
> As a reality check:
> sisboombah(10.3-RELEASE-p7)[4] sudo mount /S2
> Password:
> sisboombah(10.3-RELEASE-p7)[5] sudo mount /S2/usr
> sisboombah(10.3-RELEASE-p7)[6] ls -lT {,/S2}/usr/lib/private/libssh.so.*
> -r--r--r--  1 root  wheel  634232 Oct 16 11:57:32 2016
> /S2/usr/lib/private/libssh.so.5
> -r--r--r--  1 root  wheel  569864 Jun  5 13:37:52 2016
> /usr/lib/private/libssh.so.5
> sisboombah(10.3-RELEASE-p7)[7] ls -lT {,/S2}/usr/sbin/ssh*
> -r-xr-xr-x  1 root  wheel  297736 Jun  5 13:38:35 2016 /S2/usr/sbin/sshd
> -r-xr-xr-x  1 root  wheel  297736 Jun  5 13:38:35 2016 /usr/sbin/sshd
> sisboombah(10.3-RELEASE-p7)[8]
>
> > I think upgrade -r 10.2-RELEASE (ideally, 11.0-RELEASE though as it
> > would eliminate the possibility of any potential incompatibility) would
> > work because that would result in a full rewrite of all files.
>
> Well, I had seen reports of folks having "issues" with attempts to
> use freebsd-update to get to releng/11 from systems that weren't
> as up-to-date as they might be; I was actually trying to avoid a
> problem :-}
>
> Peace,
> david
> --
> David H. Wolfskill  da...@catwhisker.org
> Those who would murder in the name of God or prophet are blasphemous
> cowards.
>
> See http://www.catwhisker.org/~david/publickey.gpg for my public key.
>

I believe sshd no longer supports ssh1 compatibility and it looks like you
might still have an entry in /etc/sshd/sshd.config trying to touch v1.
Check the file for any non-default entries. Compare your sshd_config with
the default version in /usr/src/crypto/openssh.
--
Kevin Oberman, Part time kid herder and retired Network Engineer
E-mail: rkober...@gmail.com
PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: sshd whines & dies after releng/10 "freebsd-update" run

[David Wolfskill]

On Sun, Oct 16, 2016 at 10:29:00AM -0700, Xin Li wrote:
> ... 
> On 10/16/16 09:26, David Wolfskill wrote:
> > And over the last year or so, it's worked pretty well:  I have the
> > machine set up (as is usually my approach) to be able to boot from
> > either of a couple of slices.  I use a "dump | restore" pipeline
> > to copy the / and /usr file systems from the "active" slice to the
> > "inactive" slice, adjust /etc/fstab on the inactive slice to reflect
> > reality for when it's the boot slice, then (while the file systemms
> > from the other slice are still mounted -- e.g., on /S2) run
> > "freebsd-update -b /S2 fetch install", then reboot from the
> > newly-updated slice.
> > 
> > In the past, that's Just Worked.
> 
> Your usage probably worked because you were lucky for a few times in the
> past.  (details below)
> 
> > This weekend, though, I was planning to update my other systems tfrom
> > stable/10 to stable/11, so I figured I'd try freebsd-update on this
> > machine first.
> > 
> [...]
> > root@sisboombah:/tmp # `which sshd` -d
> > Undefined symbol "ssh_compat13" referenced from COPY relocation in 
> > /usr/sbin/sshd
> > 
> > Any clues?
> 
> I think this is not going to work (stable/10 -> releng/10.3) due to ABI
> incompatibility in a downgrade.

I seem to have failed to commnunicate clearly:  The machine in question
does not, and has not, run "stable".  It runs releng.

At the moment (on the "old" slice), it reports:

sisboombah(10.3-RELEASE-p7)[1] uname -a
FreeBSD sisboombah.catwhisker.org 10.3-RELEASE-p7 FreeBSD 10.3-RELEASE-p7 #0: 
Thu Aug 11 18:38:15 UTC 2016 
r...@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC  amd64
sisboombah(10.3-RELEASE-p7)[2] 

> Basically, freebsd-update is treating your stable/10 as a 10.3-RELEASE
> installation and will fetch only changes from 10.3-RELEASE to the latest
> patchlevel.

I can see that... if the machine were running stable.

> Because of a SSH vulnerability that affects 10.3, freebsd-update would
> patch libssh (shared library used by sshd and friends), however the
> change does not affect the main binary.  This worked by replacing your
> existing libssh with the one shipped by freebsd-update (effectively
> downgraded the library) and that would break sshd.

As a reality check:
sisboombah(10.3-RELEASE-p7)[4] sudo mount /S2
Password:
sisboombah(10.3-RELEASE-p7)[5] sudo mount /S2/usr
sisboombah(10.3-RELEASE-p7)[6] ls -lT {,/S2}/usr/lib/private/libssh.so.*
-r--r--r--  1 root  wheel  634232 Oct 16 11:57:32 2016 
/S2/usr/lib/private/libssh.so.5
-r--r--r--  1 root  wheel  569864 Jun  5 13:37:52 2016 
/usr/lib/private/libssh.so.5
sisboombah(10.3-RELEASE-p7)[7] ls -lT {,/S2}/usr/sbin/ssh*
-r-xr-xr-x  1 root  wheel  297736 Jun  5 13:38:35 2016 /S2/usr/sbin/sshd
-r-xr-xr-x  1 root  wheel  297736 Jun  5 13:38:35 2016 /usr/sbin/sshd
sisboombah(10.3-RELEASE-p7)[8] 

> I think upgrade -r 10.2-RELEASE (ideally, 11.0-RELEASE though as it
> would eliminate the possibility of any potential incompatibility) would
> work because that would result in a full rewrite of all files.

Well, I had seen reports of folks having "issues" with attempts to
use freebsd-update to get to releng/11 from systems that weren't
as up-to-date as they might be; I was actually trying to avoid a
problem :-}

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Those who would murder in the name of God or prophet are blasphemous cowards.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: sshd whines & dies after releng/10 "freebsd-update" run

[Xin Li]

On 10/16/16 09:26, David Wolfskill wrote:
> And over the last year or so, it's worked pretty well:  I have the
> machine set up (as is usually my approach) to be able to boot from
> either of a couple of slices.  I use a "dump | restore" pipeline
> to copy the / and /usr file systems from the "active" slice to the
> "inactive" slice, adjust /etc/fstab on the inactive slice to reflect
> reality for when it's the boot slice, then (while the file systemms
> from the other slice are still mounted -- e.g., on /S2) run
> "freebsd-update -b /S2 fetch install", then reboot from the
> newly-updated slice.
> 
> In the past, that's Just Worked.

Your usage probably worked because you were lucky for a few times in the
past.  (details below)

> This weekend, though, I was planning to update my other systems tfrom
> stable/10 to stable/11, so I figured I'd try freebsd-update on this
> machine first.
> 
[...]
> root@sisboombah:/tmp # `which sshd` -d
> Undefined symbol "ssh_compat13" referenced from COPY relocation in 
> /usr/sbin/sshd
> 
> Any clues?

I think this is not going to work (stable/10 -> releng/10.3) due to ABI
incompatibility in a downgrade.

Basically, freebsd-update is treating your stable/10 as a 10.3-RELEASE
installation and will fetch only changes from 10.3-RELEASE to the latest
patchlevel.

Because of a SSH vulnerability that affects 10.3, freebsd-update would
patch libssh (shared library used by sshd and friends), however the
change does not affect the main binary.  This worked by replacing your
existing libssh with the one shipped by freebsd-update (effectively
downgraded the library) and that would break sshd.

I think upgrade -r 10.2-RELEASE (ideally, 11.0-RELEASE though as it
would eliminate the possibility of any potential incompatibility) would
work because that would result in a full rewrite of all files.

Cheers,



signature.asc
Description: OpenPGP digital signature

Re: sshd whines & dies after releng/10 "freebsd-update" run

[David Wolfskill]

On Sun, Oct 16, 2016 at 12:35:01PM -0400, Brandon Allbery wrote:
> On Sun, Oct 16, 2016 at 12:26 PM, David Wolfskill 
> wrote:
> 
> > This weekend, though, I was planning to update my other systems tfrom
> > stable/10 to stable/11, so I figured I'd try freebsd-update on this
> > machine first.
> >
> 
> Wait, you used freebsd-update on a machine running stable?

No.

My *other* machines run stable (though a couple also sometimes run
head).  This machine runs releng/10.

> It only supports
> releases. IOW you may well have *downgraded* the machine in some sense.
> (Although really it should have just failed in that case.)

Right.

> Also make sure you are not using an sshd from ports; even if such a
> down/sidegrade works for base, I'd expect it to screw up installed ports.
> 

I'm certain that I wouldn't have placed a "ports" sshd in /sur/sbin
(even had I installed one), and pkg reports negatively:

sisboombah(10.3-RELEASE-p7)[5] pkg info ssh\*
pkg: No package(s) matching ssh*
sisboombah(10.3-RELEASE-p7)[6] 

Thanks!

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Those who would murder in the name of God or prophet are blasphemous cowards.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: sshd whines & dies after releng/10 "freebsd-update" run

[Brandon Allbery]

On Sun, Oct 16, 2016 at 12:26 PM, David Wolfskill 
wrote:

> This weekend, though, I was planning to update my other systems tfrom
> stable/10 to stable/11, so I figured I'd try freebsd-update on this
> machine first.
>

Wait, you used freebsd-update on a machine running stable? It only supports
releases. IOW you may well have *downgraded* the machine in some sense.
(Although really it should have just failed in that case.)

Also make sure you are not using an sshd from ports; even if such a
down/sidegrade works for base, I'd expect it to screw up installed ports.

-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

sshd whines & dies after releng/10 "freebsd-update" run

[David Wolfskill]

For most of my experience with FreeBSD (since 1998) and for most of my
machines, I build from source (either on the machine itself or a
dedicated "build machine"); this has been ... occasionally turbulent,
but overall, a fairly stable approach for me (and it's a great deal less
turbulent -- usually! -- now than it was a decade ago).

However, I have one machine that is pretty much dedicated to one
specific function, and for it, I thought I'd try freebsd-update.

And over the last year or so, it's worked pretty well:  I have the
machine set up (as is usually my approach) to be able to boot from
either of a couple of slices.  I use a "dump | restore" pipeline
to copy the / and /usr file systems from the "active" slice to the
"inactive" slice, adjust /etc/fstab on the inactive slice to reflect
reality for when it's the boot slice, then (while the file systemms
from the other slice are still mounted -- e.g., on /S2) run
"freebsd-update -b /S2 fetch install", then reboot from the
newly-updated slice.

In the past, that's Just Worked.

This weekend, though, I was planning to update my other systems tfrom
stable/10 to stable/11, so I figured I'd try freebsd-update on this
machine first.

But before I tried going to stable/11, I thought it might be good to
first get to the latest releng/10.

Running freebsd-update seemed to go well.  I rebooted from the updated
slice... and found that I could not ssh to the machine.  (I only
physically login to a machine other than my laptop if there's a problem
that's so bad that I can't login from the laptop)

And I found that sshd wasn't running.  Indeed, on attempting to start it
by hand:

root@sisboombah: # service sshd start
Performing sanity check on sshd configuration.
Undefined symbol "ssh_compat13" referenced from COPY relocation in 
/usr/sbin/sshd
/etc/rc.d/sshd: WARNING: failed precmd routine for sshd

Attempting to start it in "debug" mode was of no help:

root@sisboombah:/tmp # `which sshd` -d
Undefined symbol "ssh_compat13" referenced from COPY relocation in 
/usr/sbin/sshd

Any clues?

I have placed both a typescript of the freebsd-update run (actually, a
pair of them: one yesterday; another, today), as well as a typescript
from some poking around a bit, under
.

Thanks!

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Those who would murder in the name of God or prophet are blasphemous cowards.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature