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



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



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 / webmaster@blu.org