Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

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.

share|improve this question
add comment

2 Answers

up vote 2 down vote accepted

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.

share|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. –  Michael Kjörling Apr 10 '13 at 8:54
add comment

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).

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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