similar to: OpenSSH contract development / patch

https://bugzilla.mindrot.org/show_bug.cgi?id=2711 Bug ID: 2711 Summary: Patch to add permitgwport and restrict permitopen to be a default deny Product: Portable OpenSSH Version: 7.2p2 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 Component:

On Thu, May 04, 2017 at 09:37:59AM +1000, Adam Eijdenberg wrote: > Hi Devin, have you looked at using openssh certificates to help manage [...] > While the feature has been around for a while now (and is really > useful), there doesn't seem to be huge amount of documentation around > it. I found the following useful when getting a client of my running Yeah, when I wrote about it

> (Blargh is right (https://blog.habets.se/2011/07/OpenSSH-certificates.html <https://blog.habets.se/2011/07/OpenSSH-certificates.html>). Googling for this stuff is *hard*:) Does https://www.sweharris.org/post/2016-10-30-ssh-certs/ help at all? Stephen

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

Damien Miller wrote: > On Thu, 2 Feb 2017, Adam Eijdenberg wrote: > >> On Thu, Feb 2, 2017 at 10:42 AM Damien Miller <djm at mindrot.org> wrote: >>> On Thu, 2 Feb 2017, Adam Eijdenberg wrote: >>>> I guess a case could be made for ssh-add to always set a timeout when >>>> adding a certificate with an expiry time, but I think for now I'm

As background, for one of my clients we built out a command line tool which does SSO with Google Apps, then generates a new SSH key pair, and sends this off to an internal service which verifies the request and then issues a new short lived (24 hour) certificate (if interested the code for the server and client is open-sourced here: https://github.com/continusec/geecert), overwriting the previous

http://bugzilla.mindrot.org/show_bug.cgi?id=1267 Summary: PermitOpen - Multiple forwards don't works Product: Portable OpenSSH Version: v4.5p1 Platform: ix86 OS/Version: Cygwin on NT/2k Status: NEW Severity: security Priority: P2 Component: sshd AssignedTo: bitbucket at mindrot.org

https://bugzilla.mindrot.org/show_bug.cgi?id=2001 Bug #: 2001 Summary: Document PermitOpen none in man page Classification: Unclassified Product: Portable OpenSSH Version: -current Platform: All OS/Version: OpenBSD Status: NEW Severity: trivial Priority: P2 Component: Documentation

https://bugzilla.mindrot.org/show_bug.cgi?id=2347 Bug ID: 2347 Summary: permitopen doesn't work with unix domain sockets Product: Portable OpenSSH Version: 6.7p1 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 Component: sshd Assignee: unassigned-bugs

https://bugzilla.samba.org/show_bug.cgi?id=8367 Summary: Add a feature to --move-existing files Product: rsync Version: 3.0.8 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: core AssignedTo: wayned at samba.org ReportedBy: devin.nate at cloudwerx.com

https://bugzilla.mindrot.org/show_bug.cgi?id=2582 Bug ID: 2582 Summary: Allow PermitOpen to use a wildcard hostname with a fixed port Product: Portable OpenSSH Version: 7.2p1 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 Component: sshd

https://bugzilla.mindrot.org/show_bug.cgi?id=3123 Bug ID: 3123 Summary: PermitOpen does not allow wildcards for hosts despite what docs say Product: Portable OpenSSH Version: 7.2p2 Hardware: Other OS: Linux Status: NEW Severity: normal Priority: P5 Component: sshd

Here's another patch for people providing ssh access to restricted environments. We allow our users to use port forwarding when logging into our mail servers so that they can use it to fetch mail over an encrypted channel using clients that don't support TLS, for example fetchmail. (In fact, fetchmail has built-in ssh support.) However we don't want them connecting to other places

https://bugzilla.mindrot.org/show_bug.cgi?id=1949 Bug #: 1949 Summary: PermitOpen none option Classification: Unclassified Product: Portable OpenSSH Version: 5.9p1 Platform: All OS/Version: OpenBSD Status: NEW Severity: enhancement Priority: P2 Component: sshd AssignedTo:

AFAIK everything you described here could be done using the AuthorizedKeysCommand or AuthorizedPrincipalsCommand directives. These can emit authorized_keys options (inc. permitopen) as well as the allowed keys/principals. On Sun, 12 Nov 2023, Bret Giddings wrote: > Hi OpenSSH devs, > > I?m wondering if the following has any merit and can be done securely ... > > If you could

https://bugzilla.mindrot.org/show_bug.cgi?id=3159 Bug ID: 3159 Summary: authorized_keys: gap in port forwarding restrictions Product: Portable OpenSSH Version: 8.0p1 Hardware: Other OS: Linux Status: NEW Severity: normal Priority: P5 Component: sshd Assignee: unassigned-bugs

https://bugzilla.mindrot.org/show_bug.cgi?id=1513 Summary: CIDR address/masklen matching support for permitopen= Product: Portable OpenSSH Version: 5.1p1 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P2 Component: sshd AssignedTo: unassigned-bugs at mindrot.org

I have an application where a lot of end user CPE devices ssh in automatically to a central server, and are authenticated by public key, to do remote (-R) port forwarding, so we can open a connection back to a particular port on the remote device whether it's behind some NAT or firewall or whatever. I want to be certain, however, that if I open port 12345, it is connected to the correct end

I am currently running K12LTSP on Centos 5, which is working well but without sound on most machines(ok all). So in order to remedy this and the cd-burning issue I have decided to try to install CentOS locally on one machine and then apply the personalizations via NFS. Steps: I editted the /etc/exports to export the /home dir as per the NFS howto and that seemed to work as the user homes were

Followed the instructions here: http://www.freebsd.org/doc/handbook/updating-upgrading-freebsdupdate.html The upgrade borked. Error message: Can't find 'kernel' When I checked with ls /boot/kernel/, the directory does exist. :-( Since the system has encrypted root partion with ZFSonROOT, I tried to follow instructions at https://forums.freebsd.org/viewtopic.php?&t=8958 to boot