Cyberduck Mountain Duck CLI

#11164 closed defect (fixed)

.pem key fails for SFTP to AWS EC2 with 'Exhausted available authentication methods.'

Reported by: mrkrsl Owned by: jmalek
Priority: normal Milestone:
Component: core Version: 7.5.1
Severity: normal Keywords:
Cc: Architecture: Intel



Cyberduck no longer allows me to SFTP into my AWS EC2 instance using a standard .pem key created from the AWS dashboard. The same setup and .pem key file worked without issue in previous versions of Cyberduck.

Login now consistently fails with the following error:

Login failed. Exhausted available authentication methods. Could not read key pair from: [PrivateKeyReaderResource]

The .pem key in question is valid/working. I can successfully log into the instance using SSH/SFTP on the command line with this exact key:

sftp -i "/users/mark/.ssh/aws.pem" [user]@[IP]

The key resides in the default ~/.ssh directory.

Here's my Cyberduck connection setup:

Server: [IP]

Username: [user]

Password: [blank]

SSH Private Key: ~/.ssh/aws.pem

I'm using Cyberduck 7.5.1 (33324) on Mac OS X 10.15.6, currently putting individual files up manually in Terminal! Any help looking into this much appreciated.

Change History (7)

comment:1 Changed on Sep 9, 2020 at 11:52:39 AM by jmalek

  • Owner set to jmalek
  • Status changed from new to assigned

Can you let me know which SSH key type the AWS pem file is?

comment:2 Changed on Sep 9, 2020 at 2:03:02 PM by mrkrsl

I believe it's a 2048-bit SSH-2 RSA key, but I'm going by the AWS documentation. The key itself is prefixed -----BEGIN RSA PRIVATE KEY----- and suffixed -----END RSA PRIVATE KEY-----.

comment:3 Changed on Sep 9, 2020 at 3:40:23 PM by jmalek

I just checked with following commands: ssh-keygen -b 2048 -t rsa -f test.pem This creates a file with the BEGIN RSA PRIVATE KEY and END RSA PRIVATE KEY-sections, copied the .pub-file to the SSH server and tried using this key to authenticate to my test server.

I checked following file formats:

  • regular ssh-keygen RSA PEM format
  • PuTTy RSA SHA2 2048 Bit
    • Key file
    • exported as OpenSSH PEM
    • exported as OpenSSH new format PEM

Works just fine with this format. Can you send us the log output? Provide log output

comment:4 Changed on Sep 9, 2020 at 9:08:32 PM by mrkrsl

As per the log output guide I have 0 Subsystem logs for ch.sudo.cyberduck with Debugging and Info messages on in

There are plenty of others though if you can direct me to anything in particular. Nothing leaps out at me for being suspicious when I review the logs I have.

comment:5 Changed on Sep 17, 2020 at 8:42:36 AM by mrkrsl

Is there any update on this issue, which remains a blocking issue to use of Cyberduck?

I have a feeling that the test .pem file would need to be one from the AWS service. (Not one generated locally for test.) I can provide a dummy AWS .pem key for test if required.

comment:6 Changed on Sep 17, 2020 at 10:06:04 AM by jmalek

Didn't have any chance to check that again yet. For the logging: You did enable logging=debug through defaults write ch.sudo.cyberduck logging debug? Otherwise very few messages will be written to the system log.

A dummy key which does show this issue would be highly appreciated. By any chance: Which server operating system and SSH server is in use, so we can recreate a matching system here?

comment:7 Changed on Sep 25, 2020 at 2:02:02 PM by mrkrsl

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

Hi, I apologise for taking a little time to get back to this issue. I believe I have actually solved it by generating a brand new .pem key in the AWS console and associating that with the EC2 instance in /home/ec2-user/.ssh/authorized_keys and then using that one with Cyberduck.

I can now both ssh into the instance and use the new key in Cyberduck without issue.

On inspecting the keys themselves I notice that the formatting is different between the original and new keys. The block length is shorter in the older key.

Thank you for investigating.

Note: See TracTickets for help on using tickets.