using the CLI to test the agent is awkward and this is an example. This test would be easier to write and easier to understand if were inagent_test.go and we could use the go ssh client.

I do somewhat agree, but I'm not sureagent_test.go is a much better place since the actual forwarding is implemented here, incli/remoteforward.go. This test should ensure that the behavior we want works with the actualcoder ssh client.

We already have tests forcoder ssh in terms of making a unix socket remote forward and verifying it works. None of that behavior is changing in this PR.

What's changing is on the agent side of the connection. And it's not justcoder ssh that talks to that SSH server: it could be OpenSSH or JetBrains Gateway or VSCode (viacoder ssh --stdio), or even a custom SSH client written in go usingcodersdk. Therefore, we need to think about the required behavior in terms of what the SSH server is supposed to do, not just end-to-end with a specific client.

Yeah, I'm not opposed tbh. I think the best place for most of this testing is within theagentssh package itself. I'll create an issue for this since if we go this route, there's some other restructuring that needs to be done as well. Like moving the forwarding logic fromcli toagentssh, etc. Otherwise I think we'll end up with "many implementations of an SSH client".

#11650