add replicated vm ssh-endpoint command to print the ssh endpoint of a vm

[hedge-sparrow]

This enables users to use tools other than ssh or to construct more complicates commands with the endpoint.

i.e:

ssh $(replicated vm ssh-endpoint abdc123) 

scp ./file $(replicated vm ssh-endpoint abdc123):/some/path/

tar -c /path | ssh $(replicated vm ssh-endpoint abdc123) tar -xv

[squizzi]

I think we should bring back the interactivity that was removed in #532, if I don't provide a VM ID I should still be able to select one from the list. I liked that addition. The difference being we'd just output the ssh URI from the selection rather than start a new SSH session.

[hedge-sparrow]

I think we should bring back the interactivity that was removed in #532, if I don't provide a VM ID I should still be able to select one from the list. I liked that addition. The difference being we'd just output the ssh URI from the selection rather than start a new SSH session.

The problem with having interactivity in something we expect to run in subshells is that it doesn't always work the way we expect, things run inside bash's $() or fish's () don't behave the same way as if run directly from a tty

[squizzi]

The problem with having interactivity in something we expect to run in subshells is that it doesn't always work the way we expect, things run inside bash's $() or fish's () don't behave the same way as if run directly from a tty

Maybe a happy middle ground would be to print a vm ls of running status VMs in the case where an ID is fudged or the command is attempted against an ID that is not yet running.

I dunno, I see a benefit to keeping vm ssh around if thats the case -- which I guess we could discuss in greater detail on that PR because I find it moderately annoying to do a r vm ls and then make sure the VM is running and then ssh $(replicated vm ssh-endpoint <id>)

I'm going to approve this and then we can discuss the potential of keeping vm ssh around for just the interactive ssh use case in the other PR.