Am 05.04.2018 um 14:11 schrieb Alexander Wuerstlein:> On 2018-04-05T14:07, Nico Kadel-Garcia <nkadel at gmail.com> wrote: >> How difficult would it be to leave a scheduled security check to >>look for "ssh[ \t].*-R.*" expressions with "pgrep", and file a >> security abuse report if such processes are seen? It could be >> worked around, but should catch the most blatant abusers.so they >> can be notified of inappropriate behavior. > > Additionally, one could grep home directories for relevant > configuration statements in ~/.ssh/config. However that would be > necessarily incomplete, because the other relevant config is > ~/.ssh/authorized_keys on the remote end. Yeah, we thought of these options, too and I assume we will eventually go with them, but as was pointed out, these approaches are simple, et incomplete. That's why we asked in the first place. However, since there does not seem to be any reasonable alternative short than doing way more elaborated software development ourselves, these will have to do. Therefore, I consider this matter closed. Thanks again to everybody who helped. Best regards, Jan -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20180409/9d813781/attachment.asc>
On Mon, 2018-04-09 at 13:31 +0200, Jan Bergner wrote:> However, since there does not seem to be any reasonable alternative > short than doing way more elaborated software development ourselves, > these will have to do. > Therefore, I consider this matter closed. > > Thanks again to everybody who helped.This really depends on the way how much the clients have to try to workaround this obstacle you are going to throw under their feet. There is a configuration option "ClearAllForwardings", which does basically the same thing, but needs to be specified on command line after all the other forwarding options to my understanding. The "allowed" ssh can be wrapped in some script that makes sure this option is passed, but as already said by others, there are other ways how to get data out so using a bastion/jumpbox for external connections might be the right way. Note, that PermitTunnel is something completely different and it will not help you in this case, because it is used for L2 and L3 tunneling using Tunnel configuration options (not the -R ones). -- Jakub Jelen Software Engineer Security Technologies Red Hat, Inc.
Le 09/04/2018 ? 14:10, Jakub Jelen a ?crit?:> On Mon, 2018-04-09 at 13:31 +0200, Jan Bergner wrote: >> [?] >> Therefore, I consider this matter closed. >> >> Thanks again to everybody who helped. > > This really depends on the way how much the clients have to try to > workaround this obstacle you are going to throw under their feet. > > [?] > > Note, that PermitTunnel is something completely different and it will > not help you in this case, because it is used for L2 and L3 tunneling > using Tunnel configuration options (not the -R ones).Hello, I now have a better understanding of this part, so thank you all too. Best regards, -- benoist