Re: maybe a bug in bash?

[Greg Wooledge]

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.