Super User is a question and answer site for computer enthusiasts and power users. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I am trying to sftp into an a server hosted by someone else.

To make sure this worked I did the standard sftp i was promted with the password and that worked fine.

I am setting up a cron script to send a file once a week so have given them our public key which they claim to have added to their authorized_keys file.

I now try sftp again and I am still prompted for a password, but now the password doesn't work...

Connecting to's password: 
Permission denied, please try again.'s password: 
Permission denied, please try again.'s password: 
Permission denied (publickey,password).
Couldn't read packet: Connection reset by peer

I did notice however that if I simply pressed enter (no password) it logged me in fine...

So here are my questions:

  1. Is there a way to check what privatekey/pulbickey pair my sftp connection is using?
  2. Is it possible to specify what key pair to use?
  3. If all is setup correctly (using correct key pair and added to authorized files) why am I being asked to enter a blank password?

Thanks for your help in advance!


I have just run sftp -vvv

debug1: Authentications that can continue: publickey,password
debug3: start over, passed a different list publickey,password
debug3: preferred gssapi-with-mic,publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering public key: /root/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Server accepts key: pkalg ssh-rsa blen 277
debug2: input_userauth_pk_ok: SHA1 fp 45:1b:e7:b6:33:41:1c:bb:0f:e3:c1:0f:1b:b0:d5:e4:28:a3:3f:0e
debug3: sign_and_send_pubkey
debug1: read PEM private key done: type RSA
debug1: Authentications that can continue: publickey,password
debug1: Trying private key: /root/.ssh/id_dsa
debug3: no such identity: /root/.ssh/id_dsa
debug2: we did not send a packet, disable method
debug3: authmethod_lookup password
debug3: remaining preferred: ,password
debug3: authmethod_is_enabled password
debug1: Next authentication method: password

It seems to suggest that it tries to use the public key... What am I missing?

share|improve this question

migrated from Jul 19 '11 at 14:12

This question came from our site for professional and enthusiast programmers.

Are the keys installed in /root/.ssh or your own homedir? – Fred Foo Jul 19 '11 at 11:25
/root/.ssh (note currently logged in as root) – Lizard Jul 19 '11 at 11:30
It looks to me like the guy who runs that server as wrecked his PAM configuration. It's nearly impossible to say why without being able to see it. – bahamat Jul 19 '11 at 17:16
The line debug3: no such identity: /root/.ssh/id_dsa in the above output seems to be the point where publickey authentication fails. Does that file exist on your machine? If it exists, is it readable by anyone other than you (it shouldn't be: it should have permissions 400 or 600). This applies to it's containing directory too (which chould have permissions 700). – Fran May 18 '12 at 13:54
up vote 1 down vote accepted

Running in verbose mode should help you:

sftp -vvv

Which will show you what keys it is using and hopefully why its asking for a password.

update: You can tell ssh which private key to use: but Im unsure how you would do the same server side

share|improve this answer

First link that came up on how to do what you did:

Seems to describe the same steps you took, but without the resulting trouble. Did you make sure your private keys aren't using a password? The site implies the keys are matched automatically by SFTP; I'm guessing it's using the key fingerprints.

Also, have a look at the man page for SFTP and try specifying the desired options to prefer key-based authentication over password authentication.

Perhaps the server-side isn't properly configured? For example, the authorized_keys file has an incorrect entry specifying the user@host?

share|improve this answer

You must log in to answer this question.

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