4

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

To make sure this worked I did the standard sftp user@sftp.xxxxxx.com 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 user@sftp.xxxxxx.com again and I am still prompted for a password, but now the password doesn't work...

Connecting to user@sftp.xxxxxx.com...
user@sftp.xxxxxx.com's password: 
Permission denied, please try again.
user@sftp.xxxxxx.com's password: 
Permission denied, please try again.
user@sftp.xxxxxx.com'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!

UPDATE I have just run sftp -vvv user@sftp.xxxxxx.com

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

icelizard
  • 732
  • 3
  • 10
  • 20
  • When you login using the password, are you able to navigate your home directory? If so you should be able to see for yourself what is in authorized_keys for that user account. – dunxd Apr 12 '12 at 13:59

4 Answers4

1

debug3: Trying private key: /root/.ssh/id_dsa

debug3: no such identity: /root/.ssh/id_dsa

Did you create your key pair as the root user? Doesn't look like you did, as /root/.ssh/id_dsa does not appear to exist (or perhaps the permission are wrong: should only be read/writeable by root; no world/group read/write access).

EDIT

Looks like you've generated rsa keys by the look of your ls but you're offering dsa keys.

gravyface
  • 13,957
  • 19
  • 68
  • 100
0

Are you saying you can log in with empty root password? I would highly consider reviewing this and ensure the account has not being compromised.

ls -l /root/.ssh/id_dsa

should return

-rw------- root ...
northox
  • 187
  • 1
  • 8
0

Open a new terminal and run sshd in debug mode ( -d option) on an other port. Debug mode only works if you use full path. So

`which sshd` -d -p 9999

Watch the stdout of that console and try sftp again

sftp -oPort=9999 user@sftp.xxxxxx.com

Check the output and if you cannot figure out what is happening, paste it to here.

Gabor Vincze
  • 554
  • 1
  • 4
  • 11
0

ssh is VERY STRICT on permissions. Also, how are you specifying the key? Are you letting ssh try the default of ~/.ssh/id_rsa ?

Please try specifying the key at the CLI with this: -oIdentityFile=/root/.ssh/id_rsa

If you have access to the server as root, check auth.log and you can find out why it's rejecting the key... but it's very interesting that the server appears to accept the key at one point.

UtahJarhead
  • 928
  • 7
  • 14