Ubuntu – SFTP: Turn off Pageant to force password instead of public key

ftpsftpUbuntu

I'm trying to SFTP to a server with a username and password supplied to me by a client but I keep getting Disconnected: No supported authentication methods available (server sent: publickey). I'm on Ubuntu 13.10 and I have tried using the Filezilla gui as well as sftp -vv user@host and lftp -u user sftp://host in the terminal.

Here's the output I get from Filezilla in Debug:Verbose mode:

Response:   fzSftp started
Trace:  CSftpControlSocket::ConnectParseResponse(fzSftp started)
Trace:  CSftpControlSocket::SendNextCommand()
Trace:  CSftpControlSocket::ConnectSend()
Command:    open "user@host" 22
Trace:  Server version: SSH-2.0-CoreFTP-0.3.1
Trace:  Using SSH protocol version 2
Trace:  We claim version: SSH-2.0-PuTTY_Local:_Sep_14_2013_01:12:43
Trace:  Using Diffie-Hellman with standard group "group14"
Trace:  Doing Diffie-Hellman key exchange with hash SHA-1
Trace:  Host key fingerprint is:
Trace:  ssh-rsa 1024 b1:ac:c5:b6:d2:b8:d3:ef:fc:d2:b3:d8:06:2c:d2:25
Trace:  Initialised AES-256 SDCTR client->server encryption
Trace:  Initialised HMAC-SHA1 client->server MAC algorithm
Trace:  Initialised AES-256 SDCTR server->client encryption
Trace:  Initialised HMAC-SHA1 server->client MAC algorithm
Trace:  Pageant is running. Requesting keys.
Trace:  Pageant has 1 SSH-2 keys
Trace:  Trying Pageant key #0
Trace:  Sending Pageant's response
Trace:  Access denied
Trace:  Disconnected: No supported authentication methods available (server sent: publickey)
Error:  Disconnected: No supported authentication methods available (server sent: publickey)
Trace:  CSftpControlSocket::ResetOperation(66)
Trace:  CControlSocket::ResetOperation(66)
Error:  Could not connect to server

sftp -vv output is similar. It seems that Pageant is offering my public key before the password (which is normal) but then does not continue to password authentication. Is there a way to force password authentication first (ie bypass Pageant altogether)? I have to be able to bash script operations over this connection so using the sftp or lftp commands will be necessary. Is there a flag I can set to accomplish this? I looked in the man pages but didn't find what I was looking for.

There is always the chance that something is misconfigured on the client's server but since the client is able to login from this account no problem I suspect the problem is somewhere on my side.

UPDATE

The client is able to log into the server with this account using Filezilla on windows, ruling out the possibility that their server is configure to only allow public key auth. This is a larger company with an IT department that have many such accounts so it is reasonably safe to assume they have done this before. Here is the output from their Debug:Verbose in Filezilla:

 Status:                   Connecting to host:22...

Trace:                     Going to execute "C:\Program Files\FileZilla FTP Client\fzsftp.exe"

Response:             fzSftp started

Trace:                     CSftpControlSocket::ConnectParseResponse(fzSftp started)

Trace:                     CSftpControlSocket::SendNextCommand()

Trace:                     CSftpControlSocket::ConnectSend()

Command:             open "user@host" 22

Trace:                     Looking up host "host"

Trace:                     Connecting to xxx.xxx.xxx.xxx port 22

Trace:                     Server version: SSH-2.0-CoreFTP-0.3.1

Trace:                     Using SSH protocol version 2

Trace:                     We claim version: SSH-2.0-PuTTY_Local:_Jun_15_2008_14:47:43

Trace:                     Using Diffie-Hellman with standard group "group14"

Trace:                     Doing Diffie-Hellman key exchange with hash SHA-1

Trace:                     Host key fingerprint is:

Trace:                     ssh-rsa 1024 b1:ac:c5:b6:d2:b8:d3:ef:fc:d2:b3:d8:06:2c:d2:25

Trace:                     Initialised AES-256 SDCTR client->server encryption

Trace:                     Initialised HMAC-SHA1 client->server MAC algorithm

Trace:                     Initialised AES-256 SDCTR server->client encryption

Trace:                     Initialised HMAC-SHA1 server->client MAC algorithm

Command:             Pass: ********

Trace:                     Sent password

Trace:                     Access granted

Trace:                     Opened channel for session

Trace:                     Started a shell/command

Status:                   Connected to host

Trace:                     CSftpControlSocket::ConnectParseResponse()

Trace:                     CSftpControlSocket::ResetOperation(0)

Trace:                     CControlSocket::ResetOperation(0)

Status:                   Retrieving directory listing...

Trace:                     CSftpControlSocket::SendNextCommand()

Trace:                     CSftpControlSocket::ChangeDirSend()

Command:             pwd

Response:             Current directory is: "/"

Best Answer

The server is configured to only allow publickey authentication, not passwords. You can see this where it says:

Trace:  Disconnected: No supported authentication methods available (server sent: publickey)
Error:  Disconnected: No supported authentication methods available (server sent: publickey)

Related Solutions

Ubuntu – Loggin in ssh server: Permission denied, please try again

Are you certain that the user account you're attempting to access is correctly configured? If you log in as root on the system, can you su to the user account?

# su - username

What do you see in your logs after a failed connection attempt? On many systems, sshd will log to something /var/log/secure or /var/log/auth.log. Also, I note that you have PasswordAuthentication enabled but ChallengeResponseAuthentication disabled. Do you see the same behavior if you enable ChallengeResponseAuthentication?

Here are some general diagnostic steps to use when you have ssh problems:

Enable verbose diagnostics in ssh:
```
ssh -v host.example.com
```
This will cause the client to output a variety of diagnostic messages as it negotiates the connection. This will often provide a clue to the problem.
Run the server in debug mode.

On your server, stop sshd, then run it from the command line like this:
```
/usr/sbin/sshd -d
```
This will produce verbose debug logging on stderr that will very often contain useful information.

If neither of these helps you figure out what's going on, would you add the output to your question?

Linux – What could cause an SFTP host key fingerprint mismatch

If it is the first time they connected, it doesn't matter if there's a mismatch... the client just had some unrelated old entry that happened to have the same host name or ip address associated with it. Just clear it with:

ssh-keygen -R $name_or_ip

After you do that, it should certainly say whether it is RSA, ECDSA, etc. the next time you connect. If not, try using a proper client like the OpenBSD OpenSSH client which is standard on Linux, or trying -v (or -vvvv, etc. verbose options). And then verify and accept the new key. The key fingerprint format in old clients is md5 (and in new ones is sha256, in some weird base64 format instead of ascii-hex), and the right way to get the fingerprint on the server side is:

ssh-keygen -l -f /etc/ssh/ssh_host_rsa_key

Best Answer

Related Solutions

Ubuntu – Loggin in ssh server: Permission denied, please try again

Linux – What could cause an SFTP host key fingerprint mismatch

Related Topic