Starting with OpenSSH 7.2, a new "restrict" option for authorized_keys lines has become available. It sets all available restrictions that the current OpenSSH version can do (like no-agent-forwarding, no-x11-forwarding etc). One can individually turn on those features again by corresponding new options.
This saves one from sorrows when a new capability of OpenSSH is introduced through an update which is enabled by default, since one has to remember that restricted authorized_keys lines are in unse and then to manually add the restrictions.
On the downside, Debian jessie and CentOS 7 don't have a recent enough OpenSSH. So we'll have to continue worrying about new features being inadvertendly enabled for a while.
P.S.: Yes, I haven't blogged about Linux and Debian in English in a while.
I recently had an issue where a remote host would frequently run out of memory after a number of processes had been invoked from remote. I looked in the wrong direction first, but finally found out that each process invocation leaves two sshd processes hanging around, which are eventually exhausting the memory on the box.
Next step was finding out what happened for the sshd processes not to properly terminate. Eventually, I remembered that the incoming ssh connections were not invoked directly, but via a third host with "proxycommand ssh other-host socket %h %p". Looking on other-host quickly showed a number of socket processes being around, and killing them made the sshds on the low-memory host vanish as well.
Short-term remedy was therefore to set ClientAliveInterval in the low-memory host's sshd configuration.
I then searched for reasons why ClientAliveInterval is not set by default at least in Debian's sshd configuration. I didn't find a reason and proceeded to file a wishlist bug request againnst openesh-server for this option to be set by default.
Before filing this bug, I routinely visited the BTS, just to find out that the bug was already filed. By me. One year and 285 days ago. And that the openssh maintainer(s) didn't even bother to reply to it yet.
Guys, _this_ is a textbook example how to discourage people from filing Bugs against your packages. Please, give them at least the appreciation of a short ACK if you don't get around to fixing the bugs in reasonably short time. Having a bug rot away uncommented and unfixed in the BTS for two years is simpy not acceptable. Yes, that goes even for a wishlist bug.
