Add fallback for remote SSH connections when direct-streamlocal channel type is unsupported

[parmisean]

Feature request description

When using podman --connection <conn> ... commands to manage remote hosts, Podman currently relies on the OpenSSH channel type direct-streamlocal@openssh.com to tunnel the local API request to the remote Unix socket.

When running these commands on a Tailscale network against a remote host that has Tailscale SSH enabled, the Tailscale SSH server will reject the request with the error Error: ssh: rejected: unknown channel type (unsupported channel type) .

Steps to Reproduce:

1. Set up a remote Linux host (VM or VPS).
2. Install both Podman and Tailscale on the local machine and remote host. Connect both machines to the tailscale network and enable Tailscale SSH on the remote host.
3. Add the remote connection podman system connection add remote-ssh ssh://user@tailscale-ip.
4. Attempt to list images: podman --connection remote-ssh images.

Result: The command fails with the error Error: ssh: rejected: unknown channel type (unsupported channel type).

This proposal does not apply to the podman image scp ... command, which already utilizes the SSH session channel type.

Suggest potential solution

Implementation of a fallback mechanism that does not rely on the direct-streamlocal@openssh.com SSH channel type to improve compatibility with Tailscale and other SSH restricted environments.

1. Create a new SSH client wrapper that implements the net.Conn interface using an SSH session channel.
2. On session.Start the command podman system dial-stdio would be executed to proxy the session input/output to the Unix socket on the remote host.
3. The SSH client wrappers Read and Write methods would map to the sessions stdout and stdin respectively, piping the API calls to the remote Unix socket.
4. This fallback logic would trigger when ssh.DialNet throws an error in

   podman/pkg/bindings/connection.go

   Line 301 in ac91395

   return ssh.DialNet(conn, "unix", _url)

   .

If this is an acceptable approach, I have a working implementation I can provide as either a pull request or for more context around the proposed implementation.

Have you considered any alternatives?

There is an available workaround where the commands can be directly invoked via ssh, for example ssh user@tailscale-ip podman images.

Additional context

The Tailscale issue tailscale/tailscale#12409 is related.