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)
