No announcement yet.

can't connect to aws ec2 w/sftp private key

  • Filter
  • Time
  • Show
Clear All
new posts

  • can't connect to aws ec2 w/sftp private key

    I'm having trouble connecting to AWS EC2 instance using BC. As far as I can tell settings are correct and match what I have for CyberDuck, which connects successfully.

    This is what I see in log window:

    8/6/19 10:55:02 AM Connecting to aws
    8/6/19 10:55:02 AM Server key [RSA 2048 d5:8b:1e:e2:6e:ca:c6:6b:d7:a2:14:9c:5b:64:20:d0]
    8/6/19 10:55:02 AM Public key agent authorization failed.
    8/6/19 10:55:02 AM No more authentication methods available
    8/6/19 10:55:02 AM Connection failed: Connection lost (error code is 10058)


  • #2
    OK, it turns out that BC wants the private key added to ssh-agent:

    eval `ssh-agent`
    ssh-add <private key file>
    Then all is well. For whatever reason, Cyberduck doesn't require this.


    • #3

      Cyberduck is likely looking for a default location for the key to load. Where is your key in your %UserProfile%?
      Aaron P Scooter Software


      • #4
        No %UserProfile% -- I'm on mac.

        Cyberduck lets you specify the private key file. BC does too, but for some reason that's not enough -- it also needs key added to ssh-agent.


        • #5

          Sorry, which Profile type are you using in BC4? Is this an Amazon S3 profile that can also use a public/private key pair, or an SFTP Profile with a public/private key authorization?

          I was previously assuming it was using the Amazon S3 profile type (both S3 keys and ssh used for authorization), but re-reading, this is primarily an SFTP profile, correct?

          How was your key generated and what format is the key pair in? RSA? It looks like it is in a format that BC4 does not support (fails in the above log) while it works with ssh-agent, which BC4 can then hook into and use.
          Aaron P Scooter Software


          • #6
            plain old sftp

            key generated w/ssh-keygen on mac, 2048 bit RSA


            • #7
              Well, I thought everything was OK with ssh-agent, but all of a sudden (?) that's not working either.

              Granted that I'm an ssh noob, but I have managed to get in to aws via ssh login, and I've got Cyberduck working, so things aren't a total mess.

              But I just can't seem to get BC to connect, which for me is like trying to code with both hands tied behind my back ;-)

              Any hints, tips, etc. would be much appreciated -- thanks!


              • #8
                So I asked BC to generate the keys for me, and that seems to work once I paste the file into authorized_keys on aws.

                I'm guessing one or both of:

                - BC doesn't like the key files generated by recent ssh-keygen (i.e., non-PEM format)
                - BC doesn't like key files that don't have a passphrase. (I included a passphrase when asking BC to generate key files).


                • #9
                  I investigated this issue and found that Beyond Compare 4.3.3 (current) is not compatible with OpenSSH format private keys that are the default for OpenSSH 7.8 or newer.

                  The new format (incompatible) keys begin and end with:
                  -----BEGIN OPENSSH PRIVATE KEY-----
                  -----END OPENSSH PRIVATE KEY-----

                  Older style keys compatible with Beyond Compare begin and end with:
                  -----BEGIN RSA PRIVATE KEY-----
                  -----END RSA PRIVATE KEY-----

                  To force creation of Beyond Compare compatible keys when using OpenSSH 7.8 or newer, use the command:
                  ssh-keygen -m PEM -t rsa
                  To convert a new format key to a key that's compatible with Beyond Compare on Linux or macOS, run the commands:
                  cp ~/.ssh/id_rsa ~/.ssh/id_rsa.bc
                  ssh-keygen -p -m PEM -f ~/.ssh/id_rsa.bc
                  To convert a new format key to a key that's compatible with Beyond Compare on Windows, use PuTTYGen to save the key as a PuTTY .ppk file.
                  Chris K Scooter Software


                  • #10
                    Thanks Chris -- any plans to support the new format?


                    Note: Previously, the private key password was encoded in an insecure way: only a single round of an MD5 hash. OpenSSH 6.5 and later support a new, more secure format to encode your private key. This format is the default since OpenSSH version 7.8. Ed25519 keys have always used the new encoding format. To upgrade to the new format, simply change the key's passphrase, as described in the next section.


                    • #11
                      Support for the new key format is on our todo list, it doesn't have a set release date right now.
                      Chris K Scooter Software