On Sat, Jul 01, 2023 at 05:47:33AM +0900, Dominique Martinet wrote: > hm, this has the password show up in ps on the box executing ssh; > depending on the context that can be bad.
Fair enough. We have no way to judge the OP's risk analysis, because they've kept almost everything secret so far. I place an extremely high value on avoiding solutions that embed passwords inside dynamically generated scripts. Other people may have a different set of priorities. > It does simplify the content of the here-doc a bit because it doesn't > require escaping, but the password itself still needs one layer of > escaping (so in his example not ${password@Q} but ${initial_password@Q} > or $password), and we don't know enough to know if showing up in ps can > be important but passwords have generally been recommended to be passed > through stdin Sure, that would be preferred in most cases. But the OP is specifically giving us a situation where stdin has been tied up sending an ad hoc shell script to be interpreted on the remote host. There are many other ways this problem could be approached. If the script isn't really ad hoc, but is instead something that's going to be executed periodically, it could be stored permanently on the server. Then you could use something like printf '%s\n' "$password" | ssh user@host /opt/foo/bin/myscript where /opt/foo/bin/myscript reads the password from stdin. You could send additional parameters as well, if needed, to prevent needing to send a slightly modified script every time. If you *really* want to embed a password inside a dynamically generated script, perhaps an approach like this would be less dangerous: start="IFS= read -r pass <<'EOF'" end=' EOF The rest of the script goes here and you can'\''t easily use single quotes. ' printf '%s\n%s\n%s' "$start" "$password" "$end" | ssh user@host bash The definition of "end" could be loaded into a variable from a here document to avoid the '\'' issue, if you wish. The extra blank line between the password and EOF doesn't matter, because read only reads the first line. I haven't tested this method, but it looks... less bad than some others. Oh! And you have to make sure the password isn't EOF. Or else use a heredoc sentinel that begins with a character that's not allowed in the password. Or is a password that would be rejected by policy (which, to be fair, EOF would probably be rejected due to shortness). Or something like that.