openssh-portable-8.9.p1_3,1 ssh_dispatch_run_fatal: Connection Not permitted in capability mode [preauth]

gessel

gessel

Updating from openssh-portable from 8.8.p1_1,1 to 8.9.p1_3,1 broke it on my boxes. It seems to be related to capsicum based on the error message but I'm not finding any obvious clues in the usual places.

FreeBSD 11.3-RELEASE-p8 #0 r360490
(Unsupported I know, but, sadly, not practical to do an OS update at this time due to being very remote)

openssh-portable options:
(X) FIDO_U2F
(X) LDNS
(X) LIBEDIT
(X) PAM
(X) TCP_WRAPPERS

Setting identical DEBUG3 for jails running 8.8 vs. 8.9 there's no differences in the setup preamble, including both logging debug3: ssh_sandbox_init: preparing capsicum sandbox but the similarities end with debug1: SSH2_MSG_KEXINIT sent [preauth] and 8.9 logs to /var/log/debug.log as it fails:
debug1: do_cleanup [preauth]
debug1: monitor_read_log: child log fd closed
debug3: mm_request_receive: entering
debug1: do_cleanup
debug1: Killing privsep child 62090

and to /var/log/auth.log
ssh_dispatch_run_fatal: Connection from ip.add.re.ss port 33492: Not permitted in capability mode [preauth]

I'm at a loss. I do not have remotely efficient hands-on should something go off the rails. I have jexec and (emergency only) telnet, so I'm not dead, but dreading the next network drop that breaks the live SSH connections I have left.
 
Not very useful if you want an immediate "this will definitely fix your problem" answer, but you could set up a local test box/VM and see if you can get it in the same state and if/how you can move on from that - then you might have a bit more confidence the remote procedure will also work (following the same steps as you did locally).

And any box I have remote now I make sure I have BMC/iDRAC/iLO/whatever-it's-called because there will be one day you really need it!

Good luck.
 
Thanks Richard,

It has an RSA-II in it, but the last updates were pre TLS updates and browsers have made access nearly impossible. iLO is nice, but even until a few years ago it was IE or Java - and therefore unusable on modern systems. The move to HTML5 console will trickle down, that's nice. I also have a remote VNC console, which is OK when some ZFS feature flag breaks boot, but unbearably tedious for a remote console work (plus no copy paste).

Anyway, yes, there are backups for total breakage, but I'm hoping there's a fix.
 
I found a sub-optimal work around: the previous version security/openssh-portable-8.4.p1_3,1 works fine. This is suboptimal because it is vulnerable to CVE-2021-28041 and CVE-2021-41617 per PR 202169, but doesn't do whatever 8.9.p1_3,1 is, unfortunately, doing.

For any others so afflicted, I hadn't yet had cause for ports-mgmt/portdowngrade, so from the top:

# portmaster -d ports-mgmt/portdowngrade
# portdowngrade security/openssh-portable
# /usr/local/sbin/portdowngrade security/openssh-portable r557337
# cd openssh-portable/
# make DISABLE_VULNERABILITIES=yes deinstall install clean
# service openssh restart

enjoy SSH connectivity again.

I'm still hoping for a less vulnerability inducing solution.
 
gessel said:
It has an RSA-II in it, but the last updates were pre TLS updates and browsers have made access nearly impossible. iLO is nice, but even until a few years ago it was IE or Java - and therefore unusable on modern systems. The move to HTML5 console will trickle down, that's nice.
Click to expand...
I've got one server left that's got a BMC console that is Java-only, and it's also the same machine with the older certificates so yes, been bitten by both those. Dell and Supermicro HTML5 solutions working well so far in the more modern servers.

Hopefully someone can help you with the original problem, but think it might be along the lines of "you need to upgrade to upgrade".
 
Wow, BMC java! that's some history! I got RSA cards for my boxen and never interacted much with BMC; I'm impressed!

I suspect you're right about any forthcoming advice, but given it was a pretty definitive break from r557337, it might be an actual bug rather than a security "feature". At least there's a work around and discoverably documented, even if suboptimal.

As for remote console, I'm a fan of Gen 10 HTML5 iLO; I have a dozen or so servers running it. And while it seems recent to me it really isn't: gen 9 iLO now also supports HTML5 console and such devices are quite reasonable on ebay.

Back when version support timelines meant almost decades between support lapses, it was reasonable to synchronize major updates with hardware changes but the current model isn't as forgiving. 11->12 will be my second on the same hardware not because 11 is in any way deficient, just that it isn't supported.

A few ports (perl comes to mind) spitefully reject 11.x, not because there's any incompatibility but because you "should" have upgraded by now and if you haven't you're doing it wrong.

-david
 
Oops, forgot about how FreeBSD abandoned SVN and all the wonderful tools and protocols that were available in that excellent system for git. ?

ports-mgmt/portdowngrade only looks at SVN, which was frozen in 2021, so if a port update breaks something on your system and you need to backrev it is a far more complex process. Thread portdowngrade-gitup-tweak-for-downgrading.80280

For sure you can download the entire ports tree at a commit (~116MiB compressed, 342MiB uncompressed) and then extract the port from the archive - I just did that 8 times to find the last working release of security/openssh-portable, but it isn't clear to me how to clone a specific port out of the ports tree at a specific revision number as one might a gitlab/github project. (A pointer to a working method, if one exists, would be much appreciated).

For the purposes of this fix, the most recent but not current version of security/openssh-portable that is straight-forward to install with the good old days tools is r568761, openssh-portable-8.4.p1_4,1 which is pretty old at this point but has the critical advantages of actually working and being accessible via SVN.

# portdowngrade security/openssh-portable r568761

However, 8.4.p1_4,1 is marked vulnerable. Fortunately, there is a version that isn't marked vulnerable that doesn't have the catastrophic bug: 8.8p1_2,1. The bug was introduced in 8.9.p1,1 (...e32 commit). Unfortunately, 8.8p1_2.1 came after the svnapaplypse and so it has become absurdly difficult to access it. You can download the 116MiB port tree at the commit from https://cgit.freebsd.org/ports/commit/?id=ad60ad3528afdeafa5eb9a13a70fea04a0565b0c. Since that's dumb for a 37KiB file and people might not have 342MiB of free space, I can make the 8.8p1_2,1 port available via some other method, but given this is pretty core security software unofficial sources, even I, seem ill advised.
 
You must log in or register to reply here.
Back
Top