Boston Linux & UNIX was originally founded in 1994 as part of The Boston Computer Society. We meet on the third Wednesday of each month, online, via Jitsi Meet.

BLU Discuss list archive


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

[Discuss] ssh with rsa keys and ldap



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)
>> >
>> > This only showed the password login.
>> > ssh -vvv:
>> > debug3: authmethod_lookup publickey
>> > debug3: remaining preferred: keyboard-interactive,password
>> > debug3: authmethod_is_enabled publickey
>> > debug1: Next authentication method: publickey
>> > debug1: Offering RSA public key: /home/sshuser/.ssh/id_rsa
>> > debug3: send_pubkey_test
>> > debug3: send packet: type 50
>> > debug2: we sent a publickey packet, wait for reply
>> > debug3: receive packet: type 51
>> > debug1: Authentications that can continue:
>> > publickey,gssapi-keyex,gssapi-with-mic,password
>> > debug1: Trying private key: /home/sshuser/.ssh/id_dsa
>> > debug3: no such identity: /home/sshuser/.ssh/id_dsa: No such file or
>> > directory
>> > debug1: Trying private key: /home/sshuser/.ssh/id_ecdsa
>> > debug3: no such identity: /home/sshuser/.ssh/id_ecdsa: No such file or
>> > directory
>> > debug1: Trying private key: /home/sshuser/.ssh/id_ed25519
>> > debug3: no such identity: /home/sshuser/.ssh/id_ed25519: No such file or
>> > directory
>> > debug2: we did not send a packet, disable method
>> > debug3: authmethod_lookup password
>> > debug3: remaining preferred: ,password
>> > debug3: authmethod_is_enabled password
>> > debug1: Next authentication method: password
>> > sshuser at target.usersys.redhat.com's password:
>> > debug3: send packet: type 50
>> > debug2: we sent a password packet, wait for reply
>> > debug3: receive packet: type 52
>> > debug1: Authentication succeeded (password).
>> > ----
>> > here is the same except using a non-ldap user:
>> > debug2: we did not send a packet, disable method
>> > debug3: authmethod_lookup publickey
>> > debug3: remaining preferred: keyboard-interactive,password
>> > debug3: authmethod_is_enabled publickey
>> > debug1: Next authentication method: publickey
>> > debug1: Offering RSA public key: /home/sshuser/.ssh/id_rsa
>> > debug3: send_pubkey_test
>> > debug3: send packet: type 50
>> > debug2: we sent a publickey packet, wait for reply
>> > debug3: receive packet: type 60
>> > debug1: Server accepts key: pkalg ssh-rsa blen 279
>> > debug2: input_userauth_pk_ok: fp
>> > SHA256:4SkkYr1TZa/ke4ALxYQMlpKshIAsoCAfr7XukU7/MF8
>> > debug3: sign_and_send_pubkey: RSA
>> > SHA256:4SkkYr1TZa/ke4ALxYQMlpKshIAsoCAfr7XukU7/MF8
>> > debug3: send packet: type 50
>> > debug3: receive packet: type 52
>> > debug1: Authentication succeeded (publickey).
>> > Authenticated to target.usersys.redhat.com ([10.19.40.121]:22).
>> >
>> >
>> >
>> > On 10/25/2016 07:47 PM, Guy Gold wrote:
>> >
>> > Any interesting details when using:
>> >
>> > "ssh -vvv" on the client
>> >
>> > while tailing /var/log/auth.log (or /var/log/secure) on the ssh target ?
>> >
>> > On 25 October 2016 at 14:13, Jerry Feldman <gaf.linux at gmail.com> wrote:
>> >
>> >
>> > I have a situation using rsa keys from an ldap user id.
>> > I have checked the permissions of my home directories, ~/.ssh, as well
>> as
>> > ~/.ssh/authorized_keys.
>> > For instance,, I am logged into my laptop and ssh into the workstation
>> at
>> > my desk, and it always prompts me for my password.
>> >
>> > On the same systems, I can ssh into an alternate user (ssh -l alt-user)
>> > using the same rsa keys.
>> >
>> > Also note that I can ssh into the BLU servers as my ldap user, but the
>> BLU
>> > servers use a local user name, So, there is some system setting on the
>> > target machine (not SELINUX) that I am missing.
>> >
>> >
>> >
>> >
>> > --
>> > --
>> > 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
>> > _______________________________________________
>> > Discuss mailing list
>> > Discuss at blu.org
>> > http://lists.blu.org/mailman/listinfo/discuss
>> >
>>
>>
>>
>> --
>> Guy Gold
>> _______________________________________________
>> 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
>



-- 
--
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