similar to: [PATCH] / permitgwports / permitlisten

Displaying 20 results from an estimated 3000 matches similar to: "[PATCH] / permitgwports / permitlisten"

2017 May 05
3
[Bug 2711] New: Patch to add permitgwport and restrict permitopen to be a default deny
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:
2017 May 08
2
[Bug 2716] New: [PATCH] Add "permitlisten" support for -R style forward
https://bugzilla.mindrot.org/show_bug.cgi?id=2716 Bug ID: 2716 Summary: [PATCH] Add "permitlisten" support for -R style forward Product: Portable OpenSSH Version: 7.5p1 Hardware: amd64 OS: Linux Status: NEW Severity: enhancement Priority: P5 Component: sshd
2017 May 04
5
OpenSSH contract development / patch
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
2012 Aug 29
39
[Bug 2038] New: permitopen functionality but for remote forwards
https://bugzilla.mindrot.org/show_bug.cgi?id=2038 Priority: P5 Bug ID: 2038 Assignee: unassigned-bugs at mindrot.org Summary: permitopen functionality but for remote forwards Severity: enhancement Classification: Unclassified OS: Other Reporter: damonswirled at gmail.com Hardware: Other
2017 May 03
2
OpenSSH contract development / patch
Hi OpenSSH developers; Thank you for your amazing work. I?m emailing to see if any knowledgeable OpenSSH developer is willing to help us review / revamp some patches we have for OpenSSH, and provide advice on some of the more advanced uses of OpenSSH. This would be a for pay contract engagement. We are trying to be super respectful of the process, and are happy to be very creative ? we are
2008 Aug 27
18
[Bug 1513] New: CIDR address/masklen matching support for permitopen=
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
2023 Nov 12
1
Match Principal enhancement
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
2020 May 05
1
[Bug 3159] New: authorized_keys: gap in port forwarding restrictions
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
2023 Nov 12
1
Match Principal enhancement
Hi OpenSSH devs, I?m wondering if the following has any merit and can be done securely ... If you could match on principals in the sshd_config, then (for example) on a gateway machine, you could have something like /etc/ssh/authorized_keys/sshfwd: cert-authority,principals=?batcha-fwd,batchb-fwd? ... /etc/ssh/sshd_config containing: Match User sshfwd PubkeyAuthentication yes
2002 Aug 13
1
[PATCH] global port forwarding restriction
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
2006 Dec 05
3
[Bug 1267] PermitOpen - Multiple forwards don't works
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
2011 Nov 06
13
[Bug 1949] New: PermitOpen none option
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:
2001 Aug 27
1
permitopen flag in authorized_keys file
I've just discovered the permitopen flag. We need such a feature for our poor man's VPN services, but this flag seems to be usable only if you generate your authorized_keys file from a database or something like that: keeping a long list of host/port combinations up to date for several users and keys is no fun. As announced before, we have developed a far more powerful mechanism for
2011 Feb 10
6
[Bug 1857] New: [RFE] restrict port forwarding to localhost
https://bugzilla.mindrot.org/show_bug.cgi?id=1857 Summary: [RFE] restrict port forwarding to localhost Product: Portable OpenSSH Version: 5.8p1 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P2 Component: sshd AssignedTo: unassigned-bugs at mindrot.org ReportedBy:
2009 Jun 12
2
Restrict port forwarding on server
Hi, Is there a way to restrict port forwarding on the server? I want only port 8080 on the server to be available to clients. Example when i give this command clients should be able to connect: ssh -L 30300:localhost:8080 .... When i give this for example clients should not be able to connect: ssh -L 30300:localhost:4040 .... I tried this option in config file of server: PermitOpen
2008 Aug 22
1
CIDR address/masklen matching support for permitopen="host:port" restrictions?
Dear openssh-unix-dev list, in OpenSSH 5.1 you introduced CIDR address/masklen matching for "Match address" blocks in sshd_config as well as supporting CIDR matching in ~/.ssh/authorized_keys from="..." restrictions in sshd. I wonder whether CIDR address/masklen matching will be implemented for permitopen="host:port" restrictions in sshd as well, that would be quite
2006 Sep 21
5
Testing for the 4.4p1 release, round 2
Hi all. As most of you know, we are preparing OpenSSH 4.4p1 for release. We have had one round of testing and I would like to thank all who responded. We believe that most of the problems reported have been resolved. If you are so inclined, we would appreciate a quick retest to ensure that the fixed ones remain fixed and the working ones remain working. Of the problems identitified, I am only
2011 Oct 08
2
Detect PID of sshd processes used by one public key; detect -R allocated port on the server
I have a situation where a number of potentially hostile clients ssh to a host I control, each ssh'ing in as the same user, and each forwarding a remote port back to them. So, the authorized_keys file looks like: no-agent-forwarding,command="/bin/true",no-pty,no-user-rc,no-X11-forwarding,permitopen="127.0.0.1:7" ssh-rsa AAAAB....vnRWxcgaK9xXoU= client1234 at example.com
2017 Jul 08
4
force port redirection for list of users
Hi , I have the following requirement . other than following users, any other user sshd connection should be redirected to 2024 instead of port 22. root, ftp, guest So ssh root at ip // should be sent to sshd running at port 22 ssh otheruser at ip // should be sent to sshd running at port 2024 I know that we can do something like this: ssh -o ProxyCommand='ssh -W localhost:2024 cliuser
2019 Oct 09
0
Announce: OpenSSH 8.1 released
OpenSSH 8.1 has just been released. It will be available from the mirrors listed at http://www.openssh.com/ shortly. OpenSSH is a 100% complete SSH protocol 2.0 implementation and includes sftp client and server support. Once again, we would like to thank the OpenSSH community for their continued support of the project, especially those who contributed code or patches, reported bugs, tested