Quick SSH Note

Well, quick here; the actual note is very long:

Long story short, we have right now a flyctl ssh shell personal hostname.internal command (where “personal” is whatever your org slug is). It works without needing WireGuard installed (it will create a new WireGuard connection and cache it in your config).

We’re not done sanding the edges down, but the code is in Github:

(You should just be able to run “make”).

The plan is to do a bunch more stuff like this; Postgres is the next candidate, but even just simple stuff like being able to resolve DNS without having to explicitly bring up your WireGuard connection. Ideas welcome!

Hey @thomas, this feature looks awesome!

I’ve tried to build your branch, however it looks like there is a missing function causing the build to fail:

➜  git git clone https://github.com/superfly/flyctl.git
Cloning into 'flyctl'...
remote: Enumerating objects: 207, done.
remote: Counting objects: 100% (207/207), done.
remote: Compressing objects: 100% (146/146), done.
remote: Total 5212 (delta 94), reused 151 (delta 55), pack-reused 5005
Receiving objects: 100% (5212/5212), 1.28 MiB | 2.30 MiB/s, done.
Resolving deltas: 100% (3408/3408), done.
➜  git go version
go version go1.16 darwin/amd64
➜  git cd flyctl
➜  flyctl git:(master) git checkout tqbf-ben-netstack
Branch 'tqbf-ben-netstack' set up to track remote branch 'tqbf-ben-netstack' from 'origin'.
Switched to a new branch 'tqbf-ben-netstack'
➜  flyctl git:(tqbf-ben-netstack) make
Running Generate for Help
go generate ./...
generating cli help
Running Build
go build -o bin/flyctl .
# github.com/superfly/flyctl/cmd
cmd/ssh.go:72:22: undefined: runSSHShell
make: *** [build] Error 2
➜  flyctl git:(tqbf-ben-netstack) ✗

Please let me know if this is a genuine bug or if I’ve done something silly!

I’m able to build it but the fly ssh shell command doesn’t show up or seem to work

See this commit, and, particularly, the commit log message. Sorry, it’s been A Week.

1 Like

Also can I say here that I hate this command line, and am open to any alternatives.

Since we’re creating new WireGuard connections on the fly, I’m a little nervous about defaulting to any one organization.

Kurt likes flyctl console which is maybe where we’ll end up, though it doesn’t get us around having to pick or pass in an org slug every time you shell into something.

Maybe I’m missing something, I’d think fly ssh shell in a folder with a fly.toml would auto connect, seems reasonable to me? Or can apps be in multiple orgs? If so couldn’t it just detect if only one org and use it if it’s the only one? Not sure I have context.

1 Like

Ok see, here is why I am working on just asking this message board when I’m wondering about dev UX, because, yes, obviously, I should just auto-detect the org.

(The weird thing about me is, because I hack a bit on flyctl and because I use it to debug a bunch of different apps, I’m often running it out of ~/codebase/flyctl or ~.)

1 Like

I just merged a second cut of this feature into main on flyctl. The old, bad way still works.

The new way is:

flyctl ssh console should just work; it picks up the app from your local directory context (you can -a in an app like with other commands).

flyctl ssh console nrt.my-app.internal will connect to a specific instance (in this case, your NRT instance). (Technically, you can connect to any host in your organization this way, regardless of app).

flyctl ssh console -s will pop up a selector of available instances in all regions.

Still to come: some notion of flyctl ssh exec hostname to run individual commands.

When I run flyctl ssh console, I keep getting the prompt “Region in which to add WireGuard peer”. I don’t know what to enter, and whatever I try, I get this error:

Error create wireguard config: add peer failed: no gateways selected region

I tried doing flyctl ssh establish and flyctl ssh issue, but that didn’t change anything for this gateway error.

This is a brand new app. Do I need to do some kind of Wireguard setup first?

Short answer: run flyctl platform regions and pick the region code closest to you that has a gateway checkmark.

Long answer: we are magically setting up Wireguard for you when you run flyctl ssh console. This is a sharp edge in our UX right now, we should just guess and pick the region that’s best for you.

Does that make sense?

We hates this region selection stuff — especially because not every region has a WireGuard gateway. There’s a PR on flyctl right now that automatically selects regions, so you don’t have to think about them anymore. If I didn’t screw it up too badly, that should be how flyctl works for everyone early this week.

Why is that?

No super important reason. They all will eventually, I think.

When I run in my particular case:

flyctl ssh console huerta-db.internal

I obtain:

Connecting to huerta-db.internal...⢿ Error connect to SSH server: dial: lookup huerta-db.internal. on fdaa:0:e71::3: read udp [fdaa:0:e71:a7b:ce2:0:a:100]:62123: i/o timeout

I execute the command in the directory where the fly.toml exists.