SSH connection to an instance

1

Is there a tutorial (step by step) on how to configure an ssh connection to an instance in fly.io?

I want to create an instance and run commands to finish configuring it, because it is difficult for me to automate everything from the Dockerfile.

Thanks!!

2 Likes
2

First: finishing up config with SSH may not work as well as you want. If the VM ever crashes or is rescheduled, it will come up from the Dockerfile. We’re happy to help configure from the Dockerfile though if you’re stuck, we have more experience than we’d like doing that. :smiley:

Second: SSH is more complicated than we’d like. You will need to:

  1. Connect to your private network with wireguard:
    1. flyctl wireguard create
    2. Setup wireguard to use the generated config
  2. Get an SSH certificate
    1. flyctl ssh establish (this configures the root organization cert, you only need to run it once)
    2. flyctl ssh issue --agent
  3. Get private IP of VM: flyctl ips private
  4. SSH to it: ssh root@<private-ip>

This assumes you’re running an ssh agent, if you’re not, you can run flyctl ssh issue without that arg and follow some extra steps.

We are shipping a one command way to connect to running VMs real-soon-now.

3 Likes
3

Thanks!

I will try to run the commands from a .sh file.

It is correct the next command If I want to find the others instances off the app:

otros=$( (dig aaaa global.$FLY_APP_NAME.internal @fdaa::3 +short | grep -v "$ips") || echo "")

Where ips is the IP of the instance obtained by ips=$(grep fly-local-6pn /etc/hosts | awk '{print $1}')

It is possible that, when I do a new deploy, I get an instance that does not correspond in the variable otros.

In the last deploy I have:

IP: fdaa:0:e71:a7b:69:9d57:3bca:2
Others IPs: fdaa:0:e71:a7b:6b:a840:ff61:2

4

Yes, that’s a good command for finding IPs (you don’t have to use global, though, $FLY_APP_NAME.internal is enough.

It is possible to get an IP that’s not yet in DNS. There will be a small delay between when your VM is running and the DNS server knows about it.

And, when you’re doing deploys, you’ll actually get the new instance before the old one is torn down. So it’s possible the other IPs you got were actually old VMs that hadn’t shut down yet.

Does that make sense?

5

Its ok, in that case, after the deploy, it is convenient to do a restart? flyctl restart...

1 Like