SFTP - Using RSA Key authentication. Still prompts for password

[offerrp]

Hi

Server A: Generated RSA Key
Server B: Added the RSA Key to authorized_keys list
SFTP from A to B.
Still prompts for password.

I will be sftp-ing both from Server B to Server A and 'A to B'.
Sever B to Server A works fine. No prompting for password.

But from A-B it this is what is happening
sftp -v log...

debug1: Offering public key: ~InfAdmin-.ssh-id_rsa
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
debug1: Trying private key: ~InfAdmin-.ssh-id_dsa
debug1: Next authentication method: password
InfAdminATServerB's password:

Why is this trying id_dsa private key?
From Server B to Server A when I do the same, it does not say 'Trying Private Key -id_dsa'
This is what it says
debug1: Server accepts key: pkalg ssh-rsa blen 277
debug1: read PEM private key done: type RSA
debug1: Authentication succeeded (publickey).

How do I enforce that Server A does the same? Why is it trying the dsa private key when I have used RSA. Any suggestions?
Thanks
KJ

[Mudgen]

-i identity_file
Selects a file from which the identity (private key) for RSA or
DSA authentication is read. The default is ~/.ssh/identity for
protocol version 1, and ~/.ssh/id_rsa and ~/.ssh/id_dsa for pro-
tocol version 2. Identity files may also be specified on a per-
host basis in the configuration file. It is possible to have
multiple -i options (and multiple identities specified in config-
uration files).

I'd guess that ssh_config on server B specifies the rsa key, and does not on server A, thus when that server initiates, the default dsa key is attempted.

[Edit: Actually, I don't have that quite right, but look at the differences in the ssh_config files and/or ~/.ssh/config files.]

[offerrp]

Thank You for your time.
I checked the config files in both server A and server B.
/etc/ssh/ssh_config and /etc/ssh/sshd_config are alike

# IdentityFile ~/.ssh/identity
# IdentityFile ~/.ssh/id_rsa
# IdentityFile ~/.ssh/id_dsa

I checked in the .ssh folder for this user. There is no specific config file. Any suggestions? I can pull the file from ServerB. But I'd rather have this Push from Server A to Server B.

Server B
debug1: Offering public key: /home/InfAdmin/.ssh/id_rsa
debug1: Server accepts key: pkalg ssh-rsa blen 277
debug1: read PEM private key done: type RSA

Server A:
debug1: Offering public key: /home/InfAdmin/.ssh/id_rsa
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
debug1: Trying private key: /home/InfAdmin/.ssh/id_dsa

The only difference I see is that InfAdmin belongs to group app in Server A and a different group in Server B. Not sure if it is an issue..

Any help is appreciated
Thanks

[rdrewd]

I suggest you add a few -v's on your ssh command line to increase the amount of diagnostic messages it reveals to you. One or 2 -v's ought to be enough.

Be aware that ssh is incredibly picky about ownership and permissions on the .ssh directory and the files under it. "ls -ld" and "ls -l" are your friends. Pay particular attention that your user-id # might differ on A and B so copying the .ssh files from one server to the other could confuse the ownership or permissions.

My advice is to sit with a copy of the ssh man page. Figure out what ugly hairy command line options make the authentication work and then work out how to set up the .ssh/config file on the machine that is originating the ssh connection so the ssh command doesn't need those big hairy arguments on the command line any more.

Check to see if you have different versions of ssh on A and B.
If you can bring the ssh & sshd versions and configurations into agreement, that is surely going to be a Good Thing. It is almost never a Good Idea to continue using a less-than-current version of ssh.

The -v's might be helpful in figuring out how it is that the ssh that works is working for you. The old Sherlock Holmes clue of the dog that didn't bark!

Drew

[offerrp]

I changed the permission of the authorized_keys in serverB to 600. It works now
both ways.
I just hope it doesnt mess up anything with the other connections that have been set already and working good.