Bug 2713

Summary: Please provide a StrictModes-like setting (command line parameter) for ssh (client)
Product: Portable OpenSSH Reporter: Sascha Silbe <sascha-openssh-bugs>
Component: sshAssignee: Assigned to nobody <unassigned-bugs>
Status: NEW ---    
Severity: enhancement    
Priority: P5    
Version: 7.5p1   
Hardware: All   
OS: All   

Description Sascha Silbe 2017-05-07 22:41:30 AEST 
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.
Comment 1 Sascha Silbe 2018-07-07 19:28:46 AEST 
Since GnuPG 2.1, gpg-agent (in SSH agent emulation mode) doesn't work with password-less keys anymore so our work-around of feeding the private key into ssh-add via stdin stopped working.

The refusal of the OpenSSH client to use group-readable private keys is becoming a real pain; we have to stack up work-around upon work-around.

How the private key should be protected is a matter of threat model and policy, not a technical matter. It's OK if OpenSSH warns the user about potentially unsafe permissions _by_ _default_, but it should not _force_ users to follow the OpenSSH developer's policy that matches the OpenSSH developer's threat model only.