Add `limactl ssh` as alias to `limactl shell`

[nirs]

Description

The common way to run commands and get a shell on a vm is ssh. Common tools provide ssh command to make this easier:

• minikube ssh
• virtctl ssh

But in lima this is called shell. Maybe it is more correct, since we can theoretically interact with the vm by other means, but practically this is always ssh.

I try to use limactl ssh by mistake many times.

This should be a trivial change in the Cobra command.

Downside: we will not be able to use ssh for another command in the future.

Discussed in #3608

[jandubois]

I disagree with this. The proper alias for shell should be sh (just like ls for list, rm for remove, cp for copy, etc).

Maybe it is more correct

Yes, because SSH is an implementation detail, and not a description of what the command does. There are a gazillion other aliases we could add, including:

telnet
terminal
term
execute
exec
run

If we say ssh is acceptable because it is the common implementation, should we add scp to copy? How about qemu to start? Where do we draw the line?

Maybe it is more correct, since we can theoretically interact with the vm by other means, but practically this is always ssh.

It is not theoretical. It is really driver-specific. If we were to support shell for the wsl2 driver, the implementation would be based on wsl -d $INSTANCE and not ssh.

The common way to run commands and get a shell on a vm is ssh. Common tools provide ssh command to make this easier:

• minikube ssh
• virtctl ssh

This is the most compelling argument to me, but you can make the same argument for aliasing ps to list because docker and nerdctl use it to list containers (only running ones, unless you specify --all, but that is a minor difference).

To me the same arguments that discourage us from aliasing scp to copy and ps to list apply to aliasing ssh to shell as well.

I'm fine with adding an sh alias, but that would be a separate issue.

[afbjorklund]

I think we had this discussion before, when comparing with docker-machine ssh and podman machine ssh

The real short command is lima, but then you need to juggle the LIMA_INSTANCE environment variable...

I think the outcome last time was that you should use ssh directly in that case, instead of shell (or show-ssh)

As in: ssh lima-default

[nirs]

I think we had this discussion before, when comparing with docker-machine ssh and podman machine ssh

Right, I forgot about podman machine, another example of a popular tool.

The real short command is lima, but then you need to juggle the LIMA_INSTANCE environment variable...

This is really not usable for use case of non-default machine.

I think the outcome last time was that you should use ssh directly in that case, instead of shell (or show-ssh)

As in: ssh lima-default

This is also not usable since you need the lima ssh config to use the right identity file and ssh options.

[jandubois]

As in: ssh lima-default

Do we document this anywhere? Afaik this only works if you add an Include to your ~/.ssh/config file:

Include /Users/jan/.lima/*/ssh.config

[jandubois]

This is also not usable since you need the lima ssh config to use the right identity file and ssh options.

"Not usable" is kind of strong; it takes a one-time setup (per user/host) to make it work (see above).

[nirs]

I disagree with this. The proper alias for shell should be sh (just like ls for list, rm for remove, cp for copy, etc).

Maybe it is more correct

Yes, because SSH is an implementation detail, and not a description of what the command does.

This is exactly the issue. Using the most correct term is not a goal. The goal is to make the tool easy to use. This usually means use the terms used by other applications to do the same thing.

But if we cannot agree on this then #3608 is an easy way to resolve this.

[nirs]

This is also not usable since you need the lima ssh config to use the right identity file and ssh options.

"Not usable" is kind of strong; it takes a one-time setup (per user/host) to make it work (see above).

I was not aware that we can include all configs like this, with this ssh is a good way. I need to test this.

Having to patch your local config is an issue for people using multiple machines since you have to remember to configure it. This is why I try to avoid such configurations.

[jandubois]

I was not aware that we can include all configs like this, with this ssh is a good way. I need to test this.

The advantage of using ssh directly is that you have control over additional ssh options. So instead of setting ssh.forwardAgent: true in lima.yaml and have the agent forwarded on every connection, you can just forward it the one time you need to pull from a private repo:

ssh -A lima-default git pull ...

Having to patch your local config is an issue for people using multiple machines since you have to remember to configure it.

Just think of it as being part of installing Lima. 😄

[nirs]

Added #3614, maybe it should be a page about using ssh with lima?

[afbjorklund]

This is really not usable for use case of non-default machine.

How so? As mentioned, you do need to configure LIMA_INSTANCE

Maybe we don't really use it for creating a shell to the machine, but for wrapping single commands it is the preferred way.

But a lot of our examples do wrap "foo.lima" to "lima foo", with whatever other environment setup is needed for it to run.