SSH that requires a password via a bash script

[inthespotlite82]

Hey guys-

I'm trying to create a BASH script that will connect to a remote server, via SSH that requires a password, and then search a log file for the word error, store the output in a file, and then return the file to the local machine. I would like this process to be completely automated and run via cron. How would you go about supplying a password to SSH or scp? Is there a better way I should be doing this? I'd like to avoid the route of setting up public/private DSA/RSA keys, and would like to find a way to do this via scripting. I'd appreciate any input. Thanks in advance. So far, this is what I have.

#!/bin/bash
#Global Variables - Established in case variables are not passed to the script.
server="my_server" #The name of the server that we'll connect to.
local_server="host" #The name of the host machine.
uName="user" #The user name that we will use for this connection.
pass=`cat /root/LDAP.pwd` #A secure password file.

ssh -l $uName $server <<- EOF #I need a password here somehow
cd /var/log
grep error log.txt > myErrors.txt
scp myErrors.txt $uName@$local_server #I need a password here somehow
EOF

[eggi]

Hey There,

What you're trying to do is possible, if you use a program like "expect" to pass your password interactively (well, mock-interactively ;) to ssh and/or scp. However, your downside security wise would be much steeper than setting up dsa keys and strict trust (user@ip, etc).

Are you avoiding ssh key-exchange because it's a hassle to setup? I only ask because it has a major upside. Giving a password in a script is almost guaranteed to be much less secure (assuming you don't want people to know the password - if that's not a huge concern, and you just need to get the job done with an account that can suffer a compromise, let me know). Check out "expect" as a way to work around this if you need to. ssh and scp don't provide any mechanisms for non-interactively giving them a password other than through (at worst) rsa-keys or rhosts authentication.

Best wishes,

Mike

[inthespotlite82]

Thanks for the info. One of the server guys here at my work had mentioned "expect". I can run the script as sudo and the password file is in root's home, so I'm not too worried about compromised security if I can pass the value to ssh or scp from a file, which is what I was hoping I could do. Expect would seem to open a security hole, so I would prefer finding another method, if possible. The DSA key is a possibility, but I need to figure out how to import it from another machine that is already setup with one. On a personal note, I just like to figure out a way to accomplish my goal. I'm sure there has to be some neat little trick that I'm msising.

[eggi]

The bummer is that ssh/scp don't provide for any way (hence "expect") for you to pass them a password in non-interactive mode.

If you need to set up keys, maybe this will help - a quick step by step assuming user1 (should be whomever is going to be doing the actual transfer, so if root is running an scp for another user, that user's key will be important)

1. On the sending host, if you havent' already, for root and/or the user who the transfer will be done as, log into that account and run:

ssh-keygen -t dsa

just hit enter for all the defaults. Don't enter an extra security password or even this won't work automatically ;)

2. On the receiving host, for the user account that will be being transferred to (regardless of "where" on the machine the data is going if user2 is accepting the data and you're putting it in /tmp we need to run this command in user2's homedir)

either login as user2 and run

ssh-keygen -t dsa (unnecessary if you do the next thing ;)

or

mkdir -m 700 .ssh

cd into .ssh in user2's home directory and create a file called (depending on what version of ssh you're running) authorized_keys or authorized_keys2 (doesn't hurt to do both, either)

3. Populate authorized_keys or authorized_keys2 with the output from the id_dsa.pub file from the user on the sending host. If you cut and paste, make sure that the entry is one line when you put it into authorized_keys/authorized_keys2

A simpler way to setup the authorized_keys files is to do your first interactive scp how you would want to automate it and scp your id_dsa.pub file to [email]user2@theOtherHost:~/.ssh[/email]/authorized_keys

and/or to

[email]user2@theOtherHost:~/.auth[/email]orized_keys2

Then just send the file again (shouldn't get prompted for a password) or do a simple ssh over (the way you would during your execution) and your command should be executed remotely without a password prompt.

Hope that was helpful and I didn't leave too much out :)

Best wishes,

Mike

[FloridaMike]

Hello,

I know this is an old thread, but I did figure a way around the scp/ssh password issues in Ubuntu. I came to this site while trying to find an answer like the original poster asked.

Ubuntu 11.04, as you may know does not have a root login. This makes it difficult to use SCP in a bash script with the Tomcat server as Tomcat executes the script as root. In other words, it would work fine if you had root accounts on both machines which Ubuntu does not allow (and really is a good thing). If I could execute the script as another user, then the key pair will accept the connection sans a password.

The answer was found after much trial and error and error and error. So in the spirit of cooperation, here is the solution that executed as root running on Ubuntu and Tomcat for me:

#copy server to server shell script
HOST=$1
USER=$2
MYPATHFILE=$3
FARPATH=$4
sudo -uanother_user_name scp $MYPATHFILE $USER@$HOST:$FARPATH

Hope this helps...

Michael

[masijade]

Sorry, but tomcat does not need to "run as root", and anything the tomcat process executes will, of course, be executed with the same user as the tomcat process, so, why not simply run tomcat under a different user? Not that this is the answer to any "ssh" problem, as it would be a pain to execute tomcat under every user login that might be needed, so that part of your post is useful. However, you should be running tomcat under a user other than root already anyway, as, currently, running as root, if a hack makes its way onto the system through tomcat it will have root privileges. Do you not see that as a possible problem?