I setup SFTP between *nix servers as follows:

  1. Generate the Public key on the sending server by running the below command:

    [user1@server1] $ /usr/local/bin/ssh-keygen -t rsa -b 1024

  2. Then copy "id_dsa.pub" file into the /home/remote_user1/.ssh/authorized_keys file on the remote machine server2.

  3. Connect to server2:

    $ sftp remote_user1@server2

I am then prompted to enter the password once to complete the handshake and then for all following SFTP connections it directly connects..

But recently another team was able to directly connect to our server without the initial handshake, generally I need to provide the remote_user1's password for handshaking..

So what configuration changes (if any) may have allowed for the handshake to be done without the password..? Any links that could help me better understand the SFTP handshaking process would be very helpful too, as I couldn't find much on this subject.


I'm not aware of any such "handshaking" process in SSH. From the steps you have outlined, however, it seems like you aren't telling SSH to use the key in id_dsa for authentication, which would cause a fallback to password authentication. When you have provided the password, maybe some password or key caching daemon running on the client stores that information and reuses it on subsequent connections?

Could that by any chance be what you are seeing?

If so, one simply needs to tell SSH to use id_dsa for authentication once the remote server knows about the corresponding public key and that it should be allowed to be used for authentication.

OpenSSH's man page says:

-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 protocol version 2. (...)

and if Solaris is anything similar, unless you are in ~/.ssh when running ssh-keygen, SSH doesn't know to use ./id_dsa.

| improve this answer | |
  • Thanks Michael! I was not aware of these possibilities.Will look into it. – Kent Pawar Apr 10 '13 at 7:54
  • 1
    @KentPawar You can use the -v (maybe -vv) flag (assuming OpenSSH, but Solaris should be similar) to display additional information during connection setup and teardown. Specifically, look for messages involving attempted, failed and succeeded authentication methods. Or, if you have access to them, check the remote server logs. That will tell you how SSH is actually authenticating to the remote server, which should provide clear evidence as to whether the hypothesis I outlined is correct or not. – user Apr 10 '13 at 8:54

Turns out I had incorrect permissions set for .ssh and authorized_keys that required me to enter credentials.

~/.ssh directory could have permissions 700 or 755, but not 775 as then others can access the authorized_keys file contents. Giving others write permissions over this file would be missing the whole point of security.

~/.ssh/authorized_keys file can have permissions 400 (readable only to you) or 600 (write-able only to you).

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.