On Fri, Jun 30, 2023, 23:21 Greg Wooledge <g...@wooledge.org> wrote:
> 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.
>
declare -p
works well for transmitting bash vars around via ssh
ssh foo "$(declare -p vars)
more code"
>
