Cyberduck Mountain Duck CLI

#398 closed defect (worksforme)

Cannot connect with SSH public key authentication ("Can't read key due to internal IO problems")

Reported by: Owned by: dkocher
Priority: low Milestone: 2.8
Component: sftp Version: 2.5.5
Severity: minor Keywords:
Cc: Architecture:


Whilst trying to use SSH public key authentication to connect to a server, the following error is returned from Cyberduck:

IO Error: Can't read key due to internal IO problems: Assertion failed, next byte value is f8 instead of asserted 30

Cyberduck is able to connect normally (over SFTP) if password authentication is used instead of public key authentication.

Private key is in format of


and is correctly selected inside my Cyberduck bookmark for the site to which I am attempt to connect.

I would much prefer to connect via public key authentication (especially if Cyberduck support ssh-agent key forwarding!, but that's an enhancement, not a defect) but as of yet have been unable to connect via SFTP except with password authentication.

Change History (14)

comment:1 Changed on May 12, 2006 at 10:32:42 PM by

  • Priority changed from high to low
  • Severity changed from major to minor

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.

comment:2 Changed on May 12, 2006 at 11:26:57 PM by dkocher

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.

comment:3 Changed on May 12, 2006 at 11:41:23 PM by dkocher

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 #75.

comment:4 Changed on May 13, 2006 at 2:53:55 AM by anonymous

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 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?

comment:5 Changed on May 14, 2006 at 12:04:34 AM by dkocher

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

comment:6 Changed on May 14, 2006 at 5:51:57 PM by bshalsey (at) paxoo

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 #75!), I'd say this is a very minor issue and would, in fact, be inclined to assign the problem to SSH Agent.

comment:7 Changed on Jun 2, 2006 at 2:45:42 AM by gcat

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: 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.

comment:8 Changed on Jun 14, 2006 at 2:54:34 AM by gcat

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.

comment:9 Changed on Jun 15, 2006 at 1:15:25 AM by

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

comment:10 Changed on Aug 9, 2006 at 12:03:16 PM by

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.

comment:11 Changed on Oct 30, 2006 at 3:52:36 PM by nigelm

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.

comment:12 Changed on Feb 16, 2007 at 2:59:28 PM by dkocher

Pleaes check against build 2844 from

comment:13 Changed on May 17, 2007 at 12:11:16 PM by dkocher

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

comment:14 Changed on May 19, 2007 at 12:03:06 PM by dkocher

  • Resolution set to worksforme
  • Status changed from assigned to closed
Note: See TracTickets for help on using tickets.