4 ms·

Oh yes, I've run into this when creating judo[1] (which runs commands/scripts across a fleet of hosts via SSH). It's not even a problem with OpenSSH, the SSH p

Oh yes, I've run into this when creating judo[1] (which runs commands/scripts across a fleet of hosts via SSH). It's not even a problem with OpenSSH, the SSH protocol itself (RFC4254[2], Section 6.5) specifies that the command is sent as a string, and there's just no sane way to convert between an array of strings and a string that's also human-friendly to the command line. My work-around was to allow only a single argument in "judo -c CMD HOST", where CMD is to be interpreted by the target's shell. If you need to do anything more complex, the "judo -s SCRIPT HOST" form is more-or-less equivalent to "chmod +x SCRIPT && ./SCRIPT". [1]: http://github.com/rollcat/judo http://github.com/rollcat/judo [2]: https://www.rfc-editor.org/rfc/rfc4254 https://www.rfc-editor.org/rfc/rfc4254

mst 3y ago
OpenSSH has already added plenty of extensions and the world seems to be fairly comfortable with using quite a few of them - for backwards compatibility reasons they probably can't change the current behaviour by default for -everybody- but a protocol extension and a flag to use it would improve the world substantially.
- rollcat 3y ago
  The current behaviour is already a UX trap, and such an extension would be another one on top of it. What's the sane thing to do if either end does not support it? Any kind of fallback would just make things even worse; detecting and supporting both variants is a road to hell. I still have CentOS 7 systems in production, with the last CentOS 6 box only decommissioned a few years ago. Judo mostly works because it sticks with the lowest common denominator, the value comes from things you can do on top of it.
  - saltcured 3y ago
    What's interesting to me is that this "UX trap" is of ancient origin not mentioned in any post that I could find here. The whole ssh CLI started off trying to mimic the existing rsh CLI experience for basic things, just as scp tried to mimic rcp. To me, this is a bit like the scp vs sftp topic. You really want a new remote-invocation CLI that throws away the rsh compatibility concept and is designed with "modern" goals. And, it probably needs new protocol elements to properly engineer it. But this is also similar to the "system" callouts from multiple languages which abdicate responsibility and pass a command string to an external interpreter. Are all these API designers so naive, or do they have a philosophy of being so inclusive that they are not willing to assume that a command on a target system involves an executable and an array of arguments?
    - rollcat 3y ago
      > Are all these API designers so naive, or do they have a philosophy of being so inclusive that they are not willing to assume that a command on a target system involves an executable and an array of arguments? Remember APIs are made for humans, (assuming we're talking local processes) nobody can stop you from using raw fork(2)+pipe(2)+execve(2) every time, yet you will usually reach for popen(3).
  - formerly_proven 3y ago
    Add a flag or option to the client, e.g. -oSplitExec=true or -E* or whatever. This then uses an execv request type or something like that. If the server does not understand that, this is an error. OpenSSH updates tend to be rolled out very slowly though. So if you wanted any kind of widespread usability of this option, you would've needed to add this about ten years ago. * this is of course alreay taken, it seems only -u and -z are free at this point. You could use -U and pretend to be a roman (EXECUE).
blincoln 3y ago
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

mst 3y ago

OpenSSH has already added plenty of extensions and the world seems to be fairly comfortable with using quite a few of them - for backwards compatibility reasons they probably can't change the current behaviour by default for -everybody- but a protocol extension and a flag to use it would improve the world substantially.

rollcat 3y ago
The current behaviour is already a UX trap, and such an extension would be another one on top of it. What's the sane thing to do if either end does not support it? Any kind of fallback would just make things even worse; detecting and supporting both variants is a road to hell. I still have CentOS 7 systems in production, with the last CentOS 6 box only decommissioned a few years ago. Judo mostly works because it sticks with the lowest common denominator, the value comes from things you can do on top of it.
- saltcured 3y ago
  What's interesting to me is that this "UX trap" is of ancient origin not mentioned in any post that I could find here. The whole ssh CLI started off trying to mimic the existing rsh CLI experience for basic things, just as scp tried to mimic rcp. To me, this is a bit like the scp vs sftp topic. You really want a new remote-invocation CLI that throws away the rsh compatibility concept and is designed with "modern" goals. And, it probably needs new protocol elements to properly engineer it. But this is also similar to the "system" callouts from multiple languages which abdicate responsibility and pass a command string to an external interpreter. Are all these API designers so naive, or do they have a philosophy of being so inclusive that they are not willing to assume that a command on a target system involves an executable and an array of arguments?
  - rollcat 3y ago
    > Are all these API designers so naive, or do they have a philosophy of being so inclusive that they are not willing to assume that a command on a target system involves an executable and an array of arguments? Remember APIs are made for humans, (assuming we're talking local processes) nobody can stop you from using raw fork(2)+pipe(2)+execve(2) every time, yet you will usually reach for popen(3).
- formerly_proven 3y ago
  Add a flag or option to the client, e.g. -oSplitExec=true or -E* or whatever. This then uses an execv request type or something like that. If the server does not understand that, this is an error. OpenSSH updates tend to be rolled out very slowly though. So if you wanted any kind of widespread usability of this option, you would've needed to add this about ten years ago. * this is of course alreay taken, it seems only -u and -z are free at this point. You could use -U and pretend to be a roman (EXECUE).

blincoln 3y ago

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