I'm trying to import .p12 certificate into the keychain on my mac via bash script. So far, I've been trying: 1. sudo security import command. It returns that import was successful but, in fact, it never gets imported into any keychain. 2. sudo security add-certificates -k /Library/Keychains/System.keychain certificate.p12 it throws the following error: Password: SecCertificateCreateFromData: Unknown format in import. The only thing that worked for me was the .cer format via this command: sudo security add-certificates -k /Library/Keychains/System.keychain certificate.cer. It does import the certificate into the keychain and I can see it in the keychain access. But I only have .p12 certificates. Could anyone help me with that one, please?

I installed openssh via brew install openssh. I added the following to my .profile: export SSH_AUTH_SOCK="~/.ssh/agent.$HOST.sock" ssh-add -l 2>/dev/null >/dev/null if [ $? -ge 2 ]; then ssh-agent -a "$SSH_AUTH_SOCK" >/dev/null fi And then I have to do the following: ssh-add ~/.ssh/id_ecdsa_sk Enter passphrase for /Users/myuser/.ssh/id_ecdsa_sk: Identity added: /Users/myuser/.ssh/id_ecdsa_sk even though I have the following in my ~/.ssh/config: Host * IgnoreUnknown UseKeychain UseKeychain yes AddKeysToAgent yes IdentityFile ~/.ssh/id_ecdsa_sk (I had to add the IgnoreUnknown bit b/c the install from brew installs a version that breaks the UseKeychain bit.) But now: how do I wire it up so it adds the key to my keychain? Help appreciated!

I use Pushbullet and a third party Python script that allows me to send "pushes" from the command line. This script uses MacOS "Keychain" to access passwords and tokens used for Pushbullet. If I execute the script locally, something like % pb push "SE demo" in works fine and the "push" is sent as expected, but I need to send it using ssh from machine A to B: % ssh B pb push "SE\ demo" but when I do I get a traceback that the script can't access *Keychain*. I can work around that by first unlocking the Keychain: % security -i unlock-keychain but you have to do that everytime you want to send a push, which kind of defeats the purpose of the Keychain. The key difference between a local shell and ssh is that ssh shells are **non-interactive** (if I open a local shell and su I get a **non-login** but interactive shell - in such a shell it still works to send these pushes/there are no issues with Keychain). **How can I, using ssh, access the environment of a local interactive shell so my script can access the Keychain?** Additional details. What I am actually doing is running an AppleScript via SSH: % ssh B osascript ~/scripts/myscript At the end of this AppleScript I execute a shell script that sends this Pushbullet push do shell script "pb push 'done'" and it is this command that fails because it can't access the Keychain. If I execute the AppleScript locally on B, from the Script Editor or the command line, the do shell script-part works. OTOH, AppleScript reports that the environment it executes its do shell-script is non-interactive and non-login.

I want to link some passwordless SSH logins to some screen sessions, so that anytime a window is opened in the screen session the ssh-agent is inherited, but whenever I open a new window in screen, the ssh-agent reverts back to the main sessions settings. This is what I'm attempting but it doesn't work: Before I start the screen session, I run ` eval ssh-agent `. This ensures that the main ssh-agent which is set via key-chain doesn't get passed on. However when I run screen it reverts back to the main ssh-agent's settings, and even when I run ` eval ssh-agent ` again within that window, the settings don't carry on to the next window. Is there some way to run an ssh-agent session that can be carried on to each new window within screen? In sum, I think I need to select which ssh-agent I should use whenever I open a new terminal window. If I have a number of ssh-agent sessions running, is there a way to choose which one a newly opened terminal window, or even an existing terminal window should use?

I'm using Funtoo keychain on Ubuntu 22.04 and I have followed the instructions to add the following to ~/.profile: eval keychain --eval --agents ssh id_rsa I'm running the i3 window manager, from GDM, and the problem is that GDM seems to run /bin/bash /etc/gdm3/Xsession i3, which invokes my ~/.profile script. This causes it to hang on the eval line because it prompts for a password. Since there's no interactive shell I can't add one and the whole log-in process stops with a blank screen. To recover I have to edit ~/.profile to remove the keychain line, and manually restart GDM. Is there an effective way to not have this log-in process blocked, but still have keychain ask me for a passphrase the first time I actually open a shell window in i3?

I'm currently having issues with installing a package due to a missing key. My first plan was to updating my keyring however "pacman-key --refresh-keys" fails: [user@hostname ~]$ sudo pacman-key --refresh-keys gpg: refreshing 134 keys from hkp://pool.sks-keyservers.net gpg: keyserver refresh failed: Permission denied ==> ERROR: A specified local key could not be updated from a keyserver. Also tried running it under "su". [user@hostname ~]$ su Password: [root@hostname user]# pacman-key --refresh-keys gpg: refreshing 134 keys from hkp://pool.sks-keyservers.net gpg: keyserver refresh failed: Permission denied ==> ERROR: A specified local key could not be updated from a keyserver. Tried running dirmngr manually to see if there are any errors. [user@hostname ~]$ sudo dirmngr ERROR: A specified local key could not be updated from a keyserver After removing both ".gnupg" directories I ran dirmngr again. [user@hostname ~]$ dirmngr --debug-level guru dirmngr: enabled debug flags: x509 crypto memory cache memstat hashing ipc dns network lookup extprog dirmngr: error opening '/home/user/.gnupg/dirmngr_ldapservers.conf': No such file or directory dirmngr[18151.0]: permanently loaded certificates: 141 dirmngr[18151.0]: runtime cached certificates: 0 dirmngr[18151.0]: trusted certificates: 141 (140,0,0,1) dirmngr[18151.0]: failed to open cache dir file '/home/user/.gnupg/crls.d/DIR.txt': No such file or directory dirmngr[18151.0]: creating directory '/home/user/.gnupg' dirmngr[18151.0]: creating directory '/home/user/.gnupg/crls.d' dirmngr[18151.0]: new cache dir file '/home/user/.gnupg/crls.d/DIR.txt' created dirmngr[18151.0]: DBG: chan_3 -> # Home: /home/user/.gnupg # Home: /home/user/.gnupg dirmngr[18151.0]: DBG: chan_3 -> # Config: [none] # Config: [none] dirmngr[18151.0]: DBG: chan_3 -> OK Dirmngr 2.2.3 at your service OK Dirmngr 2.2.3 at your service And now I'm completely stuck. I suspected there might be some kind of permissions issue with a file needed by GPG but given that I've deleted both ".gnupg" directories and that they've been regenerated I don't see what's wrong. I've also tried everything on this wiki page: https://wiki.parabola.nu/Parabola_Keyring everything worked including the "sudo pacman-key --populate archlinux archlinux32 archlinuxarm parabola" command but "pacman-key --refresh-keys" still gave me the permissions error. Just tried refreshing my keyring with gpg directly: [user@hostname ~]$ sudo gpg2 --refresh-keys gpg: directory '/root/.gnupg' created gpg: keybox '/root/.gnupg/pubring.kbx' created Then tried to do it with pacman-key: [user@hostname ~]$ sudo pacman-key --refresh-keys gpg: refreshing 135 keys from hkp://pool.sks-keyservers.net gpg: keyserver refresh failed: Permission denied ==> ERROR: A specified local key could not be updated from a keyserver. So that failed. Tried with gpg2 to see if the output was the same: [user@hostname ~]$ sudo gpg2 --refresh-keys There wasn't any output so I doubt that the files it created are related to my current issue. As a last ditch effort I tried without sudo and got no output: [user@hostname ~]$ gpg2 --refresh-keys Still stuck with this. Even installed kgpg to manually generate a config file for gpg. However, I'm still getting this damn permissions error.

I have a Debian 10 server. I want to send email with msmtp and I need to cache a passphrase for a gpg key. The smtp password needed by msmtp is encrypted in a file using this gpg key. msmtp will use gpg to decrypt this file to get the smtp password. This line is present in the /etc/msmtprc file : passwordeval gpg --no-tty -q -d /etc/.msmtp-password.gpg **I'm trying to use gpg-agent and keychain to cache the password of the secret gpg key**. This way the system could send emails without asking password. I want that each time I boot the server **I submit the passphrase for the gpg key only once, the passphrase for the key will be cached until the next reboot**. (If I logout and login again I shouldn't need to submit the passphrase for the gpg key until the next reboot). I didn't succeed because when I logout from the remote host (Debian server), the gpg-agent stop. If I'm establishing a new connection via SSH keychain start a new agent with a new PID and the passphrase for the key is lost. Below you'll find what I did and I hope useful informations. I'll be happy if you could help me. My linux version cat /etc/issue Debian GNU/Linux 10 \n \l gpg version gpg --version gpg (GnuPG) 2.2.12 libgcrypt 1.8.4 We create a secret gpg key, a password for the key will be asked gpg --gen-key ... Nom réel : user@mdomain.tld Adresse électronique : user@mdomain.tld Vous avez sélectionné cette identité : « user@mdomain.tld  » ... les clefs publique et secrète ont été créées et signées. pub rsa3072 2020-10-15 [SC] [expire : 2022-10-15] 3C82AB1E9384F4A92CEBCE7077B1EDA25A942746 uid user@mdomain.tld sub rsa3072 2020-10-15 [E] [expire : 2022-10-15] We check the secret key gpg --list-secret-keys --with-keygrip ... sec rsa3072 2020-10-15 [SC] [expire : 2022-10-15] 3C82AB1E9384F4A92CEBCE7077B1EDA25A942746 Keygrip = 47CF9E2C933761CF1021731F72603B8291BB211C uid [ ultime ] user@mdomain.tld ssb rsa3072 2020-10-15 [E] [expire : 2022-10-15] Keygrip = 4133708B3FA225C4732A0F9FBD0053DEF937B46A We look at the PID of the gpg-agent process ps aux | grep gpg-agent root 738 17.1 0.0 81204 3864 ? SLs 16:55 0:04 /usr/bin/gpg-agent --supervised root 745 0.0 0.0 6092 824 pts/0 S+ 16:56 0:00 grep gpg-agent We check the keys known by gpg-agent gpg-connect-agent 'keyinfo --list' /bye S KEYINFO 47CF9E2C933761CF1021731F72603B8291BB211C D - - - P - - - S KEYINFO 4133708B3FA225C4732A0F9FBD0053DEF937B46A D - - - P - - - OK We check the gpg-agent options gpgconf --list-options gpg-agent Monitor:1:0:Options contrôlant la sortie de diagnostique:0:0:::: ... default-cache-ttl:24:0:oublier les codes personnels après N secondes:3:3:N:600:: default-cache-ttl-ssh:24:1:oublier les clefs SSH après N secondes:3:3:N:1800:: max-cache-ttl:24:2:définir la durée maximale du cache de code personnel à N secondes:3:3:N:7200:: max-cache-ttl-ssh:24:2:définir la durée maximale du cache de clef SSH à N secondes:3:3:N:7200:: ... pinentry-timeout:24:1:set the Pinentry timeout to N seconds:3:3:N:0:: default-cache-ttl and max-cache-ttl are too low, gpg-agent will cache the passphrase only 10 minutes. This is a too short period if you intend to use keychain. We can also add a log file. Default options can be changed by adding a gpg-agent.conf file. cat ~/.gnupg/gpg-agent.conf default-cache-ttl 31536000 max-cache-ttl 31536000 log-file /var/log/gpg-agent debug-level basic We check if new gpg-agent options have been added gpgconf --list-options gpg-agent Monitor:1:0:Options contrôlant la sortie de diagnostique:0:0:::: ... default-cache-ttl:24:0:oublier les codes personnels après N secondes:3:3:N:600::31536000 default-cache-ttl-ssh:24:1:oublier les clefs SSH après N secondes:3:3:N:1800:: max-cache-ttl:24:2:définir la durée maximale du cache de code personnel à N secondes:3:3:N:7200::31536000 max-cache-ttl-ssh:24:2:définir la durée maximale du cache de clef SSH à N secondes:3:3:N:7200:: ... pinentry-timeout:24:1:set the Pinentry timeout to N seconds:3:3:N:0:: We reload the gpg-agent configuration to activate the new options gpg-connect-agent reloadagent /bye OK Know we install keychain apt install -y keychain keychain version keychain -V * keychain 2.8.5 ~ http://www.funtoo.org We cache decrypted GPG keys with keychain keychain --eval --agents gpg 3C82AB1E9384F4A92CEBCE7077B1EDA25A942746 * keychain 2.8.5 ~ http://www.funtoo.org * Inheriting gpg-agent (738) GPG_AGENT_INFO=/run/user/0/gnupg/S.gpg-agent:738:1; export GPG_AGENT_INFO; * Adding 1 gpg key(s): 3C82AB1E9384F4A92CEBCE7077B1EDA25A942746 Because we entered the passphrase, the decrypted GPG key is now cached by gpg-agent (look at the 1) gpg-connect-agent 'keyinfo --list' /bye S KEYINFO 47CF9E2C933761CF1021731F72603B8291BB211C D - - 1 P - - - S KEYINFO 4133708B3FA225C4732A0F9FBD0053DEF937B46A D - - - P - - - OK We modify the .bashrc file. On next login keychain will find the decrypted GPG key cached by gpg-agent. On next reboot keychain will ask once the passphrase for the key until the next reboot cat ~/.bashrc ... # Note: PS1 and umask are already set in /etc/profile. You should not # need this unless you want different defaults for root. # PS1='${debian_chroot:+($debian_chroot)}\h:\w\$ ' # umask 022 ... eval $(keychain --agents gpg) In order to check default-cache-ttl and max-cache-ttl we wait 700 seconds, more than gpg-agent default configuration jeudi 15 octobre 2020, 16:56:32 (UTC+0200) jeudi 15 octobre 2020, 17:08:12 (UTC+0200) We check the keys known by gpg-agent the decrypted GPG key is still cached by gpg-agent (look at the 1) gpg-connect-agent 'keyinfo --list' /bye S KEYINFO 47CF9E2C933761CF1021731F72603B8291BB211C D - - 1 P - - - S KEYINFO 4133708B3FA225C4732A0F9FBD0053DEF937B46A D - - - P - - - OK We create a file and encrypt it with the key (no passphrase is needed for encryption) touch file.txt && gpg -e -r user@mdomain.tld file.txt We decrypt the file. No passphrase is needed because the decrypted GPG key is still cached by gpg-agent after 700 seconds gpg --decrypt file.txt.gpg > file.txt gpg: chiffré avec une clef RSA de 3072 bits, identifiant 4E40A1918B514393, créée le 2020-10-15 « user@mdomain.tld  » We **logout and login again** to the remote host via ssh. At new login keychain can't find the previous gpg-agent with the cached key. Then keychain start a new gpg-agent but the cached key is lost... * keychain 2.8.5 ~ http://www.funtoo.org * Starting gpg-agent... Regards

In looking toward upgrading to Ubuntu 20.04.1, I think I will have some machines on 18.04 for a while. I decided to install the unison-jz snap to prevent a version mismatch. Even though I have an ssh-agent running, I keep it around with keychain , and I am able to login to my remote host without a passphrase prompt outside of unison-jz, it always prompts me for the passphrase for my id_rsa file. I have tried to compare the output of

-v

from both ssh and unison-jz's invocation of ssh (by setting

=
-v

in my preferences file, but I cannot tell what the difference is. Any suggestions for what to do next?

I have followed the instructions here https://www.funtoo.org/Keychain and added eval keychain --eval --agents ssh --inherit any id_rsa to - I have tried both but the result was the same - .zshrc and .zprofile. Now the first terminal that I open requires me to enter the password for the SSH key (as expected) but after that, I never need to enter the password, independently of how many terminals I open. However, if I log in to this machine using SSH I need to enter the SSH key password every time I connect. Obviously there is some difference how the shell is setup if I open a new terminal session sitting in front of the machine or open an SSH session. **How do I make SSH logins "inherit" the Funtoo Keychain setup/environment so I don't need to enter the password for the SSH key every time I log in to this machine using SSH?**

I am using KDE desktop (plasma 5 ) environment with opensuse leap 42.1. Many programs in my system use native keychain to store password like (JetBrain products). But when saving the password, I notice that the default keychain for my system is genom-keyring. How to configure my system to use KWallet as default keychain. I have uninstall genom-keyring with all its dependencies and now the system does not recognize any default keychain. How can I make Kwallet the default keychain? Another question how can I avoid typing the paraphrase every time I sign in my account (to open the wallet) Thank you very much

**Disclaimer:** It would be very nice to read this question thoroughly before marking it as duplicate. I have read dozens of other questions (here, at superuser.com, serverfault.com and so on), all dealing with SSH not finding /dev/tty, *but none of them with relation to keychain*, which actually should prevent this problem. **Having said this:** I have a Linux (Debian stretch) router which is connected to the Internet via pppoe. My provider gives me a dynamic IP address which changes from time to time. Whenever this happens, the router should run a script on another host via SSH. I have correctly set up SSH on the router and the other host, using public key authentication. The SSH keys are protected by a passphrase. Furthermore, I have set up keychain as advised here . According to my understanding of this page (and others), keychain "provides" the same ssh-agent process to any SSH client; when I am logging in, it starts ssh-agent (if none is running yet) and asks (or makes ssh ask) for the passphrase(s); from then on, the SSH keys are in ssh-agent's memory and readily available to other processes. This works with the following exception: I have put a script into /etc/ppp/ip-up.d; that script contains (among others) the following lines: eval /usr/bin/keychain --noask --agents ssh --eval id_rsa_ipupdate ssh -i /root/.ssh/id_rsa_ipupdate root@re.mo.te.ip '/path/to/remote/command' Although the script itself gets executed as expected every time the provider assigns a new IP address, the SSH command fails, i.e. the script on the *remote* host doesn't get executed. It took me a while to debug this, but after making pppd log its debug messages in a separate file, I finally found the reason. Some relevant lines from pppd's debug messages: debug1: Server accepts key: pkalg ssh-rsa blen 535 debug2: input_userauth_pk_ok: fp SHA256:BZSkP9mMIB+cCi5WfgYnqT2QmskTgsKHsWuNXHxIQu0 debug3: sign_and_send_pubkey: RSA SHA256:BZSkP9mMIB+cCi5WfgYnqT2QmskTgsKHsWuNXHxIQu0 debug1: read_passphrase: can't open /dev/tty: No such device or address debug2: no passphrase given, try next key debug2: we did not send a packet, disable method debug1: No more authentication methods to try. Permission denied (publickey). So SSH does not find /dev/tty, which is probably normal, given that it is executed from within pppd in this case and thus can't read the passphrase from the keyboard. So far, so good. But the key point is: **Why does SSH (obviously) want to read the passphrase from the keyboard although an ssh-agent is running, managed by keychain and having the key readily available?** Please note the first line in the script snippet above. It should make sure that SSH_AUTH_SOCK and SSH_AGENT_PID are set and exported correctly. Please note also that the script works perfectly (without asking for a passphrase) when I run it from the command line. To make things absolutely clear: I first log in into the router. As I have set up keychain as advised on its homepage, I am immediately asked for the passphrase(s) when logging in. When then calling my script from the command line, it works as expected without asking for the passphrase. But when the script is called by pppd, the SSH line fails. Could anybody please explain why SSH wants /dev/tty although it could load the keys from ssh-agent, and how to get around that problem? P.S. Yes, I can live with the fact that the script will inevitably fail after the router has rebooted, until I log in at least once :-) **EDIT 1** I have done further research and noticed the following: The line eval /usr/bin/keychain --noask --agents ssh --eval id_rsa_ipupdate from the script above definitely creates a second ssh-agent process when the script is executed by pppd due to a change of the public IP address. That means that keychain does not find the first one (which has the SSH keys available) for some weird reason. Again, this only happens when the script is executed by pppd; when I call the script from the command line, everything is fine. I am now thinking about opening a bug report or something like that. By the way, my keychain version is 2.8.2.