Using a variable's value as password for scp, ssh etc. instead of prompting for user input every time

Question

AFAIK, the commands ssh or scp do not have/take a password parameter. Otherwise I could keep the password in a shell variable and probably get rid

Answer 1

For those for who setting up a keypair is not an option and absolutely need to perform password authentication, use $SSH_ASKPASS:

SSH_ASKPASS - If ssh needs a passphrase, it will read the passphrase from the current terminal if it was run from a terminal. If ssh does not have a terminal associated with it but DISPLAY and SSH_ASKPASS are set, it will execute the program specified by SSH_ASKPASS and open an X11 window to read the passphrase. This is particularly useful when calling ssh from a .xsession or related script. (Note that on some machines it may be necessary to redirect the input from /dev/null to make this work.)

E.g.:

$ echo <<EOF >password.sh
#!/bin/sh
echo 'password'
EOF
$ chmod 500 password.sh
$ echo $(DISPLAY=bogus SSH_ASKPASS=$(pwd)/password.sh setsid ssh user@host id </dev/null)

See also Tell SSH to use a graphical prompt for key passphrase.

Answer 2

For password authentication, as you mentioned in you description, you can use "sshpass". On Ubuntu, you can install as "sudo apt-get install sshpass".

For public/private key-pair base authentication,

• First generate keys using, "ssh-keygen"
• Then copy your key to the remote machine, using "ssh-copy-id username@remote-machine"

Once copied, the subsequent logins should not ask for password.

Answer 3

Expect is insecure

It drives an interactive session. If you were to pass a password via expect it would be no different from you typing a password on the command line except that the expect script would have retrieve the password from somewhere. It's typically insecure because people will put the password in the script, or in a config file.

It's also notoriously brittle because it waits on particular output as the event mechanism for input.

ssh-agent

ssh-agent is a fine solution if this is script that will always be driven manually. If there is someone who will be logged in to drive the execution of the script than an agent is a good way to go. It is not a good solution for automation because an agent implies a session. You usually don't initiate a session to automatically kick of a script (ie. cron).

ssh command keys

Ssh command keys is your best bet for an automated solution. It doesn't require a session, and the command key restricts what runs on the server to only the command specified in the authorized_keys. They are also typically setup without passwords. This can be a difficult solution to manage if you have thousands of servers. If you only have a few then it's pretty easy to setup and manage.

service ssh accounts

I've also seen setups with password-less service accounts. Instead of the command entry in tehh authorized_keys file, and alternative mechanism is used to restrict access/commands. These solutions often use sudo or restricted shells. However, I think these are more complicated to manage correctly, and therefore tend to be more insecure.

host to host automatic authentication

You can also setup host 2 host automatic authentication, but there are alot of things to get write to do this correctly. From setting up your network properly, using a bastion host for host key dissemination, proper ssh server configuration, etc. As a result this is not a solution a recommend unless you know what your doing and have the capacity and ability to set everything up correctly and maintain it as such.

Answer 4

The right way to do that is as follows:

1. Ensure that all your users are using ssh-agent (nowadays this is the default for most Linux systems). You can check it running the following command:

   echo $SSH_AUTH_SOCK

   If that variable is not empty, it means that the user is using ssh-agent.

2. Create a pair of authentication keys for every user ensuring they are protected by a non empty passphrase.

3. Install the public part of the authentication keys on the remote host so that users can log there.

4. You are done!

Now, the first time an user wants to log into the remote machine from some session it will have to enter the passphrase for its private key.

In later logins from the same session ssh-agent will provide the unlocked key for authentication in behalf of the user that will not be required to introduce the passphrase again.