Level up your business security with free, on-demand training and certification. Explore 1Password Academy today →
ssh
549 TopicsSSH into Devices running old versions of Dropbear SSH (e.g. UniFi APs, and other routers)
After a lot of investigation in a thread on slack over the past 2 days, I discovered that 1Password's ssh-agent doesn't support logging into UniFi Access Points, which are running an old version of Dropbear SSH. This is an alternative SSH implementation that's commonly used on low power devices like routers and access points. I'm just posting this here for anyone else who may encounter this issue trying to log into a similar device. If you also have trouble logging into a device running Dropbear, check the version: ``` ssh -V Dropbear v2017.75 ``` That version of Dropbear only supports ssh-rsa signatures and not rsa-sha2-256 or rsa-sha2-512. Support for these signature algorithms were added in version 2020.79. Routers with OpenWRT firmware installed on them also run Dropbear. If you have this, this may be a problem for you depending on when you most recently updated the firmware. The ssh logs when this occurs will look something like this: $ ssh -vvv 10.0.1.10 ... debug3: sign_and_send_pubkey: signing using ssh-rsa SHA256:<redacted fingerprint> sign_and_send_pubkey: signing failed for RSA "" from agent: agent refused operation ... 1Password's logs show this error: [1P:/Users/builder/builds/BhfSvM9x/0/dev/core/core/ssh/op-ssh-agent/src/lib.rs:306] Error handling sign request: Key(expected RSA signature algorithm, but found a Ed25519 one) If you encounter this problem, upgrade your device firmware if possible, or complain to the vendor that their devices are running an out of date SSH server. Thanks to K_J__1P for helping to figure this out with me in slack. 1Password Version: Not Provided Extension Version: Not Provided OS Version: Not Provided3.2KViews0likes12CommentsExporting encrypted ssh key not usable
Hi guys, I tried to export an encrypted ssh key, which I generated in 1Password and use this in my SSH Client tool of choice (Server Cat or WebSSH) but the key is not usable, as I get the error "Error parsing private key". If I copy or download the unencrypted key it works fine. I do not think this is the way it should behave. Could you look into it, or let me know how I can do it better? 1Password Version: 8.10.23 Extension Version: Not Provided OS Version: macOS 14.3.1 Browser: Not Provided360Views2likes2CommentsImport of SSH keys strips comments, making certain workflows impossible
In the current implementation, there is no way to import or create a new ssh key item without stripping the comment of the public key. As far as i can tell, this is due to 1Password only using the private key on import / creation and generating the public key from that itself. This is probably a good decision as users cannot miss-match key-pairs this way. This works for most use cases, because the comment is not used in the authorization process. However, some services like Gitea match the public key comment (which is often an email address) against the email address of the service account. Why Gitea does this can be read e.g. in this https://github.com/go-gitea/gitea/issues/18238. I would suggest an option while creating / edition the ssh key to manually add a comment to the public key. By doing it this way, the current import logic does not have to be changed and since the new "edit" feature would only allow to add/edit a comment to the public key, the integrity of the key-pair can also not be destroyed by the user on accident. There have been multiple discussions about the removal of comments already, but sadly no attempts have been made to resolve this issue or at least make it obvious, that the key is not being imported without any changes to its content. 1Password Version: 8.10.40 Extension Version: Not Provided OS Version: Windows 11 Browser: Not Provided120Views1like2Commentsrequest: remember application approval for SSH agent
my intelliJ app has Git Toolbox plugin which checks git via SSH every 10 minutes. Due to this, I continuously get 1Password 8 on macOS asking if I want to allow this PHPStorm to access the SSH key. Can you please add an option to remember the setting? Otherwise I need to revert moving to the 1password 8 SSH agent. 1Password Version: 8.9.4 Extension Version: Not Provided OS Version: macOS Browser:_ Not Provided2.3KViews4likes24CommentsSpecify the path to the SSH agent socket ?
Currently, the 1Password ssh agent socket is set to ~/.1Password/agent.sock on Linux, and ~/Library/Group\ Containers/2BUA8C4S2C.com.1password/t/agent.sock on macOS (as per https://developer.1password.com/docs/ssh/agent/config). Would it be possible to modify that path ? It could then be set to respect the $XDG_DATA_HOME variable on Linux, or could be set to a custom path. I propose using the agent.toml configuration file, and store that path under the following table: ```toml [ssh-agent] socket = "$XDG_DATA_HOME/1Password/agent.sock" The tables below would behave as usual... [[ssh-keys]] item = "..." ... ``` 1Password Version: 8.10.54 Extension Version: 8.10.55.2 OS Version: Fedora 41 Browser: Not Provided217Views2likes2CommentsFeature idea: when creating ssh keys, consider option to auto add comment to end of public key
When copying and pasting public keys to remote servers it is helpful if they include a comment to easily identify keys when reviewing authorized_keys Under Developer options consider having a flag to auto-add comment to key so if generating a key for "web apps server bronze 2022" it might add a comment at end: == 1password-web-apps-server-bronze-2022 Alternatively you could have a ssh comment field in 1password and whatever user defines is automatically added to end of public key. 1Password Version: 8 Extension Version: Not Provided OS Version: Not ProvidedSolved937Views4likes7CommentsGit commit signing - can't find op-ssh-sign
I have followed the https://developer.1password.com/docs/ssh/git-commit-signing for setting up git commit signing. In https://developer.1password.com/docs/ssh/git-commit-signing#step-1-configure-git-commit-signing-with-ssh, step 2 tells me to click the three dots and select Configure Commit Signing and shows a screenshot of the window you should see. I do not have that option in my three-dots menu when viewing my SSH Key: I also found https://youtu.be/BMFvhl0WRFQ, which shows a Next Step: Sign Your Git Commits message when viewing an SSH Key in 1Password. But I don't see this message either. Instead, I used the config from https://developer.1password.com/docs/ssh/git-commit-signing#configure-multiple-commit-signing-setups and manually entered it into my .gitconfig . But when I try to commit a change, I get the following error: fatal: cannot run /Applications/1Password.app/Contents/MacOS/op-ssh-sign: No such file or directory Looking in the MacOS directory, there is only one file in there called 1Password . Any ideas? 1Password Version: 8.8.0 Extension Version: 2.3.7 OS Version: macOS 12.5.1 Browser:_ Chrome2.4KViews0likes3CommentsUsing 1password on a server in a script?
Hi, I've been a recent 1password convert, and I'm loving it. One thing I can't figure out if this is possible: I have a server on which I have scripts running (through cron) that need some credentials. Both SSH keys are required as well as actual API credentials. Right now those are stored in a file on the filesystem, which works, but I'd love it if I can somehow get these out of OP instead of having to have the files there. These scripts run at night, thus it needs to be 100% "hands-off". For the SSH keys I fear there is no solution using OP that's truly non-interactive. The API credentials I think are possible, but I'm not seeing it. Anyone can point me in the right direction? 1Password Version: 8.10.0 Extension Version: 2.6.1 OS Version: Fedora 37 Browser:_ FirefoxSolved232Views0likes2Comments[Linux] Use $XDG_RUNTIME_DIR instead of $HOME/.1password?
I like to try (although not very successfully) to keep my home directory clean of unnecessary dotfiles. While this is a very cool feature, I think it makes more sense to keep the socket in $XDG_RUNTIME_DIR . This seems to be what the directory is made for, and would prevent another folder under the home directory. From the https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html: $XDG_RUNTIME_DIR defines the base directory relative to which user-specific non-essential runtime files and other file objects (such as sockets, named pipes, ...) should be stored. The directory MUST be owned by the user, and he MUST be the only one having read and write access to it. Its Unix access mode MUST be 0700. 1Password Version: 8.6.0~26.BETA Extension Version: 2.3.0 OS Version: Fedora Linux 35 (Workstation Edition)677Views0likes8Comments