[Discuss] ssh with rsa keys and ldap

[gaf.linux at gmail.com (Jerry Feldman)]

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 <cra at 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.linux at 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 <guy1gold at 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.linux at 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 at blu.org
> http://lists.blu.org/mailman/listinfo/discuss
>



-- 
--
Jerry Feldman <gaf.linux at gmail.com>
Boston Linux and Unix
PGP key id: B7F14F2F
Key fingerprint: D937 A424 4836 E052 2E1B  8DC6 24D7 000F B7F1 4F2F