Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Lookup of password for private key fails in Keychain #5148

Closed
cyberduck opened this issue Sep 7, 2010 · 21 comments
Closed

Lookup of password for private key fails in Keychain #5148

cyberduck opened this issue Sep 7, 2010 · 21 comments
Assignees
Labels
bug fixed sftp SFTP Protocol Implementation
Milestone

Comments

@cyberduck
Copy link
Collaborator

ee19048 created the issue

I just updated from 3.5.1 to 3.6.1
I connect to all of my servers via SFTP and key authentication (passwords are disabled on the server). My private key has no password, and never did.
As soon as I updated to 3.6.1, Cyberduck started to ask me for my private key password. Clicking the default button leaving the password empty does not solve the issue. I rechecked in Terminal and my key is still unprotected by passwords, and I can log into my servers via ssh.


Attachments

@cyberduck
Copy link
Collaborator Author

3d69275 commented

I can also confirm this issue, with same diagnosis after upgrade to 3.6.1 from 3.5.1.

Mac OS X 10.6.4. Command line SFTP to the same servers still remains functional.

Please advise if additional information required; I'll be reverting to 3.5.1 in interim.

@cyberduck
Copy link
Collaborator Author

@dkocher commented

I cannot yet replicate the issue. Do you have a username set in the bookmark setting? As of 9bbc7bd the login prompt can be dismissed without a password entered when using public key authentication.

@cyberduck
Copy link
Collaborator Author

3d69275 commented

Replying to [comment:5 dkocher]:

I cannot yet replicate the issue. Do you have a username set in the bookmark setting? As of 9bbc7bd the login prompt can be dismissed without a password entered when using public key authentication.

"Username set in the bookmark?" Absolutely - otherwise it'd be difficult for the remote machine to know where to look for the public key [generally in ~username/.ssh/authorized_keys].

I'm gonna be occupied for the next few hours, but I'll endeavour to pull down the trunk and build it to see if 9bbc7bd behaves correctly.

@cyberduck
Copy link
Collaborator Author

a6bf8be commented

I can confirm this issue. Just updated and can't login to my servers anymore.
I have attached two screenshots to show the problem (jan_dialog and jan_settings)

@cyberduck
Copy link
Collaborator Author

ee19048 commented

I can tell you that I feel the bug when connecting to a Mac OS X Server box, a Debian Linux and a CentOS, so it does not seem to depend on the serverside OS.
The bug is there when I connect from a bookmark and also when I type the address and credentials from scratch in the "New connection" box.
It makes no difference whether the username is identical to my local username or a different one (I tried root).

@cyberduck
Copy link
Collaborator Author

ee19048 commented

I don't know if this helps, probably not, but this is what ends up in my Console

08/09/10 14.12.34	[0x0-0x4b04b].ch.sudo.cyberduck[766]	2010-09-08 14:12:34,741 [main] ERROR ch.cyberduck.core.sftp.SFTPSession - Connection attempt canceled
08/09/10 14.13.17	Cyberduck[766]	Could not find image named 'login'.

@cyberduck
Copy link
Collaborator Author

a6bf8be commented

I have downgraded to 3.5.1 now which you can find on Apples software page

http://apple.com/downloads/macosx/internet_utilities/cyberduck.html

@cyberduck
Copy link
Collaborator Author

@dkocher commented

Replying to [comment:10 https://www.google.com/accounts/o8/id?id=aitoawmq5en6knjocnovu6ny_jf5ezv90ugs26w]:

I have downgraded to 3.5.1 now which you can find on Apples software page

http://apple.com/downloads/macosx/internet_utilities/cyberduck.html

Previous releases are always available at http://cyberduck.ch/changelog/

@cyberduck
Copy link
Collaborator Author

@dkocher commented

Can you confirm that in your private key at the beginning there is no such thing as Proc-Type: 4,ENCRYPTED.

@cyberduck
Copy link
Collaborator Author

a6bf8be commented

There is:

-----BEGIN DSA PRIVATE KEY-----
Proc-Type: 4,ENCRYPTED
DEK-Info: DES-EDE3-CBC,2E47CAC88030866B

...

@cyberduck
Copy link
Collaborator Author

@dkocher commented

Replying to [comment:13 https://www.google.com/accounts/o8/id?id=aitoawmq5en6knjocnovu6ny_jf5ezv90ugs26w]:

There is:

-----BEGIN DSA PRIVATE KEY-----
Proc-Type: 4,ENCRYPTED
DEK-Info: DES-EDE3-CBC,2E47CAC88030866B

...

From what I know this means your private key is password protected.

@cyberduck
Copy link
Collaborator Author

@dkocher commented

The issue is that our lookup for the password of the private key in the keychain fails. (We previously looke for the password in the keychain with the abreviated filename of the private key (such as ~/.ssh/id_dsa) to be compatible with SSHKeychain.

@cyberduck
Copy link
Collaborator Author

@dkocher commented

In aa6704d.

@cyberduck
Copy link
Collaborator Author

3d69275 commented

There appears to be a regression in build 7035 that leads to this bug once again rearing its unfortunate head.

Have reverted back to build 7015, as the problem doesn't exist in that nightly build.

@cyberduck
Copy link
Collaborator Author

@dkocher commented

Replying to [comment:18 http://theonlycueball.myopenid.com/]:

There appears to be a regression in build 7035 that leads to this bug once again rearing its unfortunate head.

Have reverted back to build 7015, as the problem doesn't exist in that nightly build.

Decided to break backward compatibility with SSHKeychain in 570c9c0. You have to reenter the SSH private key password.

@cyberduck
Copy link
Collaborator Author

@dkocher commented

Backward compatiblity in 22f28c7.

@cyberduck
Copy link
Collaborator Author

Cueball commented

After I encountered this bug again some time ago, I stopped updating nightly builds again and stuck with build 8001 [which works for me.]

Since it was deemed "fixed", I really wasn't about the belabour the point again in case there was just something hinky with my config. Apparently I'm not the only one seeing this problem still...

Perhaps a unit test for this case to avoid the issue in future? :-)

@cyberduck
Copy link
Collaborator Author

76be774 commented

Decided to break backward compatibility with SSHKeychain in 570c9c0

Cyberduck (tried 4.1 (8911)) should still IMHO be finding the password for my private key in Keychain.

In OS X 10.6 Snow Leopard at least, when you open an SSH connection through the Terminal with the ssh command with a server that has your public key, you are asked with a secure Cocoa dialog (not prompt) to "Enter your password for the SSH Key 'id_rsa'." (if that is the name where your private key resides), with the option to "Save password in Keychain". If one ticks that, on a subsequent connection ssh-agent will ask to have access to the keychain where the password for the private key resides in order to be able to open the connection with that private key without prompting for its password.

In other words, OS X does have a method for storing and reading the password for private keys in the Keychain without any need of third party software such as SSHKeychain.

It would be nice if Cyberduck detected OS X-saved password to my private key in the Keychain, and asked me for access to it, instead of asking the password to my private key (just as a note, Transmit 4 does).

@cyberduck
Copy link
Collaborator Author

@dkocher commented

Replying to [comment:24 elmimmo]:

Decided to break backward compatibility with SSHKeychain in 570c9c0

Cyberduck (tried 4.1 (8911)) should still IMHO be finding the password for my private key in Keychain.

In OS X 10.6 Snow Leopard at least, when you open an SSH connection through the Terminal with the ssh command with a server that has your public key, you are asked with a secure Cocoa dialog (not prompt) to "Enter your password for the SSH Key 'id_rsa'." (if that is the name where your private key resides), with the option to "Save password in Keychain". If one ticks that, on a subsequent connection ssh-agent will ask to have access to the keychain where the password for the private key resides in order to be able to open the connection with that private key without prompting for its password.

In other words, OS X does have a method for storing and reading the password for private keys in the Keychain without any need of third party software such as SSHKeychain.

It would be nice if Cyberduck detected OS X-saved password to my private key in the Keychain, and asked me for access to it, instead of asking the password to my private key (just as a note, Transmit 4 does).

Great suggestion. We should try to be interoperable with Terminal.app here.

@cyberduck
Copy link
Collaborator Author

@dkocher commented

Replying to [comment:25 dkocher]:

Replying to [comment:24 elmimmo]:

Decided to break backward compatibility with SSHKeychain in 570c9c0

Cyberduck (tried 4.1 (8911)) should still IMHO be finding the password for my private key in Keychain.

In OS X 10.6 Snow Leopard at least, when you open an SSH connection through the Terminal with the ssh command with a server that has your public key, you are asked with a secure Cocoa dialog (not prompt) to "Enter your password for the SSH Key 'id_rsa'." (if that is the name where your private key resides), with the option to "Save password in Keychain". If one ticks that, on a subsequent connection ssh-agent will ask to have access to the keychain where the password for the private key resides in order to be able to open the connection with that private key without prompting for its password.

In other words, OS X does have a method for storing and reading the password for private keys in the Keychain without any need of third party software such as SSHKeychain.

It would be nice if Cyberduck detected OS X-saved password to my private key in the Keychain, and asked me for access to it, instead of asking the password to my private key (just as a note, Transmit 4 does).

Great suggestion. We should try to be interoperable with Terminal.app here.

OpenSSH interoperability in 51d514d.

@cyberduck
Copy link
Collaborator Author

76be774 commented

How does 51d514d work? I downloaded the nightly Cyberduck-9393 but I am still asked to specify a private key file, and even if manually specified, Keychain access never asks me to unlock the keychain where the password to my private key resides.

@iterate-ch iterate-ch locked as resolved and limited conversation to collaborators Nov 26, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
bug fixed sftp SFTP Protocol Implementation
Projects
None yet
Development

No branches or pull requests

2 participants