Re: maybe a bug in bash?

[Greg Wooledge]

On Fri, Jun 30, 2023 at 11:17:06PM +0900, Dominique Martinet wrote:
> Sebastian Luhnburg wrote on Fri, Jun 30, 2023 at 03:47:57PM +0200:
> > p.s.: in the final script, it is only one SSH:
> > 
> > ssh user@machine << EOF
> > /bin/bash -c "do something with the password"
> > EOF

I wish you would remove the layers of obfuscation here, and just state
clearly what you're doing.

Why are you running /bin/bash inside the script which is already
being executed by the remote user's shell?  Is this is a stand-in for
some other program?  Is it just a bad design?  We can't tell!

> then as Greg suggested pass password to bash as argument instead;
> assuming password has been quoted once as previously:
> ssh user@machine << EOF
> bash -c 'echo \$1' -- $password
> EOF

I never suggested embedding the password inside an unquoted here document.
My suggestion was more like this:

ssh user@machine bash -s "${password@Q}" <<'EOF'
echo "$1"
EOF

Or if the remote user's shell isn't bash, then use "sh quoting" instead of
bash's @Q quoting.

q=\' b=\\
ssh user@machine bash -s "'${password//$q/$q$b$q$q}'" <<'EOF'
echo "$1"
EOF

In all cases, the here document is quoted ('EOF' instead of EOF) so no
substitutions occur within it.  It's passed to the remote system as
written.  The password is passed as an argument to the command which is
executed by sshd -- in this case, bash, which will interpret the
script passed in by stdin, and which now has the password as its "$1"
parameter.

Therefore, you can use "$1" inside the script (which is inside the quoted
here document) to refer to the password.

Everything I've written here is boilerplate.  You can take it exactly as
I've written it, and replace the echo "$1" with your actual commands.

Telling us more about the setup you're working with (is the remote user's
shell sh or bash, for example) would help us simplify the advice we
give, by removing unneeded "but if..." scenarios.