[Bug 2352] New: also look for host-prefixed ar, to avoid using ie /usr/bin/ar when cross compiling
https://bugzilla.mindrot.org/show_bug.cgi?id=2352 Bug ID: 2352 Summary: also look for host-prefixed ar, to avoid using ie /usr/bin/ar when cross compiling Product: Portable OpenSSH Version: -current Hardware: Other OS: Linux Status: NEW Severity: enhancement Priority: P5 Component: Build system Assignee: unassigned-b...@mindrot.org Reporter: astr...@lysator.liu.se It seems like this patch: http://lists.mindrot.org/pipermail/openssh-unix-dev/2013-September/031646.html ...was never accepted. If there are no good reasons to object it, please apply. -- 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 2319] [PATCH REVIEW] U2F authentication
https://bugzilla.mindrot.org/show_bug.cgi?id=2319 Matt Johnston m...@ucc.asn.au changed: What|Removed |Added CC||m...@ucc.asn.au --- Comment #10 from Matt Johnston m...@ucc.asn.au --- (I'm looking at https://datatracker.ietf.org/doc/draft-josefsson-secsh-u2f/?include_text=1 ) I think it would be worth using the 32 byte challenge to bind the authentication to the current SSH session. Otherwise an attacker running a SSH server can get their clients to sign a response for another server if they know an entry from authorized_keys (because of origin/appid of ssh://localhost)? Maybe something like challenge = chal_sess_hash | 16_random_bytes where chal_sess_hash is a 16 byte truncated sha256 hash of stringsession identifier byte SSH_MSG_USERAUTH_REQUEST stringuser name stringservice name stringu2f The client MUST check that the first 16 bytes is correct - that's slightly more complexity (decoding JSON) though the code's already there for the server. That would also improve resistance to MITM even if the server hostkey is compromised/ignored. Existing SSH public key authentication does that by including the sessionid in the hash being signed (rfc4253 page 9). For integration with SSH I think a constant origin/appid string is probably useful - people expect to be able to connect to a host at varying IPs/hostnames. Copy/pasting from one host's authorized_keys to another is also common practise. -- 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 2355] general protection / segfaults when PermitOpen=none
https://bugzilla.mindrot.org/show_bug.cgi?id=2355 Christoph Anton Mitterer cales...@scientia.net changed: What|Removed |Added See Also||http://bugs.debian.org/7788 ||07 -- 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 2353] New: options allowed for Match blocks missing form documentation
https://bugzilla.mindrot.org/show_bug.cgi?id=2353 Bug ID: 2353 Summary: options allowed for Match blocks missing form documentation Product: Portable OpenSSH Version: 6.7p1 Hardware: All OS: All Status: NEW Severity: minor Priority: P5 Component: Documentation Assignee: unassigned-b...@mindrot.org Reporter: cales...@scientia.net Hi. AFAIU such options which are allowed for Match blocks are marked with SSHCFG_ALL in servconf.c. Going through the list, a number of the is apparently allowed but missing from sshd_config(5): AllowStreamLocalForwarding IPQoS RevokedKeys StreamLocalBindMask StreamLocalBindUnlink TrustedUserCAKeys Could you please add these? I'd have written a patch, but since all my pull requests are apparently generally ignored it's probably just a waste of time :( 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 2354] New: please document that PermitRootLogin really checks for uid=0
https://bugzilla.mindrot.org/show_bug.cgi?id=2354 Bug ID: 2354 Summary: please document that PermitRootLogin really checks for uid=0 Product: Portable OpenSSH Version: 6.7p1 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 Component: Documentation Assignee: unassigned-b...@mindrot.org Reporter: cales...@scientia.net Hey. I just found out that PermitRootLogin has the feature of really checking for UID=0 and not for the username root I.e. it makes sense to have something like: Match user toor PermitRootLogin no Which would allow root=0 to log in, but not e.g. the toor=0 user to log in, if it is an alternative root user. :) nice feature! (bad name, though ^^) 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
