Re: maybe a bug in bash?

[Sebastian Luhnburg]

Hello Greg,

thank you for your quick answer, too!

First, I am not a Bash mastermind or have deeper knowledge about secure 
programming. Your suggestion about the risk of coding injection is very 
interesting! But I will read the full text after my holidays, which will 
begin after this E-Mail :)
But I will explain what I want to do and why I think it is a good way 
(it may be a little bit off topic for this mailing list).

First, in my LPIC-1 course the lecturer tell me it is better (not 
binding) to deny SSH login for root users (especially for the user with 
the name root). The reason is simple: decrease the attack surface. Yes, 
a secure password needs a lot of time to be cracked via brute force, but 
if the attacker did not know the username, which is needed to login, the 
attacker must get two things. For my opinion, the decrease the attack 
surface is a good approach.

Why I did not use SSH keys instead of SSH password login? We use a 
self-hosted password manager (precise Bitwarden). So, we have a central 
collection point of credentials and sensitive data. Every server have a 
unique password. If I use SSH keys, it is a decentral approach. Every 
user must manage his keys, which allows to connect to the servers. E.g. 
if the user change his computer, the WSL instance etc pp, all keys must 
secure separately from decentralized places. Yes, an SSH jump host could 
be a solution, but this is a future project. At the moment, I think the 
use of a password manager is an easier way to do this.

You suggest to use an argument, to pass the password. Please correct me 
if I be wrong, but to write one or more password(s) in clear text as an 
argument in the terminal (./myscript.sh password1 password2) is not the 
best practice (the Bash history save the last x commands). To get the 
input via an password manager (like Bitwarden CLI) is at this point the 
better way I think (code injection stay be a problem, if I use the 
passwords in an awkward way in my script).

Mit freundlichen Grüßen

Sebastian Luhnburg
IT
----------------------------------------------------------------------
swp software systems GmbH & Co. KG

Königsbrücker Straße 124
01099 Dresden
Tel: 0351-492850
Fax: 0351-4928550
www:https://www.vi-bim.de

Kennen Sie schon unsere FAQ-Wissensdatenbank? Einfach hier 
klicken:https://faq.vi-bim.de

Unsere Datenschutzerklärung finden Sie unterhttps://datenschutz.vi-bim.de

Registergericht: Amtsgericht Dresden HRA 3008
persönlich haftender Gesellschafter:
swp Beteiligungs GmbH
Registergericht: Amtsgericht Dresden HRB 15 20 9
Geschäftsführer: Holger Schönemann, Stefan Urlberger

Am 29.06.23 um 15:42 schrieb Greg Wooledge:
> On Thu, Jun 29, 2023 at 11:33:15AM +0200, Sebastian Luhnburg wrote:
> > I want to use this password in an here document, which inject some
> > commands into a SSH-Connection (for simplification, I use the bash instead
> > of ssh in the test script below).
> Skipping the "is it a bug or not" part, which has already been addressed
> as a mis-quoting issue, let's talk about the goal.
>
> First of all, is this the password *of* the ssh connection itself?  If
> so, that can be addressed by switching to key-based authentication (and
> either using a key with no passphrase on it, or an ssh-agent to hold
> your passphrase).
>
> Second, are you trying to do something like this:
>
>      sshnonroot@some.host  'sudo some command'
>
> where the password is for "sudo" because you aren't logging in directly
> as root?  The answer to this is so blastedly obvious that I shouldn't
> have to state it, but nonetheless, here we are: just ssh in as root
> instead of nonroot + sudo.
>
> Some folks will scream that this is a bad idea, horrible practice, can't
> do it, etc.  These folks are idiots.  Ssh can be configured to allow
> root logins only when using key authentication.  That's as secure as you
> could ask for.  Certainly it's at *least* as secure as throwing a password
> around and using sudo and invoking layers of quoting hell.
>
> But let's say it's not either of these things.  Maybe it's a database
> access password or something, and you're actually doing something like:
>
>      sshnonroot@some.host  'mysql -p mydatabase ...'
>
> The obvious play here is to send the password on stdin.  But you've
> introduced another layer of complication, because you're actually doing
> something like:
>
>      sshnonroot@some.host  bash <<-EOF
>      some command
>      another command
>      mysql -p"$injected_password" mydatabase
>      EOF
>
> where stdin is already tied up sending the script for bash to execute,
> and therefore can't be used to send the database password.  This is NOT
> going to work.
>
> What you want to do instead is pass the password as an *argument* to
> bash -s.  You've already got the @Q (or printf %q) part, which is a
> necessary step.  You just need the rest of it.
>
>      sshnonroot@some.host  bash -s "${password@Q}" <<-'EOF'
>      some command
>      another command
>      mysql -p"$1" mydatabase
>      EOF
>
> This is also described in a bit more detail at
> <https://mywiki.wooledge.org/BashProgramming/05#Passing_arguments_to_ssh>.
> I recommend reading that whole page when you get a chance.
>
> Here it is in action:
>
> unicorn:~$ password='$foo&bar'
> unicorn:~$ ssh localhost bash -s "${password@Q}" <<-'EOF'
> > printf 'Password is <%s>\n' "$1"
> > EOF
> greg@localhost's password:
> Password is <$foo&bar>

OpenPGP_0x1E7D455B730DAD17.asc
Description: OpenPGP public key

OpenPGP_signature
Description: OpenPGP digital signature