a640b0e commented

I generated a new keypair, which worked within Cyberduck. The problem, it seems, is with the extraneous tags that were included in the private key file. The Proc-Type and DEK-Info tags, which are actually defined in RFC1421, seem to be giving Cyberduck some parsing problems.

SSH Agent, a utility I use to manage my key forwarding, added these encapsulated headers to my private keys whenever I put them under its control. I've lowered the priority and severity of this bug, but Cyberduck should, to play nicely with other software, simply skip over these headers whilst parsing the private key.

@dkocher commented

Thanks for the detailed bug report. I can reproduce this with one key of my own but have not yet found the reason for the failure. You should be able to work around this by creating another key pair.

@dkocher commented

Thanks for the follow up. The Proc-Type and DEK-Info should not pose any problems and I don't think this is the actual reason for the failure - I have SSH keys here with these headers included that work.

SSH Agent support is in #12024.

anonymous commented

Not sure what would be causing the problem, then. Here's how I narrowed it down:

1. Generate new keypair with ssh-keygen -t rsa and saved it as ~/.ssh/id_rsa[.pub]
2. scp id_rsa.pub remote_host:/.ssh/authorized_keys
3. (In Cyberduck) Changed bookmark to use public key authorization and selected id_rsa as private key.
4. Connected to remote_host successfully, browsed, then disconnected.
5. cat id_rsa did not show Proc-Type and DEK-Info.
6. Open SSH Agent and activate id_rsa key.
7. cat id_rsa did show Proc-Type and DEK-Info encapsulated headers.
8. Attempted step 4 again, connecting to remote_host via Cyberduck; received the same "internal IO problem" message.
   8a. This problem occurs whether SSH Agent is running or not.

Repeating the process above, but setting mode to a-w before activating the public key in SSH Agent will allow Cyberduck and SSH Agent to play nicely together. It's quite possible (probable, perhaps) that the problem actually lies with SSH Agent, but since it does handle forwarding correctly for other apps (including command-line ssh), who knows?

@dkocher commented

Seems to me this exception is triggered when a wrong password for the key is entered. Can you confirm this?

bshalsey (at) paxoo commented

That exception does occur when an incorrect password is entered. However, my particular problem is a little more complicated.

When I try to use my original key (I'll call it tonks-1 from now on), it doesn't even ask for my password, even though I entered one when I generated the key.

The problem might be the cause, as I speculated earlier, of SSH Agent instead. The original key I used, tonks-1, which causes this problem was generated inside SSH Agent instead of using the CLI ssh-keygen utility, which also perhaps explains why the Proc-Type and DEK-Info headers show up inside the key.

Since Cyberduck seems to work well with other keys and you have other more important defects and enhancements to work on (I'm really looking forward to that key forwarding enhancement in #12024!), I'd say this is a very minor issue and would, in fact, be inclined to assign the problem to SSH Agent.

gcat commented

I have three Tiger machines with the same cofiguration,
copied from 1 below to others using scp (-r) command.

1: PowerMac G4 (in my home)
2: PowerMac G5 (in my office)
3: PowerBook G4 12 inch

I mean I have exactly the same ssh keys under ~/.ssh/,
the same version of SSH Agent, the same preferences
for cyberduck and the same cyberducks as well.

While I'm quite confortable with using cyberduck on 1,
I'm receiving the following errors on 2 and 3.

IO Error: Can't read key due to internal IO problems: java.io.IOException: Assertion failed, next byte value is 48 instead of asserted 30 (not f8 but 48)

I have tried to use fugu and fetch also. Though they
work perfectly, I prefer to use cyberduck...

I don't understand what is happening.

gcat commented

Thanks, it's solved in version 2.6.

Apparently, this bug dissapeared by distinguishing password and passphrase in cyberduck of version 2.6.

For machines 2 and 3, I tested the connection by using password first.
Though for machine 1, I just tried the SSH with passphrase.
The old versions of cyberduck just stored them in keychain as pasword which must be identified with passphrase, I suppose.

Thanks again.

a640b0e commented

I concur! The 2.6 release has fixed this problem and I feel confident enough to call it resolved.

bd86071 commented

I'm afraid I have the problem now, with version 2.6. I did not experience this with earlier versions :(
Manual login with shell works ok - guess my key is ok.

4286ede commented

I am seeing this problem with version 2.6.2.

I suspect (OK guess) it is related to SSHKeyChain having the file open since if
I copy the ssh key file and give that file to CyberDuck then (after
asking me the key password) it works quite happily. I have a couple
of shells open using ssh on that key and a tunnel defined again on that
key at present.

@dkocher commented

Pleaes check against build 2844 from http://update.cyberduck.ch/nightly/