SSH options in hcloud server ssh

[dottedmag]

TL;DR

$ hcloud server ssh -v myserver
hcloud: unknown shorthand flag: 'v' in -v

Expected behavior

It would be nice to be able to pass arbitrary SSH options to hcloud server ssh.

[phm07]

You should already be able to just do this:

$ hcloud server ssh myserver -v

[dottedmag]

Aha, and the command is delimited by --, I see, nice.

Should it be documented then?

[phm07]

Aha, and the command is delimited by --, I see, nice.

Yes, this is the default behavior as described in the posix standard:

Guideline 10:
    The first -- argument that is not an option-argument should be accepted as a delimiter indicating the end of options. Any following arguments should be treated as operands, even if they begin with the '-' character.

And it is implemented by spf13/cobra, the CLI framework we use.

Should it be documented then?

Since this behavior is not unique to the hcloud CLI and we don't even implement it ourselves, I don't know if documenting it would make sense. This is how the documentation looks like right now:

Usage:
  hcloud server ssh [options] <server> [command...]

Flags:
  -h, --help          help for ssh
      --ipv6          Establish SSH connection to IPv6 address
  -p, --port int      Port for SSH connection (default 22)
  -u, --user string   Username for SSH connection (default "root")

I agree that it is not instantly apparent that you can pass flags to the ssh binary using the [command...]. Maybe something like this is better:

Usage:
  hcloud server ssh [options] <server> [ssh options] [command [argument...]]

[dottedmag]

My confusion stems from the following. SSH manpage documents that options can only be specified before the server name:

ssh [-tons of options here] destination [command [argument ...]]

I had a look at source hcloud server ssh code and indeed it appends the arguments to after the server name, and this I have confirmed by looking at process table:

hcloud server ssh <name> -v bash

runs

ssh -l root -p <ip> -v bash

which, I supposed, would try to run command -v on the remote server.

But apparently and unexpectedly OpenSSH client accepts options even after the server name, only -- stops its option processing. TIL, after 25 years of using SSH! Worth documenting, yes.