[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Experiences with AWS's EC2 Instance Connect and Debian?

Thanks for the info, Thomas. I've not used ec2-instance-connect yet, so I wouldn't push for it to be included - was just curious as to if it was any good in day-to-day operations. Currently I have a wrapper script that identifies a server by the tags you supply, picks a matching one at random, and ssh's you to that - no need to identify a specific instance :)
I'm actually at a bit of a waypoint at the moment, trying to figure out what to do with users - I have both technical and non-technical users that need both IAM users and LDAP users, and technical users that need ssh. The AWS answer to combining IAM and LDAP is to run an AWS Directory Service server, which is Active Directory running on a dedicated machine beefy enough to run windows. Seems like overkill. Fixing all this is sort of a backburner project for me, but I haven't been lucky in finding a good solution for it.
As for Ansible and user/ssh management, I've seen and tried several ways over the years, and none of them seem particularly clean. What we've got at the moment works, but it's just a different user list to the IAM and LDAP ones. 

Thanks again,

Paul


On 9/8/19 5:49 pm, Thomas Goirand wrote:

On 7/22/19 4:36 AM, paul wrote:

Hi all,

I'm looking for a better way to manage SSH users and saw EC2 Instance
Connect which is apparently the way the world is going, but it only
officially supports Amazon Linux and Ubuntu. My current method for
distributing users is baking them into the SOE and (piecemeal) updating
later with Ansible. It's a little mucky.

https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-connect-set-up.html


Are any listizens currently using EC2 Instance Connect with Debian? I'm
curious to know your thoughts. It looks a little needlessly complex but
it would mean managing users in IAM only instead of IAM + Ansible for me.

Cheers,

Paul Morahan



Hi Paul,

I have nothing against this, though we'd need ec2-instance-connect to be
in Debian. Currently, upstream packaging isn't optimal either (see for
example the weirdo Pre-Depends: adduser in it, Homepage: field being
defined in the wrong section, no build-depends, wrong postinst way to
manage the .service, wrong way to package the .service file, etc.). So
if we write a policy compliant package, get this in Debian, then why not
having ec2-instance-connect in the default Debian AWS image? This may
only happen when Bullseye gets released though, since that new package
wont be in Buster.

BTW, I hate the default Ansible ssh user handling, where you define
users that you want to add or remove, instead of a set of users that you
want to be authorized. This is in many ways backward. For this reason,
we're sticking to our puppet definition of authorized_keys, so we don't
have the risk to forget removing a user.

Cheers,

Thomas Goirand (zigo)
Reply to: