Bug 2317 - sshd_config man page not clear on PermitUserEnvironment
Summary: sshd_config man page not clear on PermitUserEnvironment
Status: CLOSED WONTFIX
Alias: None
Product: Portable OpenSSH
Classification: Unclassified
Component: sshd (show other bugs)
Version: 6.6p1
Hardware: All All
: P5 enhancement
Assignee: Assigned to nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-11-15 12:53 AEDT by Florin Andrei
Modified: 2016-08-02 10:41 AEST (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Florin Andrei 2014-11-15 12:53:44 AEDT
From the current man page:

PermitUserEnvironment
             Specifies whether ~/.ssh/environment and environment= options in ~/.ssh/authorized_keys are processed by sshd(8).  The default is “no”.  Enabling environment pro‐cessing may enable users to bypass access restrictions in some configurations using mechanisms such as LD_PRELOAD.

What that sounds to me like is that enabling that option weakens the security in general.

But after some googling I came across this discussion:

http://serverfault.com/questions/527638/security-risks-of-permituserenvironment-in-ssh

According to the answer, PermitUserEnvironment only weakens security for restricted accounts, such as scp-only, etc., but has no impact on full shell access accounts. If that is correct, then the man page is incomplete and misleading.

I need that option enabled, but I was hesitant to use it. I almost decided to not use it, but then I came across that discussion.

Please add a brief note to that entry in the man page, making clear that there are no security issues with that option if all accounts have full shell access (of course, assuming my interpretation is correct).

Thanks.
Comment 1 Damien Miller 2014-12-11 15:59:05 AEDT
Unfortunately the reality is a little more complex than that. Restricted accounts may be invoked by the user's shell that may be affected by environment variables. It's impractical to list all the possible cases where enabling this has unexpected consequences, so we leave it to the administrator's discretion and knowledge of their own system.

I don't see any reason to modify the text to weaken the warning.
Comment 2 Damien Miller 2016-08-02 10:41:31 AEST
Close all resolved bugs after 7.3p1 release