Cyberduck Mountain Duck CLI

Opened on Feb 3, 2007 at 8:56:30 PM

Closed on Feb 6, 2007 at 4:34:39 PM

Last modified on Jun 12, 2010 at 1:09:25 AM

#1016 closed defect (fixed)

SFTP: Login Not Attempting Public Key Authentication

Reported by: ibrandt Owned by: dkocher
Priority: normal Milestone: 2.7.3
Component: sftp Version: 2.7.2
Severity: normal Keywords:
Cc: Architecture:
Platform:

Description

Great app, however I can't get SFTP to try public key authentication against my linux server (running "OpenSSH_4.5p1, OpenSSL 0.9.8d 28 Sep 2006"). I can log in with password authentication. I can also log in fine with the OpenSSH sftp command line client ("OpenSSH_3.9p1, OpenSSL 0.9.7d 17 Mar 2004") using password and public key authentication.

I ran "defaults write ch.sudo.cyberduck logging INFO", and the console output is below. I'm not getting any IO or key parsing errors like the other public key authentication related bugs I found in Trac.

I've tried both RSA and DSA SSH Protocol 2 keys, both password-less. (And I am checking off the "Use Public Key Authentication" option in the connect dialog, and then selecting either my id_rsa or id_dsa private key files.)

I've tried 2.7.2 and nightly 2813. 

599080 [Background] INFO ch.cyberduck.core.Session  - Mounting myhost...
599081 [Background] INFO ch.cyberduck.core.Session  - Opening SSH connection to myhost...
599510 [Background] INFO com.sshtools.j2ssh.transport.TransportProtocolCommon  - Starting transport protocol
599511 [Transport protocol 2] INFO com.sshtools.j2ssh.transport.TransportProtocolCommon  - Registering transport protocol messages with inputstream
599512 [Transport protocol 2] INFO com.sshtools.j2ssh.transport.TransportProtocolCommon  - Negotiating protocol version
599815 [Transport protocol 2] INFO com.sshtools.j2ssh.transport.TransportProtocolCommon  - Protocol negotiation complete
600167 [Transport protocol 2] INFO com.sshtools.j2ssh.transport.TransportProtocolCommon  - Starting key exchange
600168 [Transport protocol 2] INFO com.sshtools.j2ssh.transport.kex.DhGroup1Sha1  - Starting client side key exchange.
600560 [Transport protocol 2] INFO com.sshtools.j2ssh.transport.HostKeyVerification  - Verifying myhost,my.hst.ip.add host key
600562 [Transport protocol 2] INFO com.sshtools.j2ssh.transport.TransportProtocolCommon  - The host key signature is  valid
600562 [Transport protocol 2] INFO com.sshtools.j2ssh.transport.TransportProtocolCommon  - Completing key exchange
600564 [Transport protocol 2] INFO com.sshtools.j2ssh.transport.cipher.SshCipherFactory  - Creating new blowfish-cbc cipher instance
600566 [Transport protocol 2] INFO com.sshtools.j2ssh.transport.cipher.SshCipherFactory  - Creating new blowfish-cbc cipher instance
600797 [Background] INFO ch.cyberduck.core.Session  - SSH connection opened
600798 [Background] INFO ch.cyberduck.core.Session  - Authenticating as 'ibrandt'
600798 [Background] INFO ch.cyberduck.core.sftp.SFTPSession  - Trying Password authentication...
600899 [Background] INFO ch.cyberduck.core.sftp.SFTPSession  - Trying Keyboard Interactive (PAM) authentication...
600992 [Background] INFO ch.cyberduck.core.Session  - Login failed
618326 [main] INFO ch.cyberduck.ui.cocoa.CDWindowController  - Cancel login...
618501 [Background] INFO ch.cyberduck.core.Session  - Disconnecting…
618502 [Background] INFO com.sshtools.j2ssh.connection.ConnectionProtocol  - Closing all active channels
618503 [Background] INFO ch.cyberduck.core.Session  - Disconnected
618508 [Transport protocol 2] INFO com.sshtools.j2ssh.transport.TransportProtocolCommon  - The Transport Protocol has been stopped

Change History (6)

comment:1 Changed on Feb 4, 2007 at 8:54:51 AM by dkocher

Looking at the look it does indeed not even attempt to use Public Key Authentication as otherwise there would be a line saying Trying Public Key authentication.... However, I have just tested this many times selecting keys from different locations on my system and I am unable to see this problem here. Make sure the 'Use Public Key Authentication' is really checked and maybe try creating a bookmark instead and entering the connection settings there.

comment:2 Changed on Feb 4, 2007 at 9:58:38 PM by ibrandt

  • Severity changed from major to normal

If I create it as a bookmark and connect via that it works. Still no luck from the standard connect dialog however.

I am definitely checking off the 'Use Public Key Authentication' option. As confirmation after choosing it and selecting my private key the path to the key is displayed as a text field. I've just tried making the selection of the option the first thing I enter into the dialog (it was the last thing I was doing) in hopes that entering a value after it ('Server' for example) would encourage the selection to "take", but it made no difference.

I've got the trunk up and running in Xcode with the debugger attached. I can reproduce the issue. Aside from a Hello World tutorial I did over a year ago I'm totally green with Xcode and native Mac apps. I do know Java well, and I have academic knowledge of Objective-C, so I might be able to root out the problem. If you could recommend any particular breakpoints to start from that would speed things up a lot on my end.

Lowering the severity to normal as there is now a known workaround.

comment:3 Changed on Feb 5, 2007 at 6:43:08 AM by dkocher

  • Milestone set to 2.7.3
  • Status changed from new to assigned

Thanks for your additional comment. I think I have narrowed down the problem that you must be running a localized version of Cyberduck. There is an assumption in the code that two (identical) strings are translated the same in two different places which may not be the case.

comment:4 Changed on Feb 5, 2007 at 7:09:58 AM by ibrandt

Interesting as I think I just found the issue, but it doesn't appear related to localization:

CDConnectionController line ​608 calls: 

host.getCredentials().setPrivateKeyFile(pkLabel.stringValue());

but then ​641 calls: 

host.setCredentials(usernameField.stringValue(), passField.stringValue(), keychainCheckbox.state() == NSCell.OnState);

which in turn in Host ​454 does: 

this.setCredentials(new Login(this.getHostname(), this.getProtocol(), username, password, addToKeychain));

The "new Login" there loses the existing Login.privateKeyFile value.

When we get to SFTPSession line ​286 the call to host.getCredentials().usesPublicKeyAuthentication() returns false on account of the null privateKeyFile value, and public key authentication is not attempted.

I couldn't get Xcode to stop at my breakpoints, so this analysis is based on a quick reading of the code and compiling in a few debug statements. I very well may have erred, or perhaps this chain of events is only triggered for certain locales?

comment:5 Changed on Feb 6, 2007 at 4:34:39 PM by dkocher

  • Resolution set to fixed
  • Status changed from assigned to closed

Thanks for spotting the bug. To debug Cyberduck, run the debug.sh script and connect using the Java Remote Debugger eg. from inside the IntelliJ IDEA IDE. Within XCode, it is not possible to debug Cyberduck.

Fixed in r2818.

Note: See TracTickets for help on using tickets.