Bug 614671

Summary: sshd Authentication refused
Product: [Fedora] Fedora Reporter: David Highley <dhighley>
Component: opensshAssignee: Jan F. Chadima <jchadima>
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: 13CC: edgar.hoch, jchadima, mgrepl, tmraz
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2010-07-20 22:42:23 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Attachments:
Description Flags
ssh -v -v -v output
none
sshd -d -d -d output none

Description David Highley 2010-07-14 19:07:08 EDT
Description of problem:
Authentication refused: bad ownership or modes for file /home/dhighley/.ssh/authorized_keys

Version-Release number of selected component (if applicable):
openssh-server-5.4p1-3.fc13.x86_64

How reproducible:
Every time

Steps to Reproduce:
1.Fedora 12 -> Fedora 13 ssh host
2.autofs mounted home directories served from Fedora 12 and NIS
3.Fedora 13 client
  
Actual results:
password prompt; public keys not accepted


Expected results:
no password prompt

Additional info:
"Rick Sewill wrote:"
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 07/13/2010 01:43 PM, Kevin Fenzi wrote:
> > On Tue, 13 Jul 2010 11:16:46 -0700 (PDT)
> > David Highley <dhighley@highley-recommended.com> wrote:
> > 
> >> New install of Fedora 13 we get the following /var/log/secure entry
> >> when we ssh from a Fedora 12 system to the Fedora 13 system:
> >> Authentication refused: bad ownership or modes for
> >> file /home/dhighley/.ssh/authorized_keys
> >>
> >> We have checked and tried different modes until we are blue in the
> >> face. Have read the upates notes for openssh and Fedora 13 release.
> >> Googled the net for know issues and bugzilla.redhat.com. We did check
> >> for selinux blocks and found none.
> >>
> >> User home directory is auto NFS mounted and we use NIS. This works
> >> Fedora 12 to Fedora 12.
> > 
> > You may want to use 'ssh-copy-id' to copy the key over to the f13
> > system. That will setup the right permissions and such automatically
> > for you. 

Where would I copy it if I'm using auto mounted home directories?

> > 
> > Also, you will want to see if there are any selinux alerts on the f13
> > machine. 'ausearch -m avc -ts today' can list the ones from today. 

See above, we did check for selinux denials. We also did a restorcon -v
-R .ssh just in case and nothing changed.

> > 
> > kevin
> > 
> 
> I cannot explain how f12 <--> f12 works, but f12 <--> f13 does not.
> I can only guess there is something different for the NFS mount -or-
> something different regarding NIS.
> 
> =====
> 
> One possibility, which I consider very, very remote is the following.
> 
> I may be wrong but I think the ownership and modes for all the parent
> directories from your /home/dhighley/.ssh directory also matter.

Directory .ssh has mode of 700.
File .ssh/authorized_keys has a mode of 600
Home directory dhighley has a mode of 750

All are owned by the user and the user's group.

> 
> I assume you made sure /home/dhighley/.ssh is mode 700.
> What is the mode of /home/dhlighley?  Is it 755 (I think that's okay).
> I think any write mode for group or other would be bad.
> I assume /home/dhlighley is owned by you, the user.
> 
> What about /home?  Who owns it?  What is it's mode?
> I think root must own it.
> I think only root should have write access to it.

Mode of /home is 755 and owned by root on the NFS server and the client
Fedora 13 system.

> 
> I actually assume the ownership and modes are all correct...the
> possibility of this being the problem seems exceedingly rare to me, but
> please check.
> 
> =====
> 
> Another possibility, which I also consider remote, but is worth asking.
> On the f13 machine, when you log in as dhlighley, is the user name only
> found in NIS?  On occasion, if one is testing something new, one might
> put in a local account in the /etc/passwd file, and forget it is there.
> Depending on your /etc/nsswitch.conf file, the local file is probably
> checked before NIS.

There are no local user file entries on the Fedora 13 system.
> 
> Sorry, can't think of anything else.  Others have already mentioned selinux.
 On 7/13/2010 3:49 PM, jack craig wrote:
> > 
> > 
> > On 07/13/2010 11:16 AM, David Highley wrote:
> 
> >> User home directory is auto NFS mounted and we use NIS. This works
> >> Fedora 12 to Fedora 12.
> 
> Have you tried this:
>    setsebool -P use_nfs_home_dirs1 1

Yes

[root@redwood ~]# getsebool use_nfs_home_dirs
use_nfs_home_dirs --> on

"jack craig wrote:"
> 
> 
> 
> On 07/13/2010 01:36 PM, David Highley wrote:
> > "jack craig wrote:"
> >    
> >>
> >>
> >> On 07/13/2010 11:16 AM, David Highley wrote:
> >>      
> >>> New install of Fedora 13 we get the following /var/log/secure entry when
> >>> we ssh from a Fedora 12 system to the Fedora 13 system:
> >>> Authentication refused: bad ownership or modes for file /home/dhighley/.ss
h/authorized_keys
> >>>
> >>> We have checked and tried different modes until we are blue in the face.
> >>> Have read the upates notes for openssh and Fedora 13 release. Googled
> >>> the net for know issues and bugzilla.redhat.com. We did check for
> >>> selinux blocks and found none.
> >>>
> >>> >>> Fedora 12 to Fedora 12.
> >>>
> >>>        
> >> Hi David,
> >>
> >> I use this feature of ssh a lot.
> >>
> >> i like to debug as, ...
> >>
> >> ssh user@host date
> >>
> >> so it fails...  now try,
> >>
> >> ssh -v -v -v user@host date
> >>
> >> what does this tell you?
> >>      
> > Nice
> >

> i am going to assume for the moment you have created new key files and 
> loaded them to the
> authorized_keys file.

Why would I need to create new key files? We save the /etc/ssh directory
and restore keys. Besides, we are not talking about the host keys, were
talking about the user's keys.

> 
> so, this is going to sound bizarre, but try it...
> 
> lets talk client and server to identify the 2 hosts in your issue.
> 
> on each host, in the home directory,

This is old school server set up where there is only one home directory
in the network for a user. That home directory is share from an NFS
server to all other systems via auto mounter and NIS.

The keys work except for ssh Fedora 12 -> Fedora 13. If you ssh
Fedora 13 -> Fedora 12 or ssh Fedora 12 -> Fedora 12 they work. If you
provide a password when sshing Fedora 13 -> Fedora 12 it works. Just
need to solve the issue of needing to provide a password.

> 
> $ mv .ssh .ssh_save
> 
> log out of each of cleint & server
> 
> log into client
> 
> try access the server via ssh cmd (ok if it fails), logout again.
> 
> login and on each of client & server,
> 
> $ mv .ssh_save .ssh    (make sure the perms stayed as 700)
> 
> now try your
> 
> $ ssh user@host date
> 
> again, any luck?
Date: Wed, 14 Jul 2010 06:57:52 -0700 (PDT)

"Rick Sewill wrote:"
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
> > 
> > The keys work except for ssh Fedora 12 -> Fedora 13. If you ssh
> > Fedora 13 -> Fedora 12 or ssh Fedora 12 -> Fedora 12 they work. If you
> > provide a password when sshing Fedora 13 -> Fedora 12 it works. Just
> > need to solve the issue of needing to provide a password.
> > 
> 
> I assume ssh Fedora 13 -> Fedora 13 works.

We only have one system running Fedora 13 so I'm not able to do this
test.

> 
> Could you compare the /etc/ssh/sshd_config file on Fedora 12 with the
> /etc/ssh/sshd_config file in Fedora 13?  Just guessing, but perhaps
> there is some option in the Fedora 13 sshd_config that needs tweaking.

Did this and only found comment differences.

> 
> I looked at http://www.openssh.org/faq.html
> The faq said,
> "3.14 - I copied my public key to authorized_keys but public-key
> authentication still doesn't work.
> 
> Typically this is caused by the file permissions on $HOME, $HOME/.ssh or
> $HOME/.ssh/authorized_keys being more permissive than sshd allows by
> default.

Yes, that would be an issue if we had done any copying, need to preserve
permissions and selinux acls.

> 
> In this case, it can be solved by executing the following on the server.
> 
>     $ chmod go-w $HOME $HOME/.ssh
>     $ chmod 600 $HOME/.ssh/authorized_keys $ chown `whoami`
> $HOME/.ssh/authorized_keys

Tried all of this before posting this query and still did not work.

> 
> If this is not possible for some reason, an alternative is to set
> StrictModes no in sshd_config, however this is not recommended."
> 
> I am wondering what happens if you put "StrictModes no" in the
> Fedora 13 /etc/ssh/sshd_config file.  This would only be for a test.
> They specifically said they do not recommend doing this so I wouldn't
> leave this option set this way, but I'm curious what happens.

Ran this test and it works.

> 
> Clarification please: is it true public key authentication doesn't work,
> Fedora 12 -> Fedora 13?  Does password authentication work,
> Fedora 12 -> Fedora 13?

Yes, public key fails and password works. This is looking like the issue
described in this bug report:
https://bugzilla.redhat.com/show_bug.cgi?id=481233

The difference being Samba is not involved.
Comment 1 David Highley 2010-07-15 09:10:53 EDT
Created attachment 432080 [details]
ssh -v -v -v output
Comment 2 Tomas Mraz 2010-07-15 09:19:43 EDT
More interesting would be output from a 'sshd -d -d -d' debugging session. This looks like some SELinux denial on the server.
Comment 3 David Highley 2010-07-15 11:10:09 EDT
Created attachment 432107 [details]
sshd -d -d -d output
Comment 4 Miroslav Grepl 2010-07-19 08:03:06 EDT
How is 'authorized_keys' labeled?

ls -Z /home/dhighley/.ssh/authorized_keys
Comment 5 David Highley 2010-07-19 10:43:50 EDT
[dhighley@douglas ~]$ ls -Z .ssh/authorized_keys
-rw-------. dhighley staff unconfined_u:object_r:home_ssh_t:s0 .ssh/authorized_keys
Comment 6 David Highley 2010-07-20 22:42:06 EDT
I now believe this issue was caused by selinux. I worked half a day on a new rpm package that I knew should be generating avc log entries but none were logged. Nothing showed up in any system log file. So I rebooted the system and email started working again, avc were logged for the package I'm working on and now public keys work ssh logins. Getting to be like Windoozee where reboot is the cure for all issues.:-(