I had a similar experience when I was testing A Black Path Toward the Sun[1], specifically using SSH and SCP over the HTTP/HTTPS tunnel, as well as when I was w

I had a similar experience when I was testing A Black Path Toward the Sun[1], specifically using SSH and SCP over the HTTP/HTTPS tunnel, as well as when I was writing unreleased SSH pen testing tools at two different organizations. I found that SSH is more complicated than I would have expected at a low level, and far more barebones than I would have expected at a higher level. It's incredibly sensitive to certain types of small delay for its packets. On the other hand, the actual terminal traffic is basically just a pair of streams. For an interactive SSH session, there's no useful concept of "send a command and wait for it to finish on the remote system", because the remote system is just piping the output of the shell back to the SSH client. You can hack in something like generating a random tag and appending "; echo '---complete:{random_tag}---'" to every command and assuming the command is complete when that string appears, but it's not built in, and of course every SSH server OS can have different syntax requirements, so now the client has to detect and handle each of those. It makes sense given that SSH is a general-purpose protocol that's supposed to work for just about any CLI, so I was surprised for the same reason as the author of the article. Their issue makes sense in context as well - SSH has to support server shells like the Windows command prompt that don't even have the concept of an array of arguments at a low level, just the command string. [1] https://github.com/nccgroup/ABPTTS https://github.com/nccgroup/ABPTTS