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

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&#39;s password: debug1: Authentications that can continue: publickey,password Permission denied, please try again. admin(a)127.0.0.1&#39;s password: On Wed, Aug 12, 2015 at 7:56 PM, Mauricio Tavares <raubvogel(a)gmail.com&gt; wrote: > > On Wed, Aug 12, 2015 at 10:37 AM, Aneela Saleem <aneela(a)platalytics.com&gt; > 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&gt; > > 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. > >> > >