similar to: permitopen flag in authorized_keys file

Solaris 2.5 does not seem to define MAXHOSTNAMELEN, and a compilation of vanilla OpenSSH 2.9.9p2 fails: > gcc -g -O2 -Wall -Wpointer-arith -Wno-uninitialized -I. -I. > -I/usr/local/ssl/include -I/usr/local/include > -DETCDIR=\"/usr/local/etc\" -D_PATH_SSH_PROGRAM=\"/usr/local/bin/ssh\" > -D_PATH_SSH_ASKPASS_DEFAULT=\"/usr/local/libexec/ssh-askpass\" >

The patch below fixes a compile-time warning in readpass.c. MIME-Version: 1.0 Content-Type: application/aegis-patch Subject: openssh.2 - Fix warning in readpass.c Content-Name: openssh.2.C010.patch Content-Disposition: attachment; filename=openssh.2.C010.patch X-Aegis-Project-Name: openssh.2 X-Aegis-Change-Number: 10 # # Fix the following warning in readpass.c: # # readpass.c: In function

The README file seems to refer to an old location of zlib. The current one seems to be: http://www.gzip.org/zlib/ -- Florian Weimer Florian.Weimer at RUS.Uni-Stuttgart.DE University of Stuttgart http://cert.uni-stuttgart.de/ RUS-CERT +49-711-685-5973/fax +49-711-685-5898

My port forwarding changes require an authorization (authentication) context in channel_connect_to(). I'd like to change the dispatch_* functions so that they accept an Authctxt * instead of a void * (this parameter is already used this way). In addition, I'd have to pass the authctxt all the way down to channel_connect_to(). As a side effect, it's possible to get rid of the global

If the source and destination file are identical, the receiving scp truncates the file. On the sending end, read() returns 0, and garbage is sent instead of actual data, and the receiving end puts it into the file, which at least confuses the users. -- Florian Weimer Florian.Weimer at RUS.Uni-Stuttgart.DE University of Stuttgart http://cert.uni-stuttgart.de/

After browsing "Remote timing attacks are practical" (Boneh & Brumley, <http://crypto.stanford.edu/~dabo/abstracts/ssl-timing.html>), I wonder if it might be a good idea to add calls to RSA_blinding_on() before the OpenSSL RSA decryption routines are invoked. The issue is not a LAN-only issue, BTW. Packet delay variation is usually higher in LANs than in WANs. -- Florian

The server daemon writes the following error message to the syslog (running on a HP 9000/712/80 box): | Mar 28 18:01:54 <server> sshd[755]: Did not receive ident string from <client-ip>. Any suggestions? This happens if I connect using OpenSSH from the same box or another one (running the Linux version of OpenSSH). BTW: OpenSSH didn't compile out-of-the-box. I had to disable

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=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:

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

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

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

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:

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.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

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

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

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

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