Command restricting is somewhat new to me, scouring the web shortly I found this blog post about it, mentioning ,no-port-forwarding,no-x11-forwarding,no-agent-forwarding in addition to the command. Re-looking at OP, the restrict keyword is used to limit all of those at once.
To me this seems wildly unpredictable unless you’re intimately familiar with your SSHD implementation. I can kind of trust OpenSSH to do it right, but what if you’re using a custom one? Is this post-auth, does it allow a curious attacker to open several SSH post-auth channels in the connection?
The whole point of forking auth in OpenSSH is to allow a sandbox privilege separation so that if there’s a pre-auth 0day, all you’ll get is the privsep’d process. Looking at OpenSSH’s changelog there are a few regression issues every update, which is normally not a problem since the privsep limits their impact, but with this technique the auth child ends successfully and passes execution to the main process.
I’d also like to see a ssh -vvv log on what this looks like from client end before passing judgement. Can you just pass auth, stop, fill the server with channels and find something there? My point is, if you figure out this is going on, can you do something with it given that you have post-auth access to the main sshd process? Further, if you don’t open a channel post-auth, does the script even get executed?
Granted, this might seem pretty far-fetched, but like /u/Malor said this increases attack surface for questionable gain. I would still argue that the command+restrict is not meant for security auditing/logging and shouldn’t be used in that context without a more thorough analysis. It’s not at all clear to me that while the attacker is only authorized to use the script he is forced to use that if he doesn’t choose to (again, I’d like to see a ssh -vvv log on this first), and in any case he is still authenticated and that raises a lot of red flags to me.
TL;DR It seems like this breaks the AAA chain, while the attacker is only authorized to use the log script, they are still authenticated which has security implications.
//Edit: On fourth thought, exploiting this seems unlikely, since it requires the attacker to be intimately involved with SSH implementation. However, if this picks up, I want to point out that this fundamentally changes the scenario from ‘You have no access to this system’ into ‘You have access to this system but you can only run this logging script’ which to me seems like the basis of every infiltration trick ever