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.

2 Answers 2


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.

  • Thanks Michael! I was not aware of these possibilities.Will look into it.
    – Kent Pawar
    Commented Apr 10, 2013 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
    Commented Apr 10, 2013 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).

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .