Why is SFTP failing with correct username and password?

And same here. This seems to be a different problem from the issue that Keith refers to. My error message says 'Refused' instead of 'error with connection'.

I'm using a normal username/password login, 'sftp' in terminal works just fine. A more informative error message or a debug log would be much appreciated...

This is the error message:


Skitch upload is working flawlessly (but I don't want all my images on a 3rd party server), haven't tried FTP, does anyone still use that? :P

Some new (but not very helpful :\) information:

• The refused message really is a different message. If the hostname is incorrect I get the 'error with connection' message.


• It seems to be impossible to use a different port number by using something like: hostname.domain.tld:2222 this is required with some virtual server solutions that are used by (shared) hosting companies. In my case I wanted to use it for debugging the ssh connection.

Here is a dump of the ssh connection attempt by Skitch (started debug session with '/usr/sbin/sshd -d -p 22':

debug1: sshd version OpenSSH_4.3p2 Debian-9etch3

debug1: read PEM private key done: type RSA

debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048

debug1: private host key: #0 type 1 RSA

debug1: read PEM private key done: type DSA

debug1: Checking blacklist file /etc/ssh/blacklist.DSA-1024

debug1: private host key: #1 type 2 DSA

debug1: rexec_argv[0]='/usr/sbin/sshd'

debug1: rexec_argv[1]='-d'

debug1: rexec_argv[2]='-p'

debug1: rexec_argv[3]='22'

debug1: Bind to port 22 on 123.my.server.456.

Server listening on 123.my.server.456 port 22.

debug1: Server will not fork when running in debugging mode.

debug1: rexec start in 4 out 4 newsock 4 pipe -1 sock 7

debug1: inetd sockets after dupping: 3, 3

Connection from 123.my.ip.456 port 58311

debug1: Client protocol version 2.0; client software version libssh2_0.14

debug1: no match: libssh2_0.14

debug1: Enabling compatibility mode for protocol 2.0

debug1: Local version string SSH-2.0-OpenSSH_4.3p2 Debian-9etch3

debug1: permanently_set_uid: 101/65534

debug1: list_hostkey_types: ssh-rsa,ssh-dss

debug1: SSH2_MSG_KEXINIT sent

debug1: SSH2_MSG_KEXINIT received

debug1: kex: client->server aes256-cbc hmac-sha1 none

debug1: kex: server->client aes256-cbc hmac-sha1 none

debug1: expecting SSH2_MSG_KEXDH_INIT

debug1: SSH2_MSG_NEWKEYS sent

debug1: expecting SSH2_MSG_NEWKEYS

debug1: SSH2_MSG_NEWKEYS received

debug1: KEX done

debug1: userauth-request for user bartvb service ssh-connection method password

debug1: attempt 0 failures 0

Failed password for bartvb from 123.my.ip.456 port 58311 ssh2

debug1: PAM: initializing for "bartvb"

debug1: PAM: setting PAM_RHOST to "hostname.of.my.mac.nl"

debug1: PAM: setting PAM_TTY to "ssh"

Received disconnect from 123.my.ip.456: 11: Normal Shutdown, Thank you for playing

debug1: do_cleanup

debug1: do_cleanup

I'm 100% sure that the password is correct. Even tried setting the password to something that only contains lowercase letters but that didn't help.

This is what happens when I login with 'sftp bartvb@servername' in Terminal:

[... Lots of stuff is the same as in the failed example ...]

debug1: KEX done

debug1: userauth-request for user bartvb service ssh-connection method none

debug1: attempt 0 failures 0

Failed none for bartvb from 123.my.ip.456 port 58450 ssh2

debug1: PAM: initializing for "bartvb"

debug1: PAM: setting PAM_RHOST to "hostname.of.my.mac.nl"

debug1: PAM: setting PAM_TTY to "ssh"

debug1: userauth-request for user bartvb service ssh-connection method keyboard-interactive

debug1: attempt 1 failures 1

debug1: keyboard-interactive devs 

debug1: auth2_challenge: user=bartvb devs=

debug1: kbdint_alloc: devices 'pam'

debug1: auth2_challenge_start: trying authentication method 'pam'

Postponed keyboard-interactive for bartvb from 123.my.ip.456 port 58450 ssh2

debug1: do_pam_account: called

debug1: PAM: num PAM env strings 0

Postponed keyboard-interactive/pam for bartvb from 123.my.ip.456 port 58450 ssh2

debug1: do_pam_account: called

Accepted keyboard-interactive/pam for bartvb from 123.my.ip.456 port 58450 ssh2

debug1: monitor_child_preauth: bartvb has been authenticated by privileged process

Accepted keyboard-interactive/pam for bartvb from 123.my.ip.456 port 58450 ssh2

debug1: PAM: reinitializing credentials

debug1: permanently_set_uid: 1000/1000

debug1: Entering interactive session for SSH2.

debug1: server_init_dispatch_20

debug1: server_input_channel_open: ctype session rchan 0 win 2097152 max 32768

debug1: input_session_request

debug1: channel 0: new [server-session]

debug1: session_new: init

debug1: session_new: session 0

debug1: session_open: channel 0

debug1: session_open: session 0: link with channel 0

debug1: server_input_channel_open: confirm session

debug1: server_input_global_request: rtype no-more-sessions@openssh.com want_reply 0

debug1: server_input_channel_req: channel 0 request subsystem reply 1

debug1: session_by_channel: session 0 channel 0

debug1: session_input_channel_req: session 0 req subsystem

subsystem request for sftp

debug1: subsystem: exec() /usr/lib/openssh/sftp-server

I'm far from an expert in SSH connections but it looks like Skitch gives up after the first 'failed' and doesn't stick around for the PAM authentication.

I was able to get past this by changing this in /etc/ssh/sshd_config on my server:

PasswordAuthentication yes

(was no).

This bug report was pretty enlightening:
http://bugs.debian.org/cgi-bin/bugrep...

Everything seems to be working now (after I resolved some silly permission problems :D). Would be nice if Skitch was a bit more verbose during file transfer, had to resort to using strace on the server side to figure out what was going wrong...

P.s. contact me by mail or Gtalk (bartvb on the gmail server) if you want a root account on a similar vserver to debug this.

Yeah, the error messages for problems in FTP connectivity are almost useless. Could you not just include a protocol of the login session?

I'm getting the same thing. Connecting to a FreeBSD 7.1 box via SFTP. Telling me my username or password is incorrect. SSH, ExpanDrive and Transmit all work fine.

The bug that I mentioned talks about some possible causes, should make it easier for you to replicate (and fix) this problem.

But good to hear that there is some progress on this bug.

I'm still having this problem, was there ever a solution that worked?

I get the same webpost error message all of a sudden and my user name & password is correct. Very disappointed.