Signing back into the Community for the first time? You'll need to reset your password to access your account.  Find out more.

Forum Discussion

tonkku107's avatar
tonkku107
Occasional Contributor
3 years ago

[I-19] SSH key priority option?

I currently have 2 personal SSH keys, one RSA and one Ed25519 and am in the process of moving from the RSA key to the Ed key. Previously, I used to have the Ed key defined first in the ssh config via IdentifyFile but based on the output of the PolicyKit window, 1Password is using the RSA key first. Would an option to order keys in order of preference be possible?


1Password Version: Not Provided
Extension Version: Not Provided
OS Version: Not Provided

  • Lachy's avatar
    Lachy
    Occasional Contributor

    I also need support for IdentityFile, or at least an alternative solution. With ssh-agent, it's the only way I've found to have both work and personal accounts on Bitbucket that require distinct private keys. My ~/.ssh/config file is full of configs to know which keys are preferred on which hosts.

    For example:

    ```
    Host bitbucket.org
    IdentityFile ~/.ssh/id_ed25519 # Used for Work account

    Host personal.bitbucket.org
    HostName bitbucket.org
    User git
    IdentityFile ~/.ssh/id_ecdsa # Used for Personal account
    ```

    This has also helped me keep track of which public keys are with which services, because not everything supported Ed25519 when I set up the keys.

  • Lachy's avatar
    Lachy
    Occasional Contributor

    That works. But since it doesn't support ECDSA, I generated an alternate Ed25519 key and used:


    Host personal.bitbucket.org
    HostName bitbucket.org
    User git
    IdentityAgent ~/.1password/agent.sock
    IdentityFile ~/.ssh/id_ed25519-alternate.pub

    Now I only have one remaining service using that ECDSA key because they still don't support Ed25519.

  • tonkku107's avatar
    tonkku107
    Occasional Contributor

    Despite setting up an IdentityFile with a public key instead of a private one, 1Password is still unlocking the RSA key first.

  • floris_1P's avatar
    floris_1P
    Icon for 1Password Team rank1Password Team

    Are you SSH'ing from the terminal or if not, what SSH client are you using?

  • floris_1P's avatar
    floris_1P
    Icon for 1Password Team rank1Password Team

    Could you share (the relevant bits of) your SSH config and SSH_AUTH_SOCK=~/.1password/agent.sock ssh-add -l output?

  • tonkku107's avatar
    tonkku107
    Occasional Contributor

    SSH config:
    ```
    IdentityFile ~/.ssh/id_ed25519.pub
    IdentityFile ~/.ssh/id_rsa.pub

    Host *
    IdentityAgent ~/.1password/agent.sock

    Host aur.archlinux.org
    IdentityFile ~/.ssh/aur.pub
    User aur

    [repeating below for different servers]
    Host [server-alias]
    HostName [ip address]
    User [username]


    4096 SHA256:Gu0EFgYpwVbLsqX5nDEL5V1jUfryMTe7FR8AUUsg4+E (RSA)
    256 SHA256:WdVfgHlD0C2HEq9y60mYiah/4lY8xhitK1wY1pvYKjk (ED25519)
    3072 SHA256:S9scRLenmjLjv4srb9n5dIkYu9MM2ihZDXVbLxW4KNg (RSA)
    ```

    For that host specific AUR configuration, it works perfectly and unlocks the aur key first.
    The global configuration doesn't work and just uses the RSA key first anyway.

  • floris_1P's avatar
    floris_1P
    Icon for 1Password Team rank1Password Team

    I'm guessing that that's because you've specified multiple keys as IdentityFile. If you want control over which key is used, your SSH config should be more explicit. For example:

    ```
    IdentityFile ~/.ssh/id_ed25519.pub

    Host host-that-uses-the-rsa-key
    IdentityFile ~/.ssh/id_rsa.pub
    ```

    Or even more explicit:
    ```
    Host host-that-uses-the-rsa-key
    IdentityFile ~/.ssh/id_rsa.pub

    Host host-that-uses-the-ed25519-key
    IdentityFile ~/.ssh/id_ed25519.pub
    ```

  • tonkku107's avatar
    tonkku107
    Occasional Contributor

    SSH by default uses the keys in the order specified. I could go and mark which key to use for each host, but it would be far more convenient to have them apply globally apart from a few exceptions.

    Specifying the order to try keys in would be a small quality of life feature. It could be used to demote a key to be a fallback that's used only when necessary and to just optimize the authentication speed to not waste time trying less frequently used keys.