[Bug]: proxycommand fails to start handshake properly if doing OIDC login

[Janhouse]

Steps to Reproduce

1. Do the ssh host attempt using OIDC SSO without doing step ssh login and without doing ssh host attempt beforehand.

• Every time before running ssh host run step ssh logout to trigger login mechanism

Your Environment

• OS - Archlinux
• step-ca Version - 0.23.0

Expected Behavior

It should create the certificate, add to the agent and log you in the server by starting ssh handshake.

Actual Behavior

Certificate it created, added to agent but login fails with Bad packet length on client side and Bad protocol version identification '' from sshd side. Client starts the handshake by sending the cypher list, skipping the first step.

Additional Context

The ssh host command and proxycommand works correctly if the certificate is already made and added to agent. If it has to be made and added to agent in one try, it fails because SSH handshake fails.

proxycommand for some reason step cuts the initial handshake message containing SSH protocol version. From wireshark it looks like this:

Meanwhile, on subsequent tries and when certificate has been added in any other way, the handshake part looks like this:

This issue has been previously mentioned in https://github.com/smallstep/certificates/pull/561#issuecomment-828989785 but it was not addressed and no bug report was made.

Contributing

Vote on this issue by adding a 👍 reaction. To contribute a fix for this issue, leave a comment (and link to your pull request, if you've opened one already).

[Janhouse]

I debugged it a bit and here is the reason this bug exists:

step ssh config sets up ssh ProxyCommand without the provisioner parameter.

By default after adding oidc provisioner on step ca, there are 3 provisioners (OIDC, JWK, SSHPOP).

The step client uses the user selection (thus reads from stdin) to choose the provisoner, which is also the case for proxycommand, since it just reuses the same code as step ssh login.

So if I change the ~/.step/ssh/config and pass the --provisioner xxx to the ProxyCommand then it works correctly.

This is still a bug since by default a broken configuration is set up, and step proxycommand attempts to read provisioner selection from input, but instead reads the first message from SSH handshake, since ProxyCommand uses stdin and stdout for communication.

One way to solve this would be by selecting the first provisioner by default in case of ssh login. Or asking a user to set the default one in config.

Another, and maybe(?) a better/correct solution would be to use the ProxyUseFdpass configuration parameter and set up a filedescriptor instead of using stdin/stdout:

Specifies that ProxyCommand will pass a connected file descriptor back to ssh 
instead of continuing to execute and pass data. The default is no.