Boston Linux & UNIX was originally founded in 1994 as part of The Boston Computer Society. We meet on the third Wednesday of each month at the Massachusetts Institute of Technology, in Building E51.

BLU Discuss list archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Discuss] ssh with rsa keys and ldap

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(, 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 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> 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> 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> 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
> >>>> port 57384 ssh2
> >>>>Oct 26 08:31:15 target sshd[16073]: pam_unix(sshd:session): session
> >>>opened
> >>>>for user yyyy by (uid=0)

BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!

Boston Linux & Unix /