/cc @dmitshur

This is one of the issues I'm looking at. In trying to envision how it would work, the following question came up.

Given that we have gomote put, is scp support going to be needed and helpful? Doesn't gomote put already do what scp would let you do? Or are there specific use cases we're aware of that would make this worthwhile.

One observation about ssh vs scp. Gomote currently lets the user "ssh into" a buildlet by running gomote ssh <instance>, but it works by creating an ssh shell and letting the user use it. The normal ssh client isn't supported directly. I don't think the same solution would work for scp, because we don't want to re-implement all the complex syntax that the scp client supports.

gomote put and gomote gettar are tedious and don't work with existing tools like rsync.

The normal ssh client isn't supported directly.

It is if you run it by hand. gomote ssh echos out the command you could run on your own.

All that's required to fix this bug (I think) is to respond to "sftp" channel open requests in our ssh server and open a new onward "sftp" channel to the backend and stitch them together with a copy io.Copy goroutines.