[Bug 2266] Bugs intended to be fixed in 6.8
https://bugzilla.mindrot.org/show_bug.cgi?id=2266 Bug 2266 depends on bug 2287, which changed state. Bug 2287 Summary: AuthorizedKeysCommandUser should have it's default documented https://bugzilla.mindrot.org/show_bug.cgi?id=2287 What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- -- You are receiving this mail because: You are watching the assignee of the bug. You are watching the reporter of the bug. ___ openssh-bugs mailing list openssh-bugs@mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-bugs
[Bug 2287] AuthorizedKeysCommandUser should have it's default documented
https://bugzilla.mindrot.org/show_bug.cgi?id=2287 Christoph Anton Mitterer changed: What|Removed |Added Resolution|FIXED |--- Status|RESOLVED|REOPENED --- Comment #5 from Christoph Anton Mitterer --- Hey Damien. Let me just reopen this once more as I've discovered by chance another unexpected behaviour by this (which might be a bug)... just have a look and decide... and feel free to close it again. As we found out above, having: "AuthorizedKeysCommandUser" unset while having "AuthorizedKeysCommand" set to anything but "none" and the daemon will not start. Interestingly, having AuthorizedKeysCommandUser set to the empty value, e.g. AuthorizedKeysCommand /bin/test AuthorizedKeysCommandUser and the daemon *will* actually start, but it seems that /bin/test is nevertheless never executed. So this is no security issue, but I guess for consistency it shouldn't start either when AuthorizedKeysCommandUser is explicitly set to the empty value. Thanks, Chris. -- You are receiving this mail because: You are watching the assignee of the bug. You are watching someone on the CC list of the bug. ___ openssh-bugs mailing list openssh-bugs@mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-bugs
[Bug 2357] please add "vhosting" features respectively per-LocalAdress HostKeys/etc.
https://bugzilla.mindrot.org/show_bug.cgi?id=2357 --- Comment #1 from Christoph Anton Mitterer --- See also bug #2358, which is kinda related to vhosting functionalities. :) -- You are receiving this mail because: You are watching the assignee of the bug. ___ openssh-bugs mailing list openssh-bugs@mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-bugs
[Bug 2358] New: allow sshd to "redirect" to another local user
https://bugzilla.mindrot.org/show_bug.cgi?id=2358 Bug ID: 2358 Summary: allow sshd to "redirect" to another local user Product: Portable OpenSSH Version: 6.7p1 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 Component: sshd Assignee: unassigned-b...@mindrot.org Reporter: cales...@scientia.net Hi. This request is very close to bug #2357, i.e. it could be very handy to have it for "vhosting" like use cases in SSH, but I think it may also be generally useful, which is why I filed it as a separate enhancement request. It would be nice if sshd could "redirect" a connection to user foo to another local user bar, consider roughly the following sshd_config: Match User foo User bar Let me bring again my git/gitolite use case as an example where this could be helpful for vhosting: Match User git LocalAddress 11.22.33.44 User git-a Match User git LocalAddress 11.22.33.55 User git-b So one would have e.g. two domains, pointing to different IPs, which however both go to the same physical host (and thus sshd). In that example it would be desired, that the two git/gitolites are completely separate, i.e. no shared "usernames" (which they implement via ssh keys), no shared repositories between the two domains and so on. Right now, one would need two different user accounts for this, and two different git/gitolite installations. But this in turn "breaks" the typical convention of using "git" as the connecting username. The above functionality would allow this, basically hiding that there is actually another user, with different UID, home, etc. being used. And restricted environments (like gitolite) would really hide this from the user. Another possible (non-vhosting related) use case could be that bigger installations (in terms of users) give their users either aliases for their logins (e.g. it's often the case that people have multiple email addresses one being like "christoph.mitterer" and the other being the account name like "cmitterer" - then people could log in with both)... or temporary redirects in case the username is changed, e.g. one marries and "cmitterer" would become "cmueller", then I could login for a while with both (and especially all scripts/etc. where the name might be hardcoded would continue to function for a while, till I migrated them. Admittedly, I haven't much thought about any possible security implications of this - at least at a first glance I wouldn't see any. Cheers, Chris. -- You are receiving this mail because: You are watching the assignee of the bug. ___ openssh-bugs mailing list openssh-bugs@mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-bugs
[Bug 2357] New: please add "vhosting" features respectively per-LocalAdress HostKeys/etc.
https://bugzilla.mindrot.org/show_bug.cgi?id=2357 Bug ID: 2357 Summary: please add "vhosting" features respectively per-LocalAdress HostKeys/etc. Product: Portable OpenSSH Version: 6.7p1 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 Component: sshd Assignee: unassigned-b...@mindrot.org Reporter: cales...@scientia.net Hi. Given that SSH is such a nice protocol and that the FLOSS community has such a great implementation with OpenSSH, the protocol is used in many places far beyond the traditional "remote shell". For many of these it would be interesting to have vhosting like capabilities, i.e. that multiple "addresses" point to one physical node (where the sshd runs) and one can set options/change behaviour depending on the "address" that the clients actually chose. Unlike e.g. http where there is a "Host:" header or TLS where there is SNI, we (AFAIK) only know about the IP address/port that a client uses to connect. But for vhosting many cases this would already be enough, and especially with the rise of IPv6, everyone will have "unlimited" addresses. Right now, one can already set quite a number of options based on the address a client connects to, e.g. via Match LocalAddress unfortunately though this isn't possible yet, for some options that would be crucial for vhosting, most notably: HostKey Example (why this would be so useful): A server, which runs ssh to provide admins the remote shell. It also runs via-ssh services, like git. At first this isn't much of a problem: Even if I want my git users to use another domainname (e.g. git.example.org) than what the admins use to connect to the node (e.g. host123.example.org)... this works out, because nothing forbids the same host key to be used for multiple addresses. But when one starts to do more advanced things like the following, one runs into the limitation: Consider I do not only wish one host behind git.example.org, but rather a round-robin-DNS set (for availability or whatever). So I'd have distinct servers like: a.git.example.org b.git.example.org and so on and git.example.org points to all of them. Then consequence, for authentication to work with "git.example.org" is that all hosts needed to use the same keys... which is a bad idea. If one host is compromised, all could be attacked... for the "git" user, which is anyway just via some restricted system (git-shell or gitolite) reachable... this wouldn't be that big problem. But for the other use case of these SSH's i.e. access to the systems for admins... this would be quite bad. Right now, the only way to solve this is by running multiple sshd with different config files and so on. I guess that works, but if it would be easy to make HostKeys configurable per LocalAddress, that would simply things quite a bit for the admins :) Of course it would also be nice if further options like the Alogs, Compression, UsePam, uselogin,... etc. could be set on a per user / per localaddress basis. But I'm not sure how easy that would be. Best wishes, Chris. -- You are receiving this mail because: You are watching the assignee of the bug. ___ openssh-bugs mailing list openssh-bugs@mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-bugs
