Error: cannot resolve remote host

[gonzolively]

Describe the bug
When creating a remote session (and selecting a remote host) the host does not change to the selected host. When I go back and try to edit the connection I get an error that reads:

`Error: cannot resolve remote 'ubuntu@127.0.0.1:22022': not found`

The only way I can successfully connect to the remote host is by issuing the cr command in the terminal: specifically cr vm as vm is my remote hostname.

To Reproduce
Steps to reproduce the behavior:

1. Click "+" to start a new tab
2. Select remote host from the dropdown menu (in my case, ubuntu@127.0.0.1:22022)
3. Discover/verify that you are NOT on the desired host. I confirmed by issuing echo $HOSTNAME and receiving the hostname of my local machine.
4. Try editing the connection by clicking the elipses and once again selecting the remote host.
5. DIscover the error , Error: cannot resolve remote 'ubuntu@127.0.0.1:22022': not found

To Resolve

1. Issue cr <connection_alias> command

Expected behavior
Upon starting a new tab and selecting the appropriate remote connection from the dropdown I expect to be connected to that host within a matter of seconds.

Screenshots

• Screen capture

Desktop (please complete the following information):

• OS: MacOS Sanoma 14.3.1 (23D60)
• Version: v0.6.1 (20240131-063625)

Additional context
The connection in the error exists in the connections tab and is a live and working connection. Not sure why it wouldn't find it.

[sawka]

I'm wondering if there is a problem resolving hosts with the port numbers (the ":"). We recently added the ability to have remotes with port numbers as part of their canonical name.

[oneirocosm]

I think you're right. A quick fix would be to strip the port number from the hostname before running the command. This isn't necessarily great, but it should make it usable while still allowing separate ports to be used. Longer term, I think we'll need more changes around this, but they are somewhat dependent on the other ssh work that's being done right now.

[oneirocosm]

I've looked into this more, and I think I was wrong with my initial assessment. Now that #300 has been created, I think this is more likely an issue with the way we resolve remotes. It's very possible that these functions did not expect a port number tacked onto the end of the canonical name. I'm going to investigate it more to see what a good fix would be.

[oneirocosm]

Fixed in v0.7.0