[ Ø ] Harsh Prakash

Quiet Musings on Cloud, Machine Learning, Big Data, Health, Disaster, et al.

From SSH to SSM (a.k.a. the demise of bastion host)

without comments

To avoid having to manage very many SSH keys, sysadmins used ssh-user. AWS solves the headache with ssm-user. It is only for administering existing infrastructure. To provision new infrastructure, as should be end-goal in a Cloud shop anyway (think cattle, not pet – Shitty way to look at animals, but anyway…), you don’t need either SSM or SSH.

Traditionally, you find “what” someone does, like so –

$ sudo cat secure | tail -n 3
Aug 6 10:40:16 hostname sshd[12345]: pam_unix(sshd:session): session opened for user username by (uid=0)
Aug 6 10:40:40 hostname sudo: username : TTY=pts/3 ; PWD=/var/log ; USER=ssh-user 02 ; COMMAND=/usr/bin/bash
Aug 6 10:40:56 hsotname sudo: ssh-user : TTY=pts/3 ; PWD=/var/log ; USER=root ; COMMAND=/bin/cat secure

For tracking, the one change that can be implemented a-stat is to require all teams to start using TOKENs and not keys for GitHub check-ins so traceability of their provisioning code can be maintained.

With these, if teams need to login to existing sys, you can trace who all logged in, who all invoked ssh-user, and what ssh-userdid. So, you can narrow down a misstep to the group that last invoked ssh-user, but not to a specific individual. (Note, while SSM stills logs everyone in as ssm-user, it hyphenates sessions separately by user and can narrow it down to an individual).

Another workaround you can put in place is to manage keys via .ssh/config, at least in the interim. But eventually, you should move to SSM in an AWS shop.

And I’d rather have teams working in an IDE from their local laptops than in a text editor on a server instance (admit it, VI or EMACS isn’t everyone’s cup of tea). For that, since we’d need Linux running on Windows for Ansible etc., take your pick between WSL or VirtualBox. Either way should be a-okay – In the past, I used WSL for access (with temp keys via STS), and found a sub-system less bloated than a full-fledged sys box. And there was this sweet thing.

This is imp – Esp. as we treat infrastructure = code and engineers/sysadmins = developers/builders, we should allow engineers/sysadmins the same DevOps tools – an IDE to work in locally, etc. So that’d mean that each engineer/sysadmin forks her own repo and pushes changes out in true Git fashion (with retention/archiving handled by versioning).

With that, you pretty much kill the need for most intermediate server hosts.

- [ Ø ]

    Written by Harsh

    August 6th, 2019 at 3:30 pm

    Posted in Cloud

    Tagged with , ,

    Leave a Reply

    Time limit is exhausted. Please reload the CAPTCHA.