Is there a way to SSH / SCP to another server as a different user, via a script?

"Corporate S(tupidity)" :-)

SSH / SCP generally lives with the realm of UNIX philosophy I think. It is very rare that the designers of Unix applications intentionally make it so the administrator can't easily do something stupid. There will be generally be a warning like: "You probably don't want to do this because ... but, if you really want to, fine!".

In the case of passing a password to ssh in a script, they intentionally make this difficult, because it just such a bad idea.

At this point, I wouldn't even bother with SSH. You really need to talk with the corporate security people and come up with a real solution for the scenario. If they don't want to use keys, ask them what you should do. If that doesn't work, tell your managers what they want can't be done due to corporate security restrictions. If the managers do insist that you do this, get it in writing, or it is your ass on the line

Insert standard disclaimer about corporate policy and why it's bad to put user/pass in scripts here.

But we all work in the real world where sometimes it doesn't make sense. Soo.. There are many tools that will let you do this. Shell does not have a built-in way to get this working. My weapon of choice for very quick and dirty scripts of this nature is Expect. It is rediculously easy to get running.

#!/usr/bin/expect

set nodename "hostname"
set username "user"
set password "pass"
set prompt "your prompt on the remote system"

eval spawn ssh -x $user@$nodeaddy

set timeout 15

expect "password:" { send "$password\r" }
expect "$prompt" { send "script\r" }
exit 0

Obviously this may or may not work for you, but you can see from the syntax just how simple it is to get working.

First a warning: be careful that you don't create a security issue in the name of expediency. Kevin and Kyle bring up good points. Storing a bunch of username/password combinations in a file (even an encrypted database) is probably a very bad idea and may violate corporate policy.

The solution to your problem may be a client side certificate. See the below articles for more information:

• Setting up SSH keys for access without a password
• Run Remote Commands with SSH

Assuming that a public private key pair is allowed by the corporate policy this is not that hard to achieve. To get a username different from the user running ssh (the script) use username@host. The harder part is to get the proper private keys working. Assuming that because of some kind of false sense of security each host must use a different key pair (otherwise it is simpler) you should create a configuration file that tells the client which pair to use for which host (you can also actually specify the username in the file).

For openssh the file would look like

host a_prod
    user usera
    IdentityFile ~/.ssh/keyfora_prod

host b_dev
    user userb
    IdentityFile ~/.ssh/keyforb_prod

etc.

Just remember that this setup is not actually more secure. If someone can get access to this user on this computer he can read all private keys (that can't have a password if things must be secure, or you must hack around with ssh_agent) as well as hardcoded passwords. As there is no reason for the private key files to live anywhere else but in the ssh dir of this user (when lost, one can easilly create a new key) having four files is not different from having one from a security perspective.

OK - I finally got this working as follows:

1. Do the ssh-keygen on all of the servers.
2. Setup the authorization file for each user with their public key.
3. Setup the identification file for each user with the private key
4. Copy the private keys for the destination servers to the server you want to ssh from as unique files (b_dev_id_dsa_2048_a, c_test_id_dsa_a, ...)
5. Call ssh as follows on host a: ssh -i b_dev_id_dsa_2048_a b_dev@b

and viola, it finally works.

Thanks you everyone for the help, and finally niXar for that final Homer Simpson DUH moment as doing this is exactly backwards to what you do if the user is the same across all of the hosts.

Without private keys or Expect or something like it, I don't see how you can do this automagically. Something's got to give.

You do have something to work with, do you? I supposed you don't have Perl around since you could then use Expect.pm? Python? Anything? Just plain old ugly ksh? Tell us more.

If you're not allowed to use a programming language, then you need to enter the pass by hand. In that case you can use:

scp myfile b_dev@b_prod:/path/to/dest

If batches are involved, consider using SFTP instead. You could then use lftp, and not have to type the password, here straight from the manpage:

lftp [-d] [-e cmd] [-p port] [-u user[,pass]] [site]

But if you can't get Expect I doubt you can use lftp. Can you?

/ Oh I hate proprietary Unix crap

It's not a good idea, but if you really need to do it sshpass can help you: http://sourceforge.net/projects/sshpass/

I had to do something similar, only backwards. We're pulling files off of a bunch of servers, and this is the way we did it.

awk '{FS="|"; printf("rsync %s:%s %s &\n", $1, $2, $3)}' config | sh

Create a file called config and in it put the lines you want to run. (please note: you need to insert a blank line to start with).

The way it's setup right now, you would put [email protected]|(folder on remote server)|(folder on local server) into config, and it will rsync the two. You will want to switch the rsync command in the awk command to do the opposite.

This would work well with ssh-key auth, which is what we use.

I would as well suggest creating SSH-Keys for the authentication and use a tool like unison or lsyncd (depending on your need) to keep files in sync.

If the key based authenitication is not an option, you can use "expect" (http://linux.die.net/man/1/expect) to script it. Expect checks for a defined outupt (lets say the question for the password) and related to that enters a defined string (in that example the password).

But again as suggested, i would prefer the ssh-key solution.