On Wed, Aug 12, 2015 at 11:31 AM, Aneela Saleem aneela@platalytics.com wrote:
Yes ldap works. and running ssh in verbose mode gives i.e., ssh -v admin@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@openssh.com none debug1: kex: client->server aes128-ctr hmac-md5-etm@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@127.0.0.1's password: debug1: Authentications that can continue: publickey,password Permission denied, please try again. admin@127.0.0.1's password:
On Wed, Aug 12, 2015 at 7:56 PM, Mauricio Tavares raubvogel@gmail.com wrote:
On Wed, Aug 12, 2015 at 10:37 AM, Aneela Saleem aneela@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@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.
openldap-technical@openldap.org