Solaris

Hi,

Earlier, I have configured SFTP successfully in my prev jobs.
This time I have to configure SFTP for local server (uses SSH2) and remote server (uses SSH).
I tried to search the forum. I did not find the right thread.
I appreciate your help.
The following is the additional info

Code:

> ssh -V
sshg3: SSH Tectia Client 6.0.5 on sparc-sun-solaris2.8
Build: 7
Product: SSH Tectia Client

Are you asking ssh2->ssh machine?

On solaris the primary ssh1 method of access is --

ssh1 access files: /etc/hosts.equiv or /etc/shosts.equiv or $HOME/.shosts or $HOME/.rhosts on the server along with /etc/ssh_known_hosts to allow access.
The secondary method uses the equiv files, which is less secure.

Is this what you are asking?

When I generate the key in SSH2, the key could not be associated to SSH1 as the key generation of SSH2 is different from SSH1.
Earlier I just configured both (target and source server are same as either SSH1 or SSH2) but do not have good knowledge of admin side of Unix/Linux.

ssh1 keys are dsa

Code:

ssh-keygen -t dsa

They go in ~/.ssh as authorized_keys - start with protections on .ssh as 700.
The files in .ssh as 700 also. The root user cannot have access via keys in SSH.

See if that helps.

I do not have control over .ssh as it is in remote server. The local server (which I have control) has SSH2.
Another quick question from your reply - Do you mean to say that dsa is generated for SSH and rsa is generated for SSH2? I know one creates key and other creates the key as well as encrypts it.

ssh1 keys are created by the following command when you are running the command on an ssh2 box:

ssh-keygen -t dsa

If you run keygen on an ssh1 box there is no -t option AFAIK. rsa and dsa are rivest and diffie-hellman, they are not encrypted, they are plaintext keys. you get two keys when you run keygen - a public key and a private key. The public key is sent to the remote machine. You have to use a public key that works for ssh1, generated on an ssh2 box, hence the -t option for backward support.

You can fall back to /etc/hosts.equiv if you cannot make the keys work.