Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Emacs Tramp over AWS SSM APIs

martin.baillie.id

Post reply on HN
Print view View original

41–50 of 59 posts

Re: Emacs Tramp over AWS SSM APIs

#41

Post by skissane »

narrator wrote: post #38
tyingq wrote: post #14

"Perhaps more interesting, though, is that for the last couple of years AWS has supported tunneling the SSH protocol over their SSM APIs if you use the SSM “document” called AWS-StartSSHSession." That's interesting. I know some places go to great lengths to keep developers from accessing production without some sort of break-glass procedure through a jump host. I'm curious if they all know about this sort of loophole…

Accessing production on the command line is an anti-pattern. I can only think of one good reason to do it: If one is investigating a security incident where a hacker has broken into production and screwed around. Even then, one would want to snapshot the instance and take it offline to investigate it. If there's some tricky bug in production, then one can create some sort of debugging service that runs on another por…

> If there's some tricky bug in production, then one can create some sort of debugging service that runs on another port and deploy it to investigate the bug,

If you are under time pressure to fix an escalation from a high profile customer, and you don't have such a service yet, do you make the customer wait for you to write one, or do you just use command line access? Or else, if you already have such a service, but it doesn't contain the necessary diagnostics to investigate this particular problem, do you make the customer wait for you to enhance it, or do you just use command line access? Or you make your debug service totally generic – allow it to run arbitrary code supplied by the user – in which case it can do anything the command line can, but how is that actually any more secure than more standard means of command line access? Plus, it is going to be adding friction which may slow down resolution.

> or use management and monitoring tools.

Often these work fine for some problems, and then you get a problem which they don't cover adequately, and you need to go beyond them.

Re: Emacs Tramp over AWS SSM APIs

#42

Post by taeric »

mjw1007 wrote: post #18
xemdetia wrote: post #16

Earlier quoted context omitted.

I'm confused with claiming obscure emacs or vi commands for TRAMP, I'm from the emacs side and as soon as I understood the file path scheme (e.g.: /ssh:$host:/path/to/file) I didn't have to do anything beyond that. I would say that the dev client/server setup you're describing and what TRAMP provides are different things overall as well. TRAMP really just provides a way to get a file from a remote, edit it locally, a…

TRAMP is more than just opening and writing files: it runs VCS operations remotely, which is very helpful. https://emacs-lsp.github.io/lsp-mode/page/remote/ suggests that LSP under TRAMP is basically there, though I haven't had occasion to try it.

It can run everything remotely. If you are using eshell, you can

    cd /sshx:host:
    ls
    any remote command
It is quite impressive how well it works. Most lsp modes are tramp aware, such that completion and tag jumping will also do the right thing.

Re: Emacs Tramp over AWS SSM APIs

#43

Post by taeric »

ak217 wrote: post #17
dangom wrote: post #7

Earlier quoted context omitted.

I'd love to see a workflow comparison between emacs, vim (with remote work via neovim's tcp support + neovide) and vscode. I'm currently using Emacs and have a pretty decent setup for remote work with jupyter-emacs and tramp, and it's pretty much 0 overhead to run the same code on multiple remotes, or have the same remote run code stored in multiple places. With that said, all abstractions end if my SSH connection br…

I don't think the level of integration between tramp and other essential emacs plugins (flycheck, jedi, magit, etc.) is comparable to vscode. In vscode, entire plugins responsible for this stuff are sent over to run on the remote, leaving the local to run the UI - but also to keep all the settings and state. In emacs I have to either add pretty complicated scripts to my .emacs just to get stuff to play together if it…

I haven't found many (any?) modes that don't just transparently with with tramp. I'm curious on your experience.

Even python, if I M-x run-python while on a remote file, it runs python on that remote machine.

Re: Emacs Tramp over AWS SSM APIs

#44

Post by nijave »

gunapologist99 wrote: post #37

> For a good wee while now, AWS SSM (or AWS Systems Manager as I see they are calling it nowadays) has arguably been the most secure way to permit controlled and audited access to an EC2 instance. SSM is definitely not the most secure way[0]. SSM is super complex and super-integrated into the rest of AWS, and also isn't cross-cloud to GCP, Azure, DO, etc, so now everyone needs an account just to log into a Linux serv…

SSM supports BYO doesn't it? Can't you install the agent on any machine to enroll it in SSM or does that limit what you can do?

Re: Emacs Tramp over AWS SSM APIs

#45

Post by taeric »

squiddev wrote: post #13
taeric wrote: post #5

Earlier quoted context omitted.

How? Tramp has been working at this level for well over a decade, if I'm not mistaken. And you don't have to have anything installed in the "host" that you are connecting to.

If you're working on very slow network connections, or the network just dies entirely, it's not uncommon for Emacs just to hang entirely. You then have to kill Emacs from another terminal. At the time I was running exwm (an Emacs window manager), which made the whole thing even more painful. Emacs is powerful, but polish is not its strong point. That said, this was a few years ago now. Things may have improved in 26.…

I can concur that a slow connection is bad. It shouldn't hang entirely, as C-g should still get you response back. That said, it will hiccup bad and a save needs a round trip, regardless.

Re: Emacs Tramp over AWS SSM APIs

#46

Post by paulddraper »

narrator wrote: post #38
tyingq wrote: post #14

"Perhaps more interesting, though, is that for the last couple of years AWS has supported tunneling the SSH protocol over their SSM APIs if you use the SSM “document” called AWS-StartSSHSession." That's interesting. I know some places go to great lengths to keep developers from accessing production without some sort of break-glass procedure through a jump host. I'm curious if they all know about this sort of loophole…

Accessing production on the command line is an anti-pattern. I can only think of one good reason to do it: If one is investigating a security incident where a hacker has broken into production and screwed around. Even then, one would want to snapshot the instance and take it offline to investigate it. If there's some tricky bug in production, then one can create some sort of debugging service that runs on another por…

That's the way things should work and ought to be done.

But what about when things don't work like they should and ought to?

Want to debug network connectivity issues? See which process is hogging CPU? Investigate installation/delpoy problems? Reinvent the wheel, or use what's already there.

Re: Emacs Tramp over AWS SSM APIs

#47

Post by nijave »

narrator wrote: post #38
tyingq wrote: post #14

"Perhaps more interesting, though, is that for the last couple of years AWS has supported tunneling the SSH protocol over their SSM APIs if you use the SSM “document” called AWS-StartSSHSession." That's interesting. I know some places go to great lengths to keep developers from accessing production without some sort of break-glass procedure through a jump host. I'm curious if they all know about this sort of loophole…

Accessing production on the command line is an anti-pattern. I can only think of one good reason to do it: If one is investigating a security incident where a hacker has broken into production and screwed around. Even then, one would want to snapshot the instance and take it offline to investigate it. If there's some tricky bug in production, then one can create some sort of debugging service that runs on another por…

>Accessing production on the command line is an anti-pattern

Seems to be at odds with

>then one can create some sort of debugging service that runs on another port and deploy it to investigate the bug

In many cases, that's just SSH. In most cases, I'm not copying files around, I want to connect to the real environment where firewall rules, API keys, permission systems, overlay networks, etc are in place. If there's a stuck process (let's say, lock contention) it's much easier to just SSH on and run gdb and check the stack to see what it's doing. Some languages like Java have pretty rich tooling out of the box for remotely connecting to processes. Others, like Python and Ruby, you just use gdb

Either way, there's no copying data necessary--you just need access to the running process. For a large system with hundreds of identical servers, I don't want to deploy a debug service everywhere; I just want to connect to the one with an issue and check that.

Snapshotting works sometimes, but I used stuck processes as an example since that's usually where all this remote/log/etc stuff falls apart. And, as-it-so-happens, things like lock contention tend to be really hard to recreate in synthetic or simulated environments that don't have real, authentic load.

Keep in mind that doesn't mean "go crazy with `root` in production". You can combine that strategy with scripting and tooling to drain/isolate/quarantine servers where the stuck process is still running but they don't have live traffic being routed to them.

I see this "ZOMG NO ONE TOUCH PROD" mentality a lot in highly regulated environments but it's usually more sustainable to try to isolate in-scope system's functionality as narrowly as possible to avoid bringing unnecessarily large amounts of things in scope (e.g. put the billing functionality in a microservice to limit PCI scope)

Re: Emacs Tramp over AWS SSM APIs

#48

Post by tptacek »

thamer wrote: post #15

TIL: TRAMP (Transparent Remote Access, Multiple Protocols) is a package for editing remote files [...] Whereas the others use FTP to connect to the remote host and to transfer the files, TRAMP uses a remote shell connection (rlogin, telnet, ssh). https://www.emacswiki.org/emacs/TrampMode

Tramp is one of those "reasons to use Emacs in the first place" packages. I've been using Emacs since the 1990s, when someone impressed me with syntax highlighting in Lucid Emacs, and I only picked up Tramp last year. In the last 6-9 months or so, almost all of my development has been over Tramp.

What's particularly impressive about Tramp is that other Emacs packages tend to work well with it. For instance, you can Magit over Tramp --- or, better put: Magit just works in Tramp buffers. Same with language server stuff. It's kind of wild when you think about what's happening under the hood.

Re: Emacs Tramp over AWS SSM APIs

#49

Post by tptacek »

gunapologist99 wrote: post #37

> For a good wee while now, AWS SSM (or AWS Systems Manager as I see they are calling it nowadays) has arguably been the most secure way to permit controlled and audited access to an EC2 instance. SSM is definitely not the most secure way[0]. SSM is super complex and super-integrated into the rest of AWS, and also isn't cross-cloud to GCP, Azure, DO, etc, so now everyone needs an account just to log into a Linux serv…

What does being cross-cloud have to do with whether SSM is the most secure way to SSH into an AWS instance?

Re: Emacs Tramp over AWS SSM APIs

#50

Post by kstrauser »

Scarbutt wrote: post #40
kstrauser wrote: post #29

Earlier quoted context omitted.

Configuring OpenSSH's ControlMaster setting here makes an enormous difference. Summary: it keeps a connection open for a while in case you want to connect to the same machine again. If you do, it reuses that connection so the new one is nearly instant.

I'll give it a try, thanks.

Examples, starting with a new connection to a server I haven't accessed recently:

  ᐅ time ssh myserver exit
  
  Executed in    1.66 secs
Now visiting it again uses the existing connection:

  ᐅ time ssh mastodon exit
  
  Executed in   55.89 millis
Post reply on HN