[Bug 2500] New: ConnectionAttempts=0 causes ssh to output uninitialised data on stdout
https://bugzilla.mindrot.org/show_bug.cgi?id=2500 Bug ID: 2500 Summary: ConnectionAttempts=0 causes ssh to output uninitialised data on stdout Product: Portable OpenSSH Version: 7.1p1 Hardware: amd64 OS: Linux Status: NEW Severity: normal Priority: P5 Component: ssh Assignee: unassigned-b...@mindrot.org Reporter: d...@phas.ubc.ca Using ssh with ConnectionAttempts set to zero results in the contents of uninitialised memory being sent to stdout. For example: $ ssh -o ConnectionAttempts=0 somehost ssh: connect to host somehost port \200\335q\002\374\177: Success Cause: When ssh_connect_direct() is passed connection_attempts=0, the strport[] buffer is never initialised, since the whole attempt loop is skipped. Its contents are later output in the error message after the skipped loop (sshconnect.c:485). -- 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 2492] Incomplete output of child process
https://bugzilla.mindrot.org/show_bug.cgi?id=2492 --- Comment #17 from Marc Aurele La France --- 1) If you are using this Bugzilla to report a problem with openssh, then it must be against a stock version of it, not one polluted with Ubuntu-isms. 2) You state the problem only occurs on 15.10, regardless of openssh version. This makes it quite conclusive where the real issue lies, not in openssh. -- You are receiving this mail because: You are watching someone on the CC list of the bug. 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 2492] Incomplete output of child process
https://bugzilla.mindrot.org/show_bug.cgi?id=2492 --- Comment #16 from Volth --- Among all Ubuntus, Debians and CoreOSes on Google Cloud Engine: 1. With the regular version of openssh the problem is only on Ubuntu 15.10 (one may say "only with Kernel 4.xx") 2. On Ubuntu 15.10 the problem is reproducible not only with regular version but also with github master and older versions (random version from github master 1, 2 and 3 years ago) There was no reason for trying different openssh version on Ubuntu 15.04 -- 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 2492] Incomplete output of child process
https://bugzilla.mindrot.org/show_bug.cgi?id=2492 --- Comment #15 from Volth --- (In reply to Marc Aurele La France from comment #13) > EGAIN means there is no data available at the time of the call. > But, in the case here, this contradicts the fact that the child has > previously written the last of its data, closed the tty and > signalled the parent about its demise. Therefore, there >is< data > available, but for whatever reason 15.10's kernel decides not to > return it. I am not sure the data must be available. Note that /bin/ping is not spawned by openssh directly, the data to be copied (perhaps lazily) through the chain of stdouts. > So, I'll ask (e)again: does 7.1p1 exhibit the same behaviour on > 15.04 (which runs a much older kernel) or not? I have not tried this combination. -- You are receiving this mail because: You are watching someone on the CC list of the bug. 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 2492] Incomplete output of child process
https://bugzilla.mindrot.org/show_bug.cgi?id=2492 --- Comment #14 from Volth --- I have not tried this combination. -- You are receiving this mail because: You are watching someone on the CC list of the bug. 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 2492] Incomplete output of child process
https://bugzilla.mindrot.org/show_bug.cgi?id=2492 --- Comment #13 from Marc Aurele La France --- EGAIN means there is no data available at the time of the call. But, in the case here, this contradicts the fact that the child has previously written the last of its data, closed the tty and signalled the parent about its demise. Therefore, there >is< data available, but for whatever reason 15.10's kernel decides not to return it. So, I'll ask (e)again: does 7.1p1 exhibit the same behaviour on 15.04 (which runs a much older kernel) or not? -- 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 2499] New: It would be nice to have a tool to manage ssh connections
https://bugzilla.mindrot.org/show_bug.cgi?id=2499 Bug ID: 2499 Summary: It would be nice to have a tool to manage ssh connections Product: Portable OpenSSH Version: 7.1p1 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 Component: sshd Assignee: unassigned-b...@mindrot.org Reporter: ren...@woralelandia.com A tool for managing ssh connections is needed. For example, when you have a user compromised and wish to kill a certain connection and not the user. Example case: postgres Let's say you enable ssh login for postgres; key based. For some reason, the user gets compomised and you end up with somebody connecting from outside, using the postgres user. You don't want to kill the user because the DBs are running on it; just close the intruder's connection and disable ssh for the postgres user. Example: shared root Sometimes, several users have ssh access to a server. You might want to kill a connection just because that user is not supposed to be logged in at that time; while blocking his IP. In this case, you don't want to pkill the root user. You just want to close that particular ssh connection and have the user explain what was he/she doing at the time. Example: timed connections It would be cool to allow ssh connections at certain dates and hours. A user might need to connect only during work hours. Disallowing connections after that would be awesome. In any case, a connection management tool could be very useful. -- 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 2498] New: Allow StrictModes to be controlled by Match
https://bugzilla.mindrot.org/show_bug.cgi?id=2498 Bug ID: 2498 Summary: Allow StrictModes to be controlled by Match Product: Portable OpenSSH Version: 7.1p1 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 Component: sshd Assignee: unassigned-b...@mindrot.org Reporter: c...@bongalow.net It would be useful in some cases to be able to selectively disable StrictModes checks, depending on particulars of a connection (e.g. only for user alice) so that one can keep the extra safety check for most users. Seems like the Match directive would be a natural way to make this happen, but currently Match does not support StrictModes. -- 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 1089] StrictModes needs runtime granularity
https://bugzilla.mindrot.org/show_bug.cgi?id=1089 c...@bongalow.net changed: What|Removed |Added CC||c...@bongalow.net -- 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 2492] Incomplete output of child process
https://bugzilla.mindrot.org/show_bug.cgi?id=2492 --- Comment #12 from Volth --- EAGAIN does not mean "there is no more data" it means there is data, please try to read it a bit later. -- You are receiving this mail because: You are watching someone on the CC list of the bug. 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 2492] Incomplete output of child process
https://bugzilla.mindrot.org/show_bug.cgi?id=2492 --- Comment #11 from Marc Aurele La France --- I'd expect the ordering of events within the server/client conversation to vary. I wouldn't read too much into it. But that's not the issue here. The problem is that the kernel is telling the parent there is no more data from the child when in fact there is. So does 7.1p1 behave the same on 15.04? If not, I'd say you have some kernel digging to do. -- You are receiving this mail because: You are watching someone on the CC list of the bug. 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 2497] New: Add debugging information to ga_match() to show each attempted match
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: sshd Assignee: unassigned-b...@mindrot.org Reporter: jje...@redhat.com Created attachment 2752 --> https://bugzilla.mindrot.org/attachment.cgi?id=2752&action=edit verbose group match logging When using identity management it can be tricky to debug non-local users logins, especially in combination with many groups used, as described in our bugzilla [1] (related pull request on github [2]). The actual problem is lying in sssd, but having this feature can help to debug and understand what is going on under the hood of sshd during login time and during group matching. Steps to Reproduce: 1. Set 'AllowGroups test_group "domain user group"' to the /etc/ssh/sshd_config file 2. Set 'LogLevel Debug3' in the /etc/ssh/sshd_config file. 3. Restart sshd. 4. Attempt to log in with a user in the 'users' group. Actual results: 5. Remain puzzled Expected results: 5. Find out that the "domain user group" is never being pulled from the group list and so never matches. Or something. Original patch is by Paul Wayper [1] https://bugzilla.redhat.com/show_bug.cgi?id=1283011 [2] https://github.com/openssh/openssh-portable/pull/33 -- 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 2038] permitopen functionality but for remote forwards
https://bugzilla.mindrot.org/show_bug.cgi?id=2038 Peter �strand changed: What|Removed |Added CC||astr...@lysator.liu.se -- 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
