Timeline for Why doesn't ssh localhost sh -c 'echo "$0"' arg0 output anything?
Current License: CC BY-SA 4.0
13 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Sep 22, 2022 at 16:16 | comment | added | PatS | In my case I could not use root directly to login, this was not permitted. All root actions had to be initiated via sudo after logging in as a "non root" user. So the statement "assuming you have root equivalence" and corresponding use of root@host1:/etc/hosts could not be used. Also it took me a little while to understand your answer, but overall it was very informative. Thanks and Best Wishes. | |
| Sep 16, 2022 at 17:27 | comment | added | Ярослав Рахматуллин | ssh passes the arguments as a single token. concatenation would be: sh-c'echo"0=$01=$2"'arg1arg2arg3 . perhaps i'm splitting hair here, but I would not call what ssh is doing concatenation. | |
| Sep 16, 2022 at 14:58 | comment | added | Barmar | @user253751 why the heck does ssh concatenate all the arguments?. So that you can write simple commands more easily, e.g. ssh hostname cp foo bar instead of ssh hostname 'cp foo bar' | |
| Sep 16, 2022 at 14:56 | comment | added | Barmar | @gronostaj Yes, that's what it stands for, but the intent is that it's the secure replacement for the previous rsh, which stands for "remote shell". They could have called it srsh to be explicit, but they chose a shorter name. | |
| Sep 16, 2022 at 14:48 | comment | added | ilkkachu | @user253751, the remote system might implement some restrictions through the choice of the user's shell, including things like having a restricted or totally customized shell, or even preventing logins by having something like /bin/false as the shell. That's useful and straightforward behaviour and means restrictions like that don't need to be implemented in multiple places (like the SSH server configuration in addition to the user's passwd entry). I wouldn't be surprised if there were compatibility issues with earlier tools like rsh too, but I don't really know about those. | |
| Sep 16, 2022 at 14:41 | comment | added | gronostaj | @user253751 To be fair "ssh" stands for "secure shell" | |
| Sep 16, 2022 at 11:09 | comment | added | Chris Davies | @user253751 ssh does ask for a remote shell. By definition | |
| Sep 16, 2022 at 9:29 | comment | added | Gordon Davisson | @user253751 ssh doesn't parse the arguments again, it passes them to a shell on the remote system and that parses them. If the remote command wasn't parsed by a remote shell, you couldn't use any shell features like redirects, wildcards, or compound commands (multiple commands separated by ;, ||, &&, or if or while or ...). It looks to me like the real problem here is that you've added a third shell (and a third layer of parsing) by using sh -c. | |
| Sep 16, 2022 at 9:04 | history | edited | Chris Davies | CC BY-SA 4.0 | Advice on solving the ssh command line quoting problem |
| Sep 16, 2022 at 9:01 | comment | added | Chris Davies | To be honest I'd never considered that. I learned that ssh passed its args to the remote shell, and that's where it was executed. As a result I tend to write ssh remoteHost 'some command line…', which reminds me that the some command line… part will be passed verbatim to a remote shell for execution as if I'd typed it directly. (Wrap the line in single quotes to avoid local evaluation, or use double quotes to interpolate local variables.) I'll update my question to include this. | |
| Sep 15, 2022 at 21:51 | history | edited | Chris Davies | CC BY-SA 4.0 | Another suggestion |
| Sep 15, 2022 at 21:16 | history | edited | Chris Davies | CC BY-SA 4.0 | Answer the question that was only asked as an afterthought |
| Sep 15, 2022 at 21:10 | history | answered | Chris Davies | CC BY-SA 4.0 |