On Wed, Aug 12, 2015 at 11:31 AM, Aneela Saleem <aneela(a)platalytics.com> wrote:
Yes ldap works. and running ssh in verbose mode gives i.e., ssh -v
admin(a)127.0.0.1
OpenSSH_6.6.1, OpenSSL 1.0.1f 6 Jan 2014
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to 127.0.0.1 [127.0.0.1] port 22.
debug1: Connection established.
debug1: permanently_set_uid: 0/0
debug1: identity file /root/.ssh/id_rsa type 1
debug1: identity file /root/.ssh/id_rsa-cert type -1
debug1: identity file /root/.ssh/id_dsa type 2
debug1: identity file /root/.ssh/id_dsa-cert type -1
debug1: identity file /root/.ssh/id_ecdsa type -1
debug1: identity file /root/.ssh/id_ecdsa-cert type -1
debug1: identity file /root/.ssh/id_ed25519 type -1
debug1: identity file /root/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.6.1p1 Ubuntu-2ubuntu2
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.6.1p1
Ubuntu-2ubuntu2
debug1: match: OpenSSH_6.6.1p1 Ubuntu-2ubuntu2 pat OpenSSH_6.6.1* compat
0x04000000
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5-etm(a)openssh.com none
debug1: kex: client->server aes128-ctr hmac-md5-etm(a)openssh.com none
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ECDSA
8e:24:39:c6:46:e1:03:31:b9:bb:7a:d4:89:16:72:6b
debug1: Host '127.0.0.1' is known and matches the ECDSA host key.
debug1: Found key in /root/.ssh/known_hosts:8
debug1: ssh_ecdsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
Poor ssh in the machine you are connecting to is completely
oblivious to ldap. As of now it only knows about publickey and
password. Try setting up sshd to use pam and then get ldap from there
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /root/.ssh/id_rsa
debug1: Authentications that can continue: publickey,password
debug1: Offering DSA public key: /root/.ssh/id_dsa
debug1: Authentications that can continue: publickey,password
debug1: Trying private key: /root/.ssh/id_ecdsa
debug1: Trying private key: /root/.ssh/id_ed25519
debug1: Next authentication method: password
admin(a)127.0.0.1's password:
debug1: Authentications that can continue: publickey,password
Permission denied, please try again.
admin(a)127.0.0.1's password:
On Wed, Aug 12, 2015 at 7:56 PM, Mauricio Tavares <raubvogel(a)gmail.com>
wrote:
>
> On Wed, Aug 12, 2015 at 10:37 AM, Aneela Saleem <aneela(a)platalytics.com>
> wrote:
> > Hi Aaron!
> >
> > Actually i'm trying to login LDAP users as local users from command
> > line.
> >
> > I have followed this guide but unable to perform 'ssh'
> >
> I think we need more than "unable to perform 'ssh'." Have
you
> done the usual stuff like ssh in verbose mode and check the logs? Have
> you checked that ldap works in said machine?
>
> > On Wed, Aug 12, 2015 at 7:23 PM, Aaron Richton
> > <richton(a)nbcs.rutgers.edu>
> > wrote:
> >>
> >> On Wed, 12 Aug 2015, Aneela Saleem wrote:
> >>
> >>> Hi all, Can anyone please tell me how can i pull users from LDAP
> >>> server
> >>> and treat them as local users? So that i can login as an ldap user and
> >>> test
> >>> whether particular user have permissions to particular HDFS commands
> >>> or not.
> >>
> >>
> >> I'm not sure what you're referring to by "pull." In a
typical *ix
> >> setup,
> >> you'd configure the system name services and/or authentication services
> >> to
> >> include an LDAP backend.
> >>
> >> The precise details and options depend on the exact flavor of the
> >> system
> >> you're using. nss_ldap, nss-pam-ldapd, and nssov are likely candidates
> >> on
> >> the name service side; nss-pam-ldapd also provides a pam_ldap on the
> >> authentication side. But again, this is somewhat system-dependent (no
> >> NSS on
> >> OS X/Darwin, for example).
> >>
> >> For nssov, see the LDAPCon paper
> >>
http://ldapcon.org/2011/downloads/cheng-paper.pdf for starters.
> >>
> >