fly ssh console times out

Questions / Help
1

I think I’ve done everything I was able to find in the support and documents but I’m just not able to ssh into my server. I get this error: Error: error connecting to SSH server: dial: connect tcp [xxxx:xx:xxx:xxx:xxx:xx:xx:2]:22: operation timed out
Stacktrace:
goroutine 1 [running]:
runtime/debug.Stack()
/home/runner/go/pkg/mod/golang.org/toolchain@v0.0.1-go1.24.1.linux-amd64/src/runtime/debug/stack.go:26 +0x5e
github.com/superfly/flyctl/internal/cli.printError(0xc000308b40, 0xc0009c7c15, 0xc0004d6f08, {0x3059fe0, 0xc000776468})
/home/runner/work/flyctl/flyctl/internal/cli/cli.go:185 +0x59e
github.com/superfly/flyctl/internal/cli.Run({0x307ff10?, 0xc00013f0c0?}, 0xc000308b40, {0xc00006c090, 0x4, 0x7})
/home/runner/work/flyctl/flyctl/internal/cli/cli.go:118 +0xb05
main.run()
/home/runner/work/flyctl/flyctl/main.go:47 +0x150
main.main()
/home/runner/work/flyctl/flyctl/main.go:26 +0x18

Any advice would be greatly appreciated

2

What command exactly are you using to SSH in? Where are you running the command from?

3

Not OP, but I’m also seeing an issue that smells the same.

I’m running fly ssh console (or with --machine xxxxxx — it’s the same result because I just have the one machine). It looks like this for a while: (the dots spin)

Connecting to fdaa:0:4699:a7b:xxx:xxxx:xxxx:x...⡿

Then a minute or so later it times out like this:

Connecting to fdaa:0:4699:a7b:xxx:xxxx:xxxx:x... complete
Error: error connecting to SSH server: dial: connect tcp [fdaa:0:4699:a7b:xxx:xxxx:xxxx:x]:22: operation timed out

It also happens when I use fly console --machine xxxxx (which might be the same thing under the hood? ¯\(ツ)/¯)

I’ve verified on https://fly.io/apps/xxxxx/machines/yyyyyyy that the IPv6 is the one I’m expecting for the machine. The machine and app are otherwise behaving as I’d expect them to.

I’ve tried running this from two computers: my Mac laptop and a Linux VM. The two are on the same home network, but are otherwise independent. Neither has another VPN or any other networking funny business that I’m aware of

I’m deploying an image based on oven/bun:1, which is… Debian? I haven’t to my knowledge done anything SSH-related to the image, and I hope I didn’t need to

I’m blocked because I’d like to upload an “initial” sqlite database to a persistent disk on this machine, and I don’t know how else to do this besides fly ssh console

1 Like
4

You can also do a machine create with a files JSON parameter, see here. You have to base64-encode the file, so it is a bit fiddly, but that might get you going again.

Edit: not sure if this works with mounts though, but you can give it a try. It may only work with the disk that is available before additional storage is mounted.

5

I wonder if the SSH issue is region-dependent. My London-region Alpine-backed machine works fine for flyctl ssh console, but it’s existed for a while, and I wonder if newer machines might have a problem that older ones do not.

6

I’m actually unable to use fly ssh console on any of my apps. I’ve tried several of various ages (including some that were last deployed many moons ago), and of several different base images.

I’ve also tried from both my home network as well as tethering to a cell network.

Is there something I need to explicitly set up in order to get fly ssh console to work? Perhaps I missed some memo

7

No, it should work already… Can you fly ping the Machine successfully?

8

Nope! I see:

$ fly ping
35 bytes from fdaa:0:4699::3 (gateway), seq=0 time=13.4ms
35 bytes from fdaa:0:4699::3 (gateway), seq=1 time=18.9ms
35 bytes from fdaa:0:4699::3 (gateway), seq=2 time=29.1ms
35 bytes from fdaa:0:4699::3 (gateway), seq=3 time=15.3ms
35 bytes from fdaa:0:4699::3 (gateway), seq=4 time=20.9ms
...
$ fly ping myapp.internal
<nothing, eventually I C-c>
$ fly ping fdaa:0:4699:a7b:xxx:xxxx:xxxx:x
<nothing, eventually I C-c>

So strange!

1 Like
9

For completeness, I’ve also tried fly doctor (all PASSED) and scaling to 0 and 1 again (I verified that it’s a different machine with a different IP, but it still doesn’t work)

10

That was good thinking…

It may be the gateway itself that’s at fault. You said above that the Machine was behaving normally, otherwise, which strongly suggests that Fly Proxy, et al. can still reach it.

I would try the following, just as an initial stab:

$ fly agent stop
$ fly wg remove <org-name>  # repeat as necessary.  (there can be a lot!)

(And then re-do the ping attempts.)

If I remember correctly, there’s a local environment variable that you can set to request a gateway in a completely different region, but I would have to look that one up…

11

Oh! That seems to have done it: I used fly wireguard to make a connection to sea instead of sjc, and now ping and ssh work?!

So strange. No idea what’s up with sjc…

1 Like
12

Hi folks - sorry for the trouble. There was a bug with our WireGuard peer creation logic, and we’ve just pushed out a fix for it. Please let us know if you’re continuing to see issues here!

3 Likes
13

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.