SSH login via scipt

[zaksworld]

I have some web servers that I manage, so I Have to constantly update them.

It is a real pain when I am constantly running scripts and have to type in the root password about 5-10 times per computer per update.

I know there is a way to store my main computer's data on the servers so that I don't have to type the username and password every time, but since I have a bunch of computers, I still have to run the code to get into every computer, so even without typing in the username and password, it is still very time consuming.

All my servers have the same root password, so if there is any line of code I could add to my script (or just a script I could run), so my main computer will login automatically, or if there is any way that I can store my server's data on my main computer, so that my main computer can login to my servers automatically, I would like to know.

Thanks in advance
Zak

[JT9161]

Use keys

[whoop]

Use keys

He is saying "authenticate using keys"

Still I wouldn't use this to login to an account with elevated privileges, but maybe I'm paranoid.
In any case, using keys is always more secure (if you don't count debian's blunder, that is, but that is solved now)...

[kevdog]

I believe you can do this using expect. Here are a couple examples:

Sorry I couldnt find better ones:
http://bash.cyberciti.biz/security/e...-login-script/
http://www.unix.com/shell-programmin...ll-script.html

[terbor]

You can change the name of the folder you store your keys in (so it is not the standard ) and turn off the password access ( If this applies to the way you access your servers now )

[iponeverything]

I think expect is just what your looking for.

I have used it quite a bit in situations like you have described.

Once I had 100 catalyst switches, and had to go though every one and change the enable password and DHCP helper address.

I added all the IP addresses for the switches to a file and wrote an 20 line expect script..

Then, I just sit back and watch. I check the logs I created for errors and move on to something else..

[Denbert]

I have some web servers that I manage, so I Have to constantly update them.

It is a real pain when I am constantly running scripts and have to type in the root password about 5-10 times per computer per update.

Why don't you setup an auto-update job on each server, with a mail report back to you?

http://www.debianadmin.com/automatic...-cron-apt.html

[apmcd47]

I think Denbert's suggestion is best. Use cron jobs on the servers.

If not, public key authentication is the way forward. By using expect I imagine you will be putting passwords in a shell-script. A big no-no in my opinion.

I think I would do the following:

1) Set up a new public/private key pair, using, say, rootpriv as the name of the key.

2) Imagine dave is the name of one of your servers. Copy rootpriv.pub into /root/.ssh/authorized_users on dave.

3) In your account on your normal machine, add the following to ~/.ssh/config:

Host root-dave
   Hostname dave
   Username root
   Keyfile rootpriv

This is from memory, check the manpage on ssh-config for the actual keywords. But this should mean when you ssh to root-dave you will login to dave as root using rootpriv for authentication. You would do (2) and (3) for the other servers.

4) If you are using ubuntu you will probably be running your desktop inside an ssh-session. Thus running

ssh-add

in a shell terminal will prompt you for the passphrase of your default keys and allow you to login to other machines with those keys without prompting for your passphrase. It is possible to remove the key from the session too. When you logout the the session and hence the stored key is lost, so you would need to do this every time you log in.

Add the following lines to the top and bottom of your shellscript:

ssh-add ${HOME}/.ssh/rootpriv
ssh-add -d ${HOME}/.ssh/rootpriv

You will be prompted for the rootpriv passphrase every time you run the script, but only once during the course of the script. You will also have to change every ssh invocation from eg

ssh root@dave ...

to

ssh root-dave ...

The problem with this of course is that the servers are open to anyone with access to your desktop during the time your script is running, so if you leave it unattended, lock it. Alternatively run the script inside its own ssh session (man ssh-session).

Andrew

[BkkBonanza]

You may also want to read up on cluster ssh (google it).
This version of ssh allows you to run commands on multiple servers simultaneously. If your systems are similar enough this may make routine admin work easier.

[zaksworld]

Why don't you setup an auto-update job on each server, with a mail report back to you?

http://www.debianadmin.com/automatic...-cron-apt.html

Haha, well, I've thought about that, but because of other complications, I am not allowed, plus it might not work as well as expected...but thanks for the idea anyways!

I think expect is just what your looking for.

I have used it quite a bit in situations like you have described.

I have thought about using expect, but (because of the same complications) I am not allowed to use it either, but thanks for the idea.

If not, public key authentication is the way forward. By using expect I imagine you will be putting passwords in a shell-script. A big no-no in my opinion.

I'm trying to avoid using public key authentications, because then I have to go onto each individual server and not only install the updates, but use a bunch of extra time to be able to get all of the keys, and time is money! ha


I did manage to find somewhat of a solution. It's a program called sshpass

apt-get install sshpass

. It allows me to run (or write in a script)

sshpass -p 'password' ssh -o StrickHostKeyChecking=no user@myipaddress

I only need to install this on my main computer (so only one install), and I can write the other computers passwords into a script.

I know some people have a concern about this, but the passwords change often, so even if someone can get the scripts (highly unlikely), then the system is still mostly safe.

Now, I'm going to keep this post open, just in case anyone has any ideas about this, and because I haven't tried the sshpass yet. Once I test out the sshpass today (and it succeeds), I'll close this post.

Thanks everyone!
Zak