Provide IP address in virtual machine information

[eecsmap]

I have a use case where I need to allocate VM and provide a SSH config file with content such as:

Host macos-ventura-xcode14
  HostName 192.168.64.2
  User cm
  ForwardAgent yes
  TCPKeepAlive yes
  ServerAliveInterval 60
  ServerAliveCountMax 30
  ProxyJump orchard-worker5

So user can do ssh -F mysshconfig macos-ventura-xcode14 to access this machine directly.

To support this operation, I have the worker name in the /vms/{vm_name} response, except the IP address.

Can we have this IP address listed in the response too?

[edigaryev]

This was previously requested for VMs with --net-bridged: https://github.com/cirruslabs/orchard/issues/123.

Ideally, it would be nice to make the Orchard Controller listen as a SSH server and thus become the SSH's JumpHost target on its own.

This way the ssh(1) invocation would look like this:

ssh -J orchard-controller.example.com macos-ventura-xcode14

...and work for both the standard networking and --net-bridged. Not sure about the authentication, though, as orchard ssh vm, as there's both a service account token and VM's credentials at play.

As for directly exposing the IP in the API, we could either:

1. Update the VM's API resource only once at the beginning of its lifetime with its resolved IP
2. Or make a separate API endpoint that will resolve the current VM's IP through the internal gRPC connection between the Controller and the Worker each time this API endpoint is requested

Does (1) work for you, or do you need an always up-to-date IP of the VM?

/cc @fkorotkov

[eecsmap]

If possible, the best option will be using orchard-controller as the jump box. Since the controller is public available to clients anyway. Otherwise, (1) returns the VM IP and the hosting worker should be a acceptable solution for now. At least I could use these information to make up an SSH config, with the hope the VM is not going to be moved around workers and got different IPs. This solution assumes the public access of all workers though. (I need to change the firewall rules to expose them out). (2) probably is more reliable option, but could it coexist with (1)?

My workflow should be:

1. allocate the VM, get the meta from the response, including worker, and vm IP.
2. build the ssh config and provide to client.
3. free the VM after use.

BTW, right now I am using a heavy work around. I basically wrote a SSH forwarder / proxy as a dedicated server.

1. allocate VMs
2. provide the list of VM names to the forwarder, it will establish port-forwards to each VM's ssh, return a map of forwarder ports to VM's 22 ports.
3. build the ssh config using the forwarder ports for each VM.
4. free the forwarding ports from the forwarder.
5. free the VMs from the controller.

[eecsmap]

How likely we can have the orchard controller itself play the role of jumpbox?

Btw, I also send a commercial letter for further support :) Hope it reach you guys well.

[fkorotkov]

@eecsmap could you please indicate yourself on the email thread? We have a few going on :-)

[eecsmap]

@eecsmap could you please indicate yourself on the email thread? We have a few going on :-)

I got your reply already :)

Wenyang

[eecsmap]

Any good news from the jumpbox feature :)

[fkorotkov]

PoC seems to be working fine. We are slowly working on polishing edge cases and adding tests.

[eecsmap]

I also made a jumpbox implemented in python3. And I realize that when I do ssh -J jumpbox:443 vm_AbCd It will fail since ssh client send the ssh packet for TCP connection forward with lower case hostname.

channel_connect_stdio_fwd: vm_abcd:22

And then we use this vm_abcd to construct the websocket uri as

GET /v1/vms/vm_abcd/port-forward?port=22&wait=5 HTTP/1.1

And our API seems to be case sensitive, such websocket request therefore returns 404 not found.

I wonder how are you going to address this issue.

I am thinking about: 1) always create vm with lower case name. 2) or let orchard vm names be case insensitive?

Btw, Can I have an approximate date when your jumpbox will be available?

[fkorotkov]

Probably either next week or at most the week after.

[edigaryev]

It will fail since ssh client send the ssh packet for TCP connection forward with lower case hostname.

Good point.

We'll be begin deprecating the non-[a-z0-9-] VM names in https://github.com/cirruslabs/orchard/pull/179 and completely disable them in Orchard 1.0.0 so that the users will have some time to migrate.

Only allowing such names will avoid lowercase comparisons internally in Orchard, which could lead to subtle bugs (including security ones) and allow for DNS compatibility in the future.

[eecsmap]

Hi guys. This jumpbox works amazing now. However I currently run into a case where I still need the IP of the VM. I see you suggested above that:

1. Update the VM's API resource only once at the beginning of its lifetime with its resolved IP
2. Or make a separate API endpoint that will resolve the current VM's IP through the internal gRPC connection between the Controller and the Worker each time this API endpoint is requested

For our case, simply return in the /v1/vms/ the IP address should be fine. (and yes, we use it with --net-bridged as #123 ) The second option is nice to have but not in real need for now. I noticed in #123 @roblabla offered a patch, I think the option1 will the something similar right?