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



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



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