passing passwords to a script

Question

I want to scp a file to a remote host, and from there, run a command on the file, and exit the remote session. If I write a usual script, call scp and then ssh, I am prompted to enter two passwords. Is there a way to copy, ssh, and run a command on a remote machine with one password?

Also how to write scripts which need to interact with user to enter passwords?

I do not want to use "read" as it's not safe. I do not want to use passwordless ssh, since my private key file may be compromised, which is even worse. I read something about "expect" but not sure if it's the right tool.

Solution 1

I do not want to use passwordless ssh, since my private key file may be compromised, which is even worse.

No, this is wrong. A private key file provides more security than a password. Use a private key file. The private key file is encrypted with a password; if someone gets the key file, they still need your password. If you were using password authentication, anyone getting hold of the password would be home free.

Run ssh-agent for the duration of your session. Before you use a particular key, enter the password with ssh-add (or through some GUI prompt). Then there won't be a prompt when you connect using this key.

Solution 2

Is there a way to copy, ssh, and run a command on a remote machine with one password?

There are two ways, varying in their convenience and trade-offs.

One is to transfer the file inline. Do you need input other than the file content? If not, ssh example.com 'cat > the_file ; process the_file' < the_file will do what you want.

The other is to do something that reuses the SSH connection. ControlMaster and friends for ssh might help - see ssh_config(1) for details, or there are various wrappers, or implementations of SSH for various programming languages that help.

Also how to write scripts which need to interact with user to enter passwords?

Read it from the TTY. Generally, the best strategy is to allow ssh to interact directly with the user and not get in the way, because it has a much better tested and validated implementation of interacting in this way.

I do not want to use read as it's not safe.

For interacting with the user, I presume. It isn't substantially different in safety to just letting SSH ask, actually, but it is ideal to just stay out of the way.

I do not want to use passwordless ssh, since my private key file may be compromised, which is even worse.

...and I presume that the SSH agent isn't acceptable either for about the same reason.

Solution 3

Using 'expect' for what you ask is possible and some people still use it. An expect script can 'catch' the commands output and you can 'answer' based on their output. Your script will look like:

spawn scp some_file user@host:/destination
expect "*?assword:*"
send -- "Your Super Secret Password Here\r"
send -- "\r"

Of course this would work but it would rise another problem. Your password will be saved in a plain-text form and anyone reading this file would be able to see your password.

My personal opinion is that the safest non-interactive way is the private-key-authentication.

Comments

[Mingye Wang]

except also stores your password in plain in memory, so it's as bad as read. Oh, not that bad. Since read is a shell builtin, the variable may be kept in the memory for a longer time if you don't unset it.

[eli]

The cat solutions works well; I printed a file this way yesterday. Apparently it works for many file types too. I did not know about MasterControl, I have to check it out. Thanks a lot for pointing it out.

[eli]

Sure. But if someone gets your private key file, he can take his time to run various softwares on that to break it. But getting your password is not like that and is generally harder to hack. So I am not sure how safe is ssh-agent. If someone breaks your key, would he need to use your own machine too to connect to the remote host, or can connect from any station?

[jw013]

@eli Cracking a password protected key file shouldn't be any easier than cracking an account password of equivalent strength. A good random key is much harder to guess than a typical password. The one reason I have seen for enforcing password-only is because it is simpler logistically for site-admins to enforce site-wide password strength policies than it is to enforce private key passphrase policies.