Need help with database remote script

[Ben Prusinski_1]

Hi gurus

I am trying to get the following scripts to work. Basically, we are trying to copy some Oracle database control files from one server to another via either ssh or rsh and rcp. The second step of the script calls another script on the remote server to execute. Below is the body of the script:

I. calloutscript1 on server a:

#!/bin/ksh
# connect to remote host and execute script
MOUNTHOST=100.1.1.2
USER=erm
PASS=erm
#
ssh $USER@$MOUNT_HOST; read $PASS
#
#execute this script on mount host
# remote host
./opt/mountchecks.sh ps1_ps2.env

II. Scripts on Mount host B
(these are on Host A and need to be
executed from Host B via remote connection from host A)

mountchecks.sh

#!/bin/ksh

. /opt/strat.env

# Get the environment for this activty
get_environment $1
. /opt/ps.env
# close connection and return to host A
exit 0

Thanks
Ben

[Michael Schulte zur Sur]

Hi Ben,

so, where do you need help?

Michael

[Ben Prusinski_1]

Michael,

I need to do two things in the first script on Server A:

1) open a remote connection using ssh to copy files to a remote host, Server B

2) in the script on Server A, I need to connect to Server B via ssh to execute a script on Server B in the script on Server A.

The problem I have is I can get ssh to connect but it prompts me for a password and my script breaks on Server A in this point. I have not done shell scripting in a while. Thanks

-Ben

[RAC_1]

ssh does not work that way. You have problem with the way you are authenticating ssh. That can be done in three ways.

1. hosts based (use of .shosts and /etc/shosts.equiv files)
2. password based
3. exchange of public/private keys.

For logging into another hosts without being prompted for passwords, you need to set as option 1 or option 3

Option 3 is better. With this, you generate the keys and put it in users authorized_keys file. Set ssh to authenticate as option 3 and you are done.

Anil

[RAC_1]

http://www.employees.org/~satch/ssh/faq/ will help you in setting up ssh for exchange of public and private keys.

Anil

[Eric Antunes]

Hi Ben,

It maybe better to use remsh specifying a command:

remsh host [-l username] [-n] command

The man remsh says:

"...
If command, is not specified, instead of executing a single command, you will be logged in on the remote host using rlogin
..."

[Muthukumar_5]

We can transfer files or execution command as,

r* commands
secure commands

If you want to do secure way,

you have to share public/private keys between the hosts.

Or you can use .shosts / /etc/shosts.equiv file. see man .shosts file.

If you want to do it by simple then make r* commands setup as,

host1:

$HOME/.rhosts
host2 +

If you want to give only to root then,

$HOME/.rhosts
host2 root

change the permission to 400.

Make it on two side.

Use rcp to copy files,

to execute commands then,

remsh host2 hostname
host2

It is easy to do. If you want to do it in secure then use scp and ssh.

[RAC_1]

Doc on setting up ssk keys.

Using H/P's Secure Shell & Secure Copy


Purpose:

As we migrate to more secure systems, convenient utilities such as FTP and TELNET will be replaced with more secure systems. Secure Shell (ssh) and Secure Copy (scp) are the standard replacements for these. Over time, the insecure utilities will be completely blocked from use, so all users with HP Unix accounts will need to become familiar with these. Because of the authentication and encryption, making a connection initially is slower than the insecure systems. But once the connection is made, they are equally as fast and convenient.

Authentication & Encryption

Both ssh and scp use public/private key encryption. This document will not cover the theory behind this authentication and encryption algorhythym. This is covered in Practical Unix & Internet Security: 2nd Edition (Garfinkel/Spafford, © 1996, 1991 O'Reilly & Associates, Inc.) in considerable depth. This document will concentrate on the actual use of this technology rather than the theory.


Setting up the keys

1. It is most efficient to take the time to set up all hosts at the same time. If you have an account on 6 machines, set up all 6 at the same time. If you later are granted access to another machine, it is your responsibility to make the modifications to all of them. This is the responsibility of each user rather than a job for the systems administrator.
2. Fastest/easiest way to set up the key files.
a. Open a session on one host using CDE (Citrix Metaframe for Unix is best). Open a standard text terminal session inside the CDE desktop.
b. Also open the text editor from the CDE desktop.
c. On the terminal session, type ssh-keygen -t dsa. Press for the next 3 questions. Do NOT use a passphrase unless instructed to do so by Security, or if standard policies change.
i. The above command will create the .ssh directory under the users' home directory.
ii. It will also create 3 files, you will add a fourth, and a fifth will soon appear.
d. Change into the .ssh directory with cd ~/.ssh.
e. Next, display the public key created with the previous step: cat id_dsa.pub. This will show the lengthy public key.
f. Highlight that public key by holding the left mouse button down, and dragging the cursor down across the displayed characters. There are a LOT of them. The very last will be your user name and the host on which you're working. Make sure that they are all highlighted, but nothing else.
g. At the top of the menu bar, click Edit --->Copy. This loads the character string into the CDE paste buffer
h. Next, move the cursor into the menu bar of the text editor. Click Edit-->Paste. This writes the paste buffer into the text file. At the end of the line, type a single so that the carriage returns to the far left.
i. Return to the text terminal session by clicking on its menu bar. Ensure that your home directory has appropriate permissions. Type cd ../.. which will move up two directories in the hierarchy. List the directory with ll. On the far left, the permissions should read drwxr-xr-x. If they don't, change them with chmod 755 . The secure utilities will not work properly if these permissions are not correct.

j. Next, open a session on the next host on which you will use the secure utilities. Type ssh . You will be challenged with: The authenticity of host ' (ip address)' can't be established. RSA key fingerprint is (long hexadecimal number). Are you sure you want to continue connecting (yes/no)? Answer yes.
k. You will next see Warning: Permanently added '(hostname) (IP address) ' (RSA) to the list of known hosts. You will then be challenged for your password, as normal.
l. Close the session on remote host, return to the standard terminal session on the host. Next, either open a session on another remote host, or continue with step m below if you have completed steps c-k, above on all hosts. You will be creating a text file with the contents of the id_dsa.pub file from each host, separated by a carriage return.
m. When steps c-k have been done on all hosts, save the text file. Click on File-->Save As, and enter /(the path to your home directory/.ssh/authorized_keys. It is essential to save this file in this particular directory with this particular filename. Be sure that this path/filename is in the box near the bottom of the popup window.
n. Next, ensure that the authorized_keys file has the proper permissions. Return to the home session on the first system. Then change into the .ssh directory with cd ~/.ssh.
o. List the .ssh directory with ll. The authorized_keys files should show -rw-r--r-- on the far left. If not, change the permissions with chmod 644 authorized_keys.
p. Next copy the authorized_keys file into the .ssh directory of each remote host on which you ran steps c-k, with scp authorized_keys HOST:/(my home directory)/.ssh/authorized_keys.
q. Lastly, open a session on each host that has the authorized_keys file, with ssh . You will be challenged for a password, but if the previous steps have been done exactly, this will be the last time. You can check this by logging off (with exit or ), then logging on again. You should not be challenged for a password. If so, check permissions as above before opening a help desk ticket.
r. You might want to open a session ON each host, TO each host. Again, you should only be challenged for a password the first time. Afterwards, you may ssh or scp securely without being prompted for a password.
s. If you are later granted access to another host, you must add the contents of its ~/.ssh/id_dsa.pub file to each ~/.ssh/authorized_keys file.


An