Hi,
Facing this issue where I need to ssh from a solaris server to Linux server.
The flow is as below:
-Oracle Webserver on solaris server (oracle user) initiates a cgi script
-The CGI script then executes a shell on the solaris server that tries to ssh to linux server

Have already tried the below:
-Checked the permissions for the .ssh and related folder/files
-authorized keys updated correctly
-tried alternative ssh login from another user which works fine

Issue could be-
-I must try the first login manually, where I'll need to enter password and then the solaris server will get registered in the known_hosts of the linux server
-Cant do this because I donot have the oracle user access.

Please suggest a work-around to the issue that can be done from my end.
Or is it that I must simply ask the DBA to execute an ssh from their ends?

Thnx

If this is supposed to be an automated process, you should disable passwd auth and only allow auth-keys. That may get you past the initial login / unknown host issue... not sure.
Prob easiest to ask the DBA to test it. Note that they need to test from the Solaris system to Linux. ssh auth is not bi-directional, and you'd need an ssh server at the other end anyway.

DBAs it is then....still was kind of hoping on sorting this out at my end itself.

Thanks

Which keys where changed? An update of authorized_keys could mean that you updated the list after the oracle keys where changed, or that after a reinstall of Linux, you are starting over creating the authorized_keys list.

Could the problem be with an old entry in ~/.ssh/known_hosts? This list may also contain the public key of the Oracle server, and if its keys changed, there would be a mismatch. If you were connecting from a shell, you would see a message indicating line in known_hosts that caused the problem. Working blind from a CGI script, you may not see the line unless it is logged. Could it also be that the ssh client (on the oracle side) notices that it is a first time connecting with the servers fingerprint and the CGI script doesn't handle it.

If the Linux server was updated, check the release notes. It is possible that you need to indicate the location of the authorized_keys file. When I upgraded to openSuSE10.3, I had ssh connection issues. Looking at the release notes, I found that I needed to change a line to:
AuthorizedKeysFile %h/.ssh/authorized_keys

Another time the host part of my entry in AllowUsers didn't match up with the entry I had in /etc/hosts. One had host and the other host.domain.

The linux server is new box installed- true...but no changes carried out in (oracle) solaris server end.
So I am pretty sure that the old keys at solaris end hold true.

Though i agree on ur point regarding the issue that the cgi script doesnt handle the first time connection that takes place between the solaris server and the new linux server.

I tried to carry out the same connection with a test oracle server whose access rights I have. was able to successfully connect-but ony after the first time manual password entry.

So I believe its the first time entry issue.

Is there any work around for avoiding this?
I mean without having the need to entry password first time manually, resolve the connection on linux end itself?

Your LINUX box has been (re)installed?

You need to update the keys on your solaris server. If it is a reinstallation of your LINUX you might take the keys from your previous installation otherwise you will get a system spoofing error on your solaris server. Always good to have a backup
If it is a new installation you need to login manually once from Solaris to LINUX because you are being asked to store the server keys (this is a one-time process).

Further more, if you are using passwordless executing of scripts on the LINUX server, the LINUX server, or better the account on your LINUX server needs to have the proper keys in the account's ~/.ssh/authorized_keys2 file

All,
The one time password entry resolved the issue.
Asked the DBA to do it using oracle.

Thanks