Thanks Chuck. It actually does not matter in this case. The workstation is in a lab and not widely available outside. However, restorecon may be a better way. I'll try that on another server.
On Wed, Oct 26, 2016 at 4:31 PM, Chuck Anderson <c...@wpi.edu> wrote: > Most likely all you had to do was fix the labels (or in some cases > enable a boolean). I say this because SELinux policy should already > exist to allow /usr/sbin/sshd to access authorized_keys--that is a > very basic function of a common system daemon that existing policy > should cover, not some obscure daemon or use case. > > restorecon -R /home/auser > > By changing the policy (loading a new policy module created with > audit2allow) you may be inadvertently making your system less secure > by allowing a broad range of access, rather than just fixing the > labels (or turning on a boolean) to match what the existing policy > already allows. It is always a good idea to LOOK at what you are > piping into audit2allow before just blindly allowing it. Please post > the sshd lines from audit.log and we may be able to help with that. > > On Wed, Oct 26, 2016 at 03:59:34PM -0400, Jerry Feldman wrote: > > Not wanting to make Dan Walsh weep all over > > me(https://stopdisablingselinux.com/), or worse hit me over the head > > with my own mallet, I re-enabled selinux and issue this command (as > > root): > > > > grep sshd /var/log/audit/audit.log | audit2allow -M mypol > > > > And verified it works. > > > > On 10/26/2016 03:07 PM, Jerry Feldman wrote: > > >Found the culprit!!! Journalctl is your friend. > > >Oct 26 14:56:18 target.usersys.redhat.com python[31245]: SELinux is > > >preventing /usr/sbin/sshd from open access on the file > > >/home/auser/.ssh/authorized_keys. > > > If you > believe > > >that sshd should be allowed open access on the authorized_keys file by > > >default. > > > # grep > sshd > > >/var/log/audit/audit.log | audit2allow -M mypol > > >I temporarily disabled selinux to test this. > > > > > >On Wed, Oct 26, 2016 at 1:40 PM, Jerry Feldman <gaf.li...@gmail.com> > wrote: > > > > > >>It's wierd. I can ssh to the workstation as a non-ldap user > > >>ssh -l <nonldap> > > >>And it authenticates properly. But if I ssh to another host at work > where > > >>I have the keys set up. it always goes to password. > > >> > > >> > > >>On Wed, Oct 26, 2016 at 12:14 PM, Guy Gold <guy1g...@gmail.com> wrote: > > >> > > >>>Jerry, > > >>> > > >>>Interesting. > > >>>Would you say it's safe to assume the culprit is the client rather > than > > >>>the > > >>>ssh server (target) ? > > >>> > > >>>It's as if "something" (ldap?) is throwing the auth process to believe > > >>>"you" does not exist, even when the files are there. > > >>> > > >>>On 26 October 2016 at 08:42, Jerry Feldman <gaf.li...@gmail.com> > wrote: > > >>> > > >>>>Unfortunately nothing very interesting. > > >>>>/var/log/secure on target: > > >>>>Oct 26 08:30:45 jfeldmanws sudo: xxxx : TTY=pts/0 ; PWD=/home/xxxx > ; > > >>>>USER=root ; COMMAND=/bin/tail -f /var/log/secure > > >>>>Oct 26 08:31:15 jtarget sshd[16073]: Accepted password for yyyy from > > >>>>10.18.41.22 port 57384 ssh2 > > >>>>Oct 26 08:31:15 target sshd[16073]: pam_unix(sshd:session): session > > >>>opened > > >>>>for user yyyy by (uid=0) > _______________________________________________ > Discuss mailing list > Discuss@blu.org > http://lists.blu.org/mailman/listinfo/discuss > -- -- Jerry Feldman <gaf.li...@gmail.com> Boston Linux and Unix PGP key id: B7F14F2F Key fingerprint: D937 A424 4836 E052 2E1B 8DC6 24D7 000F B7F1 4F2F _______________________________________________ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
