Description of problem: The default umask for standard user accounts per logic in /etc/bashrc is 002 (rwx/rwx/rx). With these configured permissions on ~/.ssh and ~/.ssh/authorized_keys, pubkey authentication will fail, with the sshd-reported error: Dec 22 06:56:01 <hostname> sshd[11930]: Authentication refused: bad ownership or modes for file /home/<username>/.ssh/authorized_keys Version-Release number of selected component (if applicable): Fedora 21 Server How reproducible: Any Fedora 21 Server installation should present the issue. Steps to Reproduce: 1. Perform Fedora 21 Server installation. 2. Log in via password-authenticated ssh. 3. mkdir ~/.ssh 4. Insert pubkey string into ~/.ssh/authorized_keys 5. Attempt to log in via pubkey-authenticated ssh. Actual results: Pubkey authentication fails, password login requested. Above error displayed in system journal. Expected results: Pubkey authentication succeeds. Additional info: None.
http://docs.fedoraproject.org/en-US/Fedora/14/html/Deployment_Guide/s2-ssh-configuration-keypairs.html explicitly describes the procedure with chmod. I don't think it is good idea to change the default umask just because of this. Btw. this file belongs to setup component, not to bash itself.
Debian, Fedora, OpenSUSE, CentOS and RHEL all use 0022 as a umask; only Fedora uses 0002. What is the reasoning behind Fedora's use of a less-secure default umask?
(In reply to Jessica K. Litwin from comment #2) > Debian, OpenSUSE, CentOS and RHEL all use 0022 as a umask; only > Fedora uses 0002. > > What is the reasoning behind Fedora's use of a less-secure default umask? Fixed.
er yes i mentioned fedora twice i'm not very smart before coffee.
bashrc umask code on both RHEL and Fedora is: if [ $UID -gt 199 ] && [ "`id -gn`" = "`id -un`" ]; then umask 002 else umask 022 fi So for UID's higher than 200 with eff. group name == eff. user name (IOW, common users and dynamic system groups), umask is 002 on both RHEL and Fedora. For static UID's lower lower than 200, umask is 022. If you login via ssh as a root, your UID is 0, and id -gn == id -un == root. Therefore, you should have umask 022. Am I missing something? Common users and dynamic system accounts always had umask 002 on both Fedora and RHEL - so comment #2 is imho not valid.
(In reply to Ondrej Vasik from comment #5) > bashrc umask code on both RHEL and Fedora is: > if [ $UID -gt 199 ] && [ "`id -gn`" = "`id -un`" ]; then > umask 002 > else > umask 022 > fi > > So for UID's higher than 200 with eff. group name == eff. user name (IOW, > common users and dynamic system groups), umask is 002 on both RHEL and > Fedora. > For static UID's lower lower than 200, umask is 022. > > If you login via ssh as a root, your UID is 0, and id -gn == id -un == root. > Therefore, you should have umask 022. Am I missing something? > Common users and dynamic system accounts always had umask 002 on both Fedora > and RHEL - so comment #2 is imho not valid. This is exactly the problem IMHO. The threshold at 200 is ancient[0] now. This script should be using the value of SYS_UID_MIN from /etc/login.defs, especially since the local administrator may have need to change the threshold. (We did because we have many UIDs defined in LDAP and shared across many hosts and file systems that would otherwise conflict with the new policy.) [0] https://fedoraproject.org/wiki/Features/1000SystemAccounts
Err, I should have said UID_MIN from login.defs. id < SYS_UID_MIN are statically defined system accounts whilst SYS_UID_MIN <= id < UID_MIN are dynamically defined system accounts. Everything < UID_MIN is a system account however and deserves a umask of 002.
Threshold 200 has nothing to do with mitr proposal [0]. Static id threshold is independent of the dynamic threshold. Anyway, probably worth to change in rawhide, dropping this split between system accounts and user accounts completely. Reassigning to setup package as bash has nothing to do with this issue in anycase. [0] https://fedoraproject.org/wiki/Features/1000SystemAccounts
This message is a reminder that Fedora 21 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 21. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '21'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 21 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
This bug appears to have been reported against 'rawhide' during the Fedora 24 development cycle. Changing version to '24'. More information and reason for this action is here: https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora24#Rawhide_Rebase
I'm possibly running into this issue, but unclear. I upgraded from F23->F24, where I had sudo enable to auth via ssh-agent auth. This worked fine, until after the upgrade. I'm getting the following errors in the /var/log/secure file: Jun 22 18:33:05 loki sshd[1451]: pam_unix(sshd:session): session opened for user leif by (uid=0) Jun 22 18:33:08 loki sudo[1488]: Authentication refused: bad ownership or modes for file /home/leif/.ssh/authorized_keys Jun 22 18:33:08 loki sudo[1488]: Authentication refused: bad ownership or modes for file /home/leif/.ssh/authorized_keys However, I'm pretty confident my .ssh etc. are correct: loki (18:35) 259/0 $ ls -ld .ssh drwx------ 1 leif users 322 Jun 22 17:50 .ssh/ loki (18:35) 260/0 $ ls -l .ssh/authorized_keys -rw------- 1 leif users 740 Dec 15 2010 .ssh/authorized_keys loki (18:36) 261/0 $ id uid=504(leif) gid=100(users) groups=100(users),10(wheel)
(In reply to Leif Hedstrom from comment #11) > I'm possibly running into this issue, but unclear. I upgraded from F23->F24, > where I had sudo enable to auth via ssh-agent auth. This worked fine, until > after the upgrade. I'm getting the following errors in the /var/log/secure > file: > > Jun 22 18:33:05 loki sshd[1451]: pam_unix(sshd:session): session opened for > user leif by (uid=0) > Jun 22 18:33:08 loki sudo[1488]: Authentication refused: bad ownership or > modes for file /home/leif/.ssh/authorized_keys > Jun 22 18:33:08 loki sudo[1488]: Authentication refused: bad ownership or > modes for file /home/leif/.ssh/authorized_keys This is apparently a problem with openssh, not with default umask in bashrc. > However, I'm pretty confident my .ssh etc. are correct: > > loki (18:35) 259/0 $ ls -ld .ssh > drwx------ 1 leif users 322 Jun 22 17:50 .ssh/ > loki (18:35) 260/0 $ ls -l .ssh/authorized_keys > -rw------- 1 leif users 740 Dec 15 2010 .ssh/authorized_keys > > loki (18:36) 261/0 $ id > uid=504(leif) gid=100(users) groups=100(users),10(wheel) Looks correct to me. Please file a bug against openssh.
(In reply to Leif Hedstrom from comment #11) > I'm possibly running into this issue, but unclear. I upgraded from F23->F24, > where I had sudo enable to auth via ssh-agent auth. This worked fine, until > after the upgrade. I'm getting the following errors in the /var/log/secure > file: > > Jun 22 18:33:05 loki sshd[1451]: pam_unix(sshd:session): session opened for > user leif by (uid=0) > Jun 22 18:33:08 loki sudo[1488]: Authentication refused: bad ownership or > modes for file /home/leif/.ssh/authorized_keys > Jun 22 18:33:08 loki sudo[1488]: Authentication refused: bad ownership or > modes for file /home/leif/.ssh/authorized_keys For the reference, the above issue is now tracked separately: bug #1349551
This message is a reminder that Fedora 24 is nearing its end of life. Approximately 2 (two) weeks from now Fedora will stop maintaining and issuing updates for Fedora 24. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '24'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 24 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 24 changed to end-of-life (EOL) status on 2017-08-08. Fedora 24 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.