Opened 16 years ago
Last modified 9 years ago
#3201 closed Bug report
RC2 connect with SSH problems
|Reported by:||vytautas||Owned by:|
|Keywords:||Cc:||vytautas, Tim Kosse|
|Component version:||Operating system type:|
|Operating system version:|
After updating to RC2 of FileZilla 3 Client it will no longer connect when using SSH authentication. Connecting with the same key from the same computer with FileZilla 2 works OK, as did the previous release of FileZilla 3
Here is the connection log:
Status: Connecting to vytautas.mine.nu:22...
Response: fzSftp started
Trace: CSftpControlSocket::ConnectParseResponse(fzSftp started)
Command: open "ftpweb@…" 22
Trace: Looking up host "vytautas.mine.nu"
Trace: Connecting to 192.168.1.100 port 22
Trace: Server version: SSH-2.0-OpenSSH_4.5
Trace: Using SSH protocol version 2
Trace: We claim version: SSH-2.0-PuTTY_Local:_Aug_26_2007_22:50:51
Trace: Doing Diffie-Hellman group exchange
Trace: Doing Diffie-Hellman key exchange with hash SHA-256
Trace: Host key fingerprint is:
Trace: ssh-rsa 1024 65:16:d9:bc:18:86:c6:10:db:7b:68:27:cc:fe:a5:e2
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: Reading private key file "C:\Documents and Settings\User\My Documents\Keys\Linux-Server-FC4.ppk"
Trace: Pageant is running. Requesting keys.
Trace: Pageant has 1 SSH-2 keys
Trace: Configured key file not in Pageant
Trace: Offered public key
Trace: Server refused public key
Trace: Disconnected: No supported authentication methods available
Error: Disconnected: No supported authentication methods available
Error: Could not connect to server
Status: Waiting to retry...
Change History (3)
comment:1 by , 16 years ago
comment:2 by , 16 years ago
OK, after more checking it seems that FileZilla is no longer using keys stored in the Pageant first or something along those lines, but defaults to trying key files stored in the Putty session settings stored in windows registry.
I fixed this problem by deleting the Putty session data from the registry and then it connected OK on the affected PC.
However I would think that that is not a desirable way/order of reading keys.
comment:3 by , 16 years ago
This behavior is inherited from the latest PuTTY builds. According to the comments in the PuTTY source, this is by design.
Sorry, I'll do some more testing on this as it seems to be working on another computer. Maybe that PC was being difficult.