similar to: [Bug 1315] New: Match Group does not support negation

Markus, ignore the other stuff I sent.. I need to go back to bed and stop trying to code.. <sigh> For everone else.. Will this make everyone happy? This does the follow. it will always honor AllowUsers. If there is no Allow/DenyGroups it stated they are not in allowUsers. IF there are AllowDenyGroups it tries them. And then stated they are not in either AllowUsers nor AllowGroups

The primary purpose of the attached patches is for portable OpenSSH to support changing expired passwords as specified in shadow password files. To support that, I did a couple enhancements to the base OpenBSD OpenSSH code. They are: 1. Consolidated the handling of "forced_command" into a do_exec() function in session.c. These were being handled inconsistently and allocated

Hi, I ran across a case in which my server maintenance was simplified by using SSHD configuration options like this in sshd_config: AllowGroups admin at 192.168.0.* sshuser in much the same fashion as (Allow|Deny)Users. In this case, the goal is to provide access to administrators only from the local network, while allowing SSH users to login from anywhere. This (IMHO) simplifies access

https://bugzilla.mindrot.org/show_bug.cgi?id=2497 Bug ID: 2497 Summary: Add debugging information to ga_match() to show each attempted match Product: Portable OpenSSH Version: 7.1p1 Hardware: Other OS: Linux Status: NEW Severity: enhancement Priority: P5 Component:

http://bugzilla.mindrot.org/show_bug.cgi?id=938 Summary: "AllowGroups" option and secondary user's groups limit Product: Portable OpenSSH Version: 3.9p1 Platform: ix86 OS/Version: Linux Status: NEW Severity: major Priority: P2 Component: PAM support AssignedTo: openssh-bugs at

Hello, I am trying to force a command for all users *except* for users in the "wheel" group. My idea was to do the following in sshd_config: ForceCommand /usr/bin/validate-ssh-command Match Group wheel ForceCommand But obviously this doesn't work, because ForceCommand requires an argument. I couldn't find a way to achieve what I want. I wrote a patch that adds a

I added a few features to openssh for my local use that I think would be more broadly useful. I basically added access control lists to control who would be allowed public key authentication. I added four config file entries for the server: PubkeyAllowUsers PubkeyDenyUsers PubkeyAllowGroups PubkeyDenyGroups These follow the same sematics as the already existing entries for

Please find attached a patch against openssh-4.7p1 It extends the Match in sshd_config. The point is that it is sometimes easier (and more secure) to match on NOT something. A criterium may be preceded by ! which inverts the condition, thus: Match !Group sysadmins ForceCommand /usr/bin/sftp forces use of sftp on any user who is not a system administrator. A !! has the

https://bugzilla.mindrot.org/show_bug.cgi?id=1680 Summary: Match User/Group with no affirmative match does not work as expected Product: Portable OpenSSH Version: 5.3p1 Platform: Other OS/Version: All Status: NEW Severity: normal Priority: P2 Component: ssh AssignedTo:

http://bugzilla.mindrot.org/show_bug.cgi?id=999 Summary: AllowGroups ,DenyGroups failed to report hostname Product: Portable OpenSSH Version: 4.0p1 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: sshd AssignedTo: openssh-bugs at mindrot.org ReportedBy:

hi, using the example in the grep help: txt <- c("arm","foot","lefroo", "bafoobar") i <- grep("foo",txt); i [1] 2 4 but how can i get the negation (1,3) when looking for 'foo'? thanks, m.

Hi, I recently came across the following in __floatsidf in compiler-rt: __floatsidf(int a) { ... if (a < 0) { ... a = -a; In the case where a == INT_MIN, is this negation not undefined behaviour? AIUI this function is used for software emulation on targets that have no hardware floating point support. Perhaps there is an in-built assumption

Hi all, this is a patch to make Ciphers, MACs and KexAlgorithms available in Match blocks. Now I can reach a -current machine with some Android terminal app without changing the default ciphers for all clients: Match Address 192.168.1.2 Ciphers aes128-cbc MACs hmac-sha1 KexAlgorithms diffie-hellman-group-exchange-sha1 Index: servconf.c

Could everyone please test the latest snapshots as we will be making a new release soon. If you have any patches you would like us to consider, please resend them to the list ASAP. -d -- | Damien Miller <djm at mindrot.org> \ ``E-mail attachments are the poor man's | http://www.mindrot.org / distributed filesystem'' - Dan Geer

Hi, I want to come to a specific behavior described in https://access.redhat.com/solutions/289073 For example, taking an user who is NOT a member of a group *-foo Match Group !*-foo => this won't match Match Group *,!*-foo => this will match I would expect the first to match too, intuitively. I'm unsure if this behavior is expected, and if not, if it has a corresponding bug

OpenSSH 3.0 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 version 1.3, 1.5 and 2.0 implementation and includes sftp client and server support. This release contains many portability bug-fixes (listed in the ChangeLog) as well as several new features (listed below). We would like to thank the

https://bugzilla.mindrot.org/show_bug.cgi?id=1690 Summary: AllowUsers and DenyGroups directives are not parsed in the order specified Product: Portable OpenSSH Version: 5.3p1 Platform: ix86 OS/Version: Linux Status: NEW Keywords: patch Severity: trivial Priority: P2 Component:

https://bugzilla.mindrot.org/show_bug.cgi?id=2292 Bug ID: 2292 Summary: sshd_config(5): DenyUsers, AllowUsers, DenyGroups, AllowGroups should actually tell how the evaluation order matters Product: Portable OpenSSH Version: 6.7p1 Hardware: All OS: All Status: NEW

Full_Name: Drouilhet R?my Version: 1.8.1 OS: Linux Submission from: (NULL) (195.221.43.136) qchisq(1,10) works well but qchisq(1,10,ncp=0) does not work whereas ncp=0 is the default value of the function qchisq(1,10). (of course, 10 will be replaced by any integer value). Let us notice that this bug occurs only when applying probability one. (qchisq(seq(0,.9,.1),10,ncp=0) works very well).

Windows usernames are case-insensitive and almost any Unicode character is allowed in a username. The user should be able to login with her username given in any case and not be refused. However, this opens up a security problem in terms of the sshd_config Match rules. The match rules for user and group names have to operate case-insensitive as well, otherwise the user can override her settings