[Bug 2713] New: Please provide a StrictModes-like setting (command line parameter) for ssh (client)

bugzilla-daemon at bugzilla.mindrot.org bugzilla-daemon at bugzilla.mindrot.org
Sun May 7 22:41:30 AEST 2017


https://bugzilla.mindrot.org/show_bug.cgi?id=2713

            Bug ID: 2713
           Summary: Please provide a StrictModes-like setting (command
                    line parameter) for ssh (client)
           Product: Portable OpenSSH
           Version: 7.5p1
          Hardware: Other
                OS: Other
            Status: NEW
          Severity: enhancement
          Priority: P5
         Component: ssh
          Assignee: unassigned-bugs at mindrot.org
          Reporter: sascha-openssh-bugs at silbe.org

Background: We're using rsync over ssh to mirror a directory tree to a
set of remote servers, with rrsync as a forced command on the server
side to restrict access to the target directory. An entire group of
people as well as an automated process using a separate user account
need to be able to perform the transfer. Some of the people involved
also have unrestricted access. Because rrsync uses the target directory
as the root of the accessible hierarchy, the paths to use for
restricted and unrestricted access are different. So it makes a whole
world of difference which private key is chosen.

The very strict "only the user may be able to read the private key
file" check hurts us quite a bit here. It's also OpenSSH enforcing its
own policy that doesn't match our threat model at all. sshd has a way
to explicitly disable those checks (StrictModes no) for
authorized_keys, but the _client_ (of all things) refuses to load
private keys that are group-readable (but not world-readable) with no
way to tell it that, yes, this is exactly what we want and need.

We're currently using the work-around of running "ssh-add - <
foo/id_rsa", but that's just that: a work-around. Besides other things
it requires ssh-agent to be running.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.


More information about the openssh-bugs mailing list