No announcement yet.

BC Suddenly Asking for SSH Private Key Passphrase

  • Filter
  • Time
  • Show
Clear All
new posts

  • BC Suddenly Asking for SSH Private Key Passphrase

    Hello... For the last couple weeks, I've had a BC setup in place consisting of four sessions that all use an SSH connection to another machine, within a local network. It all ran very well for a week.

    Then suddenly BC started asking for a passphrase when I try to open any of these sessions (within the GUI). This doesn't make sense to me because:
    * I remember choosing to skip the passphrase when I created the keys
    * BC didn't ask me for a passphrase on these sessions, until now
    * I can still, even now, SSH between these machines without having to enter a passphrase.

    I don't remember changing anything in BC or SSH configurations at all; let alone something that might've caused this. I suppose it could be somewhere in my SSH setup, but that last bullet above makes me suspect BC. Is there something in BC that could explain this?

    My last option is to try re-doing the SSH keys, but even if that works, it will leave me without an explanation, and the problem could happen again.

  • #2
    Beyond Compare 4.4.1 was released on December 20th. In case a software update caused the passphrase issue, please try downgrading to version 4.4.0 and let us know if that resolves the problem.

    I emailed download links for version 4.4.0 and 4.3.7 to your forum email address.

    Chris K Scooter Software


    • #3
      Yes -- that solved it. I'd initially installed v4.4.0 (a few weeks ago). What was installed on the machine now was v4.4.1. I now reinstalled from the original v4.4.0 *.deb file -- problem gone.

      Thanks. I'm guessing this will be fixed in the next rev, but I'll verify before I approve the next upgrade push.


      • #4
        1. What Linux distribution did you create the key on (Ubuntu 20.04, CentOS 7, etc)?
        2. Did you use default key creation settings (ssh-keygen -f ~/.ssh/id_rsa) or did you use additional arguments?
        3. On the computer running Beyond Compare, is the private key ~/.ssh/id_rsa, or an alternate filename?
        Chris K Scooter Software


        • #5
          This was Ubuntu 21.04.

          The notes I took during creation of several different machines at that time, including this one, say: "ssh-keygen -t rsa -b 4096". I can't guarantee that's what was used to create this particular key, but it may have been.

          If it wasn't that, then I can at least say it wouldn't have been anything fancy. I would've been operating from someone's online basic tutorial.

          Yes -- the location and file are the defaults you gave.


          • #6
            Thank you, I tried creating a key using the method you described on Ubuntu 21.04, but I haven't been able to duplicate the problem.

            1) To double check your key type, use the command:
            ssh-keygen -l -f ~/.ssh/
            4096 SHA256:XJlmPUN1Z94Zh6eQOijYjEE1Z0oKqt7p3XYze6CHwc4 [email protected] (RSA)
            2) If an SFTP profile doesn't have a private key defined, the Linux version of Beyond Compare automatically tries ~/.ssh/id_rsa for authentication. Do you have the private key filename path defined in Tools > Profiles, or is it blank?

            3) Is the SFTP server also running Ubuntu 21.04, or is it some other operating system?
            Chris K Scooter Software


            • #7
              1) Executing the line you gave, produces the following (with 'username' and 'hostname' redacted):
              4096 SHA256:efybBuZRXcY8vv46AGwxM8yHTzZzCtfto3fgDGKW1zk [email protected] (RSA)

              2) It does have a path/file defined in the text box, but it's the default: /home/username/.ssh/id_rsa. (Bear in mind I'm now extracting this information from v4.4.0)

              3) The server is running Linux Mint 20.2, which is based on Ubuntu 20.04.

              If it will make the difference in reproducing, I'm willing to send you the keyfile offline, and I'll generate new ones. Let me know if it gets to that point.

              I can also upgrade back to v4.4.1, if needed, if it gets us more direct debug info.


              • #8

                Could you bundle up your key pair and email the text files into [email protected] along with a link back to this forum thread (for our reference)? Thanks!
                Aaron P Scooter Software


                • #9
                  Copying the response I sent to vance via email:

                  This is a bug that was introduced in BC 4.4.1, but it's different than what we first thought.

                  The private key id_rsa you provided has a passphrase on it.

                  ssh-keygen -p is used to update the passphrase on a key. If there isn't an existing passphrase on a key, it prompts for the new key. If there is a passphrase on a key, it first prompts for the old passphrase before asking for the new passphrase. Running the command on the key you provided gives the following, indicating it has a passprase:

                  [email protected]:~$ ssh-keygen -p -f id_rsa
                  Enter old passphrase:

                  The bug introduced in BC 4.4.1 isn't that it prompts for a passphrase when a key doesn't have a passphrase set, it's that if the passphrase is saved by the system, it doesn't use that saved passphrase and prompts instead.

                  As an example, on Ubuntu 20.04, the first time you SSH to a system in terminal using a private key with a passphrase, it shows the following prompt:

                  Ubuntu passphrase save dialog

                  After you save the key, Beyond Compare 4.4.0 automatically uses the saved passphrase for the SFTP server.

                  Beyond Compare 4.4.1 prompts for a passphrase rather than using the passphrase saved by the system.

                  I'll add this to our bug list to be fixed.
                  Chris K Scooter Software


                  • #10
                    After more investigation and discussion with our lead developer, it turns out this isn't a bug in BC 4.4.1, but a bug/limitation of older versions of BC, such as 4.4.0 or 4.3.7.

                    Beyond Compare can provide key authentication via a file or via ssh-agent. File authentication is attempted first, ssh-agent is attempted if that fails.

                    In your scenario:

                    SSH private key with passphrase in ~/.ssh/id_rsa using the newer OpenSSH private key file format. This format is not supported in BC 4.3.7, and support was buggy in 4.4.0.
                    SSH private key saved in ssh-agent by filling in the "Enter password to unlock the private key" prompt from screenshot in my previous post.

                    Using BC 4.4.0 or 4.3.7 Linux load an SFTP profile with "SSH private key file" field blank.
                    BC tries private key in ~/.ssh/id_rsa because path is not specified.
                    Loading the key from file fails.
                    Authentication via ssh-agent is tried next, it has the passphrase saved so there is no prompt.

                    BC 4.4.1 Linux, load an SFTP profile with "SSH private key file" field blank.
                    BC tries private key in ~/.ssh/id_rsa because path is not specified.
                    BC prompts for passphrase.
                    Chris K Scooter Software


                    • #11
                      I've made an entry in our internal feature request list to give ssh-agent priority over the private key file. That would have avoided the passphrase prompt in your scenario.
                      Chris K Scooter Software


                      • #12
                        OK. I don't know how that could've happened. You mentioned the idea that the system can save a passphrase -- that seems like a feature that would compromise security, but maybe I did that months ago and don't remember it, and that's why it never prompted me.

                        In any case, having generated a new key, I'm up and running with v4.4.2, and I don't see the passphrase request anymore. Many thanks for your time and attention for what turned out to be user error.