Hi Phillipp, developers; I likewise just submitted a patch for similar. It i buried under the thread named OpenSSH contract development / patch. At the request of the OpenSSH dev team, I submitted our patch in the mindrot Bugzilla https://bugzilla.mindrot.org/show_bug.cgi?id=2711 Your patch, I see is available there too https://bugzilla.mindrot.org/show_bug.cgi?id=2716 Anyhow, just drawing attention of these 2 patches together ? they?re similar, though not identical. Ours also changes the behavior of permitopen. Your approaches looks very familiar, it felt like deja vu. Thanks, Devin
Hello Devin, it seems I haven't done my homework, and wrote a patch without properly checking bugzilla ...> Anyhow, just drawing attention of these 2 patches together ? they?re > similar, though not identical. [..] ?Your approaches looks >?very familiar, it felt like deja vu.The patches are indeed very, very similar. I think that does underline the need for such an option. I must admit I was pretty surprised that it did not exist already.> Ours also changes the behavior of permitopen.While I generally agree with having to explicitly whitelist "permitopen" host/port pairs, it does change the default behavior and would probably break configuration in the wild. Or am I mistaken here? Best Philipp
Hi Philipp; Yes, the patch I submitted is one we use to accomplish a specific outcome, and it would break configuration in the wild with respect to permitopen. We provided it in case anyone else gets use out of similar needs. By the same token, the patch I submitted will break gateway ports also (ssh -R), since if they are not explicitly defined our patch will preclude all gateway ports. To do it more generically, I suppose you would need to have a global config value to identify if the sshd should be either: 1. default allow all port forwards except as restricted by an authorized_key, or 2. default deny all port forwards except as permitted by an authorized_key. The extra wrinkle is what to do about users that auth with username and password or something different which does not allow configuration like authorized_keys, which gets into a whole bunch more complexity. In our case we wanted the default deny, and our use case does not need to work about breaking everyone else. Thanks!> While I generally agree with having to explicitly whitelist > "permitopen" host/port pairs, it does change the default behavior and > would probably break configuration in the wild. Or am I mistaken here?Best Philipp