Author Archives: rodney

SSH Public Keys using LDAP on Amazon EC2

You need to centralized login for your users? And you are managing 1000+ Amazon EC2 instances or servers?
Pros:
You can use multiple public key to be used for your instances.
Define multiple users for admin and their public keys.

Cons:
You need to patch the SSH installed on your AMI to use the setup.
If LDAP server is down, it falls back to default SSH configuration.(not sure if this is CONS).

Using Ubuntu Karmic and OpenSSH Versioin: 5.1p1 you can patch the SSH to validate public keys from LDAP server. LDAP server setup and configuration is beyond the scope of this article. Here’s how to do it on your running Ubuntu Karmic EC2 instance:

$ sudo wget http://archive.ubuntu.com/ubuntu/pool/o/openssh/openssh_5.1p1.orig.tar.gz
$ sudo svn checkout http://openssh-lpk.googlecode.com/svn/trunk/ openssh-lpk-read-only  

$ cd openssh-5.1p1/
$ sudo patch < ../openssh-lpk-read-only/patch/contrib/contrib-openssh-lpk-5.1p1-0.3.10.patch
$ sudo patch < ../openssh-lpk-read-only/patch/contrib/contrib-openssh-5.1_p1-lpk-64bit.patch

$ sudo apt-get install build-essential libpam0g-dev 
$ ./configure --with-ldap --sysconfdir=/etc/ssh --prefix=/usr --with-pam 

$ sudo make 
$ su make install 

Add ldap schema as describe in this post: SSH Public Keys from LDAP

Configure LDAP Client, by entering the LDAP info upon installation of these packages:

$ sudo apt-get install libnss-ldap libpam-ldap nscd 

Another good reference for this is LDAP NSS and here Ubuntu LDAPClientAuthentication
Now on your LDAP server define the users and group:

dn: uid=foo,ou=users,dc=example,dc=com
objectclass: top
objectclass: person
objectclass: organizationalPerson
objectclass: posixAccount
objectclass: ldapPublicKey
description: John Doe Account
userPassword: {crypt}0LXhFAsrBWEEQ
cn: John Doe
sn: John Doe
uid: foo
uidNumber: 1034
gidNumber: 1002
homeDirectory: /home/foo
sshPublicKey: ssh-dss AAAAB3...
sshPublicKey: ssh-dss AAAAM5...
dn: cn=unix,ou=groups,dc=example,dc=com
objectclass: top
objectclass: posixGroup
description: Unix group
cn: unix
gidNumber: 1002
memberUid: foo
memberUid: bar

Now configure your /etc/ssh/sshd_config as describe on this doc: OpenSSH-LPK Wiki

UseLPK yes
LpkServers         ldap://10.1.7.1 ldap://10.1.7.2
LpkUserDN          ou=users,dc=example,dc=com
LpkGroupDN         ou=groups,dc=example,dc=com
LpkBindDN          cn=Manager,dc=example,dc=com
LpkBindPw          somepasswordifneeded
LpkServerGroup     somegroupname
#LpkForceTLS        yes
LpkSearchTimelimit 3
LpkBindTimelimit   3

I’m not using TLS here so I comment out that entry. You have to replace the values with your LDAP informations.
Restart SSH daemon:

$ sudo /etc/init.d/ssh restart

You should be able to login with the public key from LDAP. If not check your LDAP configurations.

After you can login successfuly, you might also use the pam_mkhomedir to create home directory for the users.
Edit the /etc/pam.d/common-session and add the following:

session required        pam_unix.so
session required        pam_mkhomedir.so skel=/etc/skel/
session optional        pam_ldap.so

Assuming you have the keypair and uploaded the publick key to LDAP server, you can now execute:

$ ssh foo@<your-ec2-instance> 

Your done!

Five Easy Steps to Tag EC2 Instance Using mr.awsome

Are you running 10,30 or 100 instances in your single EC2 Account? How do you identify each one?

There have been lot of questions on how to tag and manage a bunch of EC2 instances. To tell you I’ve been into your situation, after working with several EC2 clients. What a pain to keep track which instance is which.

Existing posts about How-are-admins-managing-their-ec2-ebss-and-snapshots and answers like Tagging-ec2-instances-using-security.

But in some cases, placing a set of instances into a set of groups, would possibly create or block access to the other instances using the same group when trying to change a security settings.

Matt Juszczak describe an example of this problem in his blog here.

Proposed Solution: Set a unique security group for an instance.

PROS:
1. It solves the tagging of each instance
2. Eliminates the possible problem describe above since the current instance is only affected when you try to change it’s security settings.

CONS:
1. Unfortunately, you have to define individual group for each of the instance and that is extra work.
2. Existing instances (especially production instances) cannot make use of this solution unless by launching the production image and remapping Elastic IP.

Continue reading