I frequently need to log into a VM that has no direct access to the internet or our source code repo. In the past I have circumvented this with a reverse port forward over ssh but now my problem is that we use Yubikey local hardware tokens and I need to forward the request through my local machine, where I can press the key In the past, without the Yubikey, this is what I had:

Host bastion
  HostName 129.153.206.108

### The Remote Host
Host sredev1
  HostName 10.0.1.40
  ProxyJump bastion
  RemoteForward 7999 foo.mycorp.com:7999

Then, updating my local git as:

get remote set-url main localhost:7999

which allowed

git pull

However, the situation is more complicated and I need similar functionality; I am not particular on the method but I don't want to have syncing processes in place. My ssh config at the moment is:

Host oci*.private.devops.scmservice.*.oci.oracleiaas.com
   User cbongior@bmc_operator_access
   IdentityAgent ~/.ssh/scm-agent.sock
   PKCS11Provider /usr/local/lib/libykcs11.dylib


Host fsretoolsint-jh-1
    Hostname 100.92.7.226
    User     jumpuser
    IdentityFile ~/.ssh/jumpuser.pkey

Host sredev2
  Port 22
  IdentityFile ~/.ssh/sredev2.key
  Hostname 10.196.169.56
  ProxyJump  fsretoolsint-jh-1
  RemoteForward 7999 oci.private.devops.scmservice.us-phoenix-1.oci.oracleiaas.com:22

And, for example, in a given repo I have:

git remote -v
origin  ssh://localhost:7999/namespaces/axuxirvibvvo/projects/VERM/repositories/fleetman (fetch)
origin  ssh://localhost:7999/namespaces/axuxirvibvvo/projects/VERM/repositories/fleetman (push)

And locally that same repo is:

origin  ssh://oci.private.devops.scmservice.us-phoenix-1.oci.oracleiaas.com/namespaces/axuxirvibvvo/projects/VERM/repositories/fleetman (fetch)
origin  ssh://oci.private.devops.scmservice.us-phoenix-1.oci.oracleiaas.com/namespaces/axuxirvibvvo/projects/VERM/repositories/fleetman (push)

On my vm this is what I get when I try git pull:

-> % git remote set-url origin ssh://localhost:7999/namespaces/axuxirvibvvo/projects/VERM/repositories/fleetman
cbongior@sredev2 [10:51:44 PM] [~/dev/oracle/fleetman] [main *]
-> % git fetch origin
cbongior@localhost: Permission denied (publickey).
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

Now, I know the local keypair isn't registered - and there is no point. We are setup to use Yubi keys to authenticate and this is where I am stumped. So, for architectural clarity, the arrangement is:

my laptop with YK -> jump host -> vm

and the tunnel arrangement is:

git server << my laptop << jump host << vm port 7999

I am created a reverse tunnel on the VM directorying traffic on port 7999 to the git server on 22 **Question:** How can I configure this to forward the ssh request to my local agent?

I'm storing my ssh keys on a yubikey and hence I don't have any private key file on disk. This gives me a problem when I'm also using OpenSSH Certificates to authenticate. If I would like to bring the certificate with me using the ssh-agent I need to add it to the agent some how. This is done automatically if I have a private key called priv and a cert called priv-cert.pub. But since I don't have a file I cant find a way to add the certificate file to the agent. Does anyone have a clue how to do this? It seems there is no support for this, I found this feature request: https://bugzilla.mindrot.org/show_bug.cgi?id=2472

I want to add to my bashrc the code:

eval $(ssh-agent -s)
ssh-add ~/.ssh/id_rsa

but it is always asking to **Enter passphrase for /home/User/.ssh/id_rsa:** A friend of mine add the same snippet to bashrc and worked perfectly(without asking for passphrase and showing the message **Identity added: /home/User/.ssh/id_rsa**. How can I do it in a way that I don't have to type the passphrase each time I entry on terminal and show me the info that Identity added?

There are endless number of helpful articles and answers on how set up ~/.ssh/config (e.g., this one's pretty good ), but none of them mentions what to do if the private key is also password protected.

I am trying to connect to an Elasticache Redis Server via an AWS Ubuntu instance and using an ssh tunnel. When I try to configure Redis Desktop Manager to connect via an ssh tunnel and provide credentials and .pem file, I have authentication issues. However, this same .pem file doesn't create issues when I try to connect via shell. Am I missing something here ? should I change the file permission (as for now it is 400). This a screenshot on the errors shown on the RDM system log

I'm using WSL2, on Terminal, with Ubuntu installed. I have added the following to my .bashrc:

# Start ssh-agent
# check if ssh-agent is already running
if [ -z "$SSH_AUTH_SOCK" ]; then
     #start ssh-agent
    eval "$(ssh-agent -s)"
fi


# Ask for ssh-add
read -p "Do you want to add your SSH public key? (y/n) " response

if [ "$response" = "y" ]; then
  ssh-add ~/id_rsa
  ssh-add -l
elif [ "$response" = "n" ]; then
  echo "No identity on terminal session"
else
  echo "Invalid response"
fi

With the idea that every time I open a new terminal, it will ask for a prompt if an identity is needed and proceed to start ssh-agent and add the key if yes. At first, it appears as if the script work and it'll show the agent's PID, along with a prompt for my ssh password and I'm able to see the ssh-agent when i do top. However, it did not actually initialize ssh-agent nor add the key, despite seeing the output of these commands. I even did ssh-add -l and it'll output: The agent has no identities. How do I go about making this work? This has to be a WSL issue..

I am trying to unlock the gnome keyring on my server machine so that I can push git commits via ssh to github. The ssh key for this is encrypted. What I tried is this:

# See https://unix.stackexchange.com/a/676655 
function unlock-gnome-keyring () {
    read -rsp "Password: " pass
    export $(echo -n "$pass" | gnome-keyring-daemon --replace --unlock)
    unset pass
}

unlock-gnome-keyring
# Enter password...
# Prints
# discover_other_daemon: 0** Message: 20:29:52.540: Replacing daemon, using directory: /run/user/1000/keyring

ssh-add /home/username/.ssh/id_ed25519
# Enter password for keyfile...
# Prints:
# Identity added: /home/username/.ssh/id_ed25519 (comment)

That looks OK so far and I can then push to the repo. However, after some time this does not work anymore. Similarly, when I close the shell and reopen it, I am asked again for the passphrase. This may be expected if the shell that sharted the keyring daemon gets closed? I don't quite know. Either way, I try to unlock the keyring again, as above and get the same output. Then,

$ git pull
sign_and_send_pubkey: signing failed for ED25519 "/home/username/.ssh/id_ed25519" from agent: agent refused operation
git@...: Permission denied (publickey).
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.

This can only be fixed by re-adding the key to the keyring. How can this be fixed?

I use my keys without any password because all machines involved operate in a fairly closed environment. So I do not need ssh-agent. But I accidentally ran a script that seems to have enabled it use, and I cannot get it to stop. I can kill the process, but upon next boot, since the 'decrypted' key isn't in the cache, I am not able to ssh without the error message: sign_and_send_pubkey: signing failed: agent refused operation The 'culprit' seems to be $SSH_AUTH_SOCK. Will all of this be solved if I just remove that? Or is there a better way? **EDIT**: The $SSH_AUTH_SOCK variable only exists when I check from a terminal in my GNOME desktop. If I check from a tty, it returns nothing.

I have my ssh identities added at the end of the .bashrc script, as the server says here when I log in, Agent is running with pid 8411 and all of the identitias are added. As is also evident from the console below, I can not use my identities. In order to use them, I need to type a command to start the ssh agent (which now receives a new pid 8531) and also type the command to add the identity to the agent (again?), and only then will git recognize the identity and allow to pull the repo. What is going on here, what am I doing wrong? Last login: Sat Jul 1 11:51:58 2023 from 162.243.190.66 Agent pid 8411 Identity added: /root/.ssh/id_ed25519 (mattias@domain.se) Identity added: /root/.ssh/id_ed25519_api_requests (mattias@domain.se) Identity added: /root/.ssh/id_ed25519_airspace_sweden (mattias@domain.se) Identity added: /root/.ssh/id_ed25519_hwx (mattias@domain.se) root@DR2-sweden-internal-api:~# cd /var/www/html root@DR2-sweden-internal-api:/var/www/html# ls aircraft airspace airspace-sweden drones index.html root@DR2-sweden-internal-api:/var/www/html# git clone git@github.com:domain/myrepo-api-out-HemsWX.git Cloning into 'myrepo-api-out-HemsWX'... ERROR: Repository not found. fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. root@DR2-sweden-internal-api:/var/www/html# eval "$(ssh-agent -s)" Agent pid 8531 root@DR2-sweden-internal-api:/var/www/html# ssh-add ~/.ssh/id_ed25519_hwx Identity added: /root/.ssh/id_ed25519_hwx (mattias@domain.se) root@DR2-sweden-internal-api:/var/www/html# git clone git@github.com:domain/myrepo-api-out-HemsWX.git Cloning into 'myrepo-api-out-HemsWX'... remote: Enumerating objects: 91, done. remote: Counting objects: 100% (91/91), done. remote: Compressing objects: 100% (65/65), done. remote: Total 91 (delta 35), reused 79 (delta 23), pack-reused 0 Receiving objects: 100% (91/91), 20.14 KiB | 2.88 MiB/s, done. Resolving deltas: 100% (35/35), done. This is at the end of my ~/.bashrc #add github deploy keys to agent eval "$(ssh-agent -s)" ssh-add ~/.ssh/id_ed25519 ssh-add ~/.ssh/id_ed25519_api_requests ssh-add ~/.ssh/id_ed25519_airspace_sweden ssh-add ~/.ssh/id_ed25519_hwx ------- UPDATE (for Ulrichs comment) ---------- So I notice that the first of the four identities is usable. The -v gave a whole lot of debug lines =) debug1: Connecting to github.com [140.82.121.3] port 22. debug1: Connection established. debug1: identity file /root/.ssh/id_rsa type -1 debug1: identity file /root/.ssh/id_rsa-cert type -1 debug1: identity file /root/.ssh/id_dsa type -1 debug1: identity file /root/.ssh/id_dsa-cert type -1 debug1: identity file /root/.ssh/id_ecdsa type -1 debug1: identity file /root/.ssh/id_ecdsa-cert type -1 debug1: identity file /root/.ssh/id_ecdsa_sk type -1 debug1: identity file /root/.ssh/id_ecdsa_sk-cert type -1 debug1: identity file /root/.ssh/id_ed25519 type 3 // origin/master * [new branch] version_1.2 -> origin/version_1.2 root@DR2-sweden-internal-api:/var/www/html/hwx#

How and where can I check what keys have been added with ssh-add to my ssh-agent?

I want to communicate between several computers on my network (static Ethernet), through SSH. In order to do that I need to run [ssh-add](https://man.archlinux.org/man/ssh-add.1.en) every time I log in on a specific machine. What can I do so it's set up once and it doesn't ask me for the passphrase every time I log in or reboot my machine? I know that there is a way where you add some lines to the bash_profile file, but I still need to type the password every time I reboot/log in to a specific machine. if [ -z "$SSH_AUTH_SOCK" ] ; then eval ssh-agent -s ssh-add fi

When I ask Google how ssh agent forwarding works it gives me lots of links to SEO optimized rubbish explaining how to provision ssh-agent. That is NOT what I am asking. I currently have an issue where jobs started in a screen session on the far side of a VPN connection fail because they can't connect out via ssh after the VPN fails. Normally these jobs rely on agent forwarding from the origin client to connect. I have suspicions about what is going wrong here, but a better understanding of the whole agent forwarding would help here. When I connect from host0 to hosta, the ssh-agent on host0 provides my private key to the ssh client on host0. On hosta I see SSH_AUTH_SOCK populated referencing a local socket. If, on hosta I then ssh hostb, the ssh client somehow connects to ssh-agent on host0. presumably that is using an alternate channel in the host0-hosta ssh connection. what is happenning at $SSH_AUTH_SOCK on hosta? (fuser $SSH_AUTH_SOCK suggests that nothing has that open) In the case of my screen session, if the ssh session which started the screen session has ended, and I start a new ssh session from host0 to hosta, will the key requests from the screen session be sent over the new connection?

At some time in the past whenever I tried an ssh connection to a server without specifying the password ssh would try all the keys in ssh-agent to the point where if there were too many keys, my IP address could be barred for too many connection failures. The behaviour seems to have changed in that even if there is a single valid key in the ssh-agent list I have to include it in the command, eg ssh -i ~/.ssh/alternate-key user@host. Is this due to some change configuration setting or a change in the behaviour of the ssh executable itself.

### Brief Q: How can I cryptographically secure a credentials file that is stored on disk as plaintext? Or, rather: how can I avoid storing credentials like those for Gmail and other API keys on disk? For existing programs that assume such an unencrypted file containing secrets. I ask this question motivated by wanting to access Gmail using gmi/lieer and notmuch - which AFAICT use an unencrypted credentials file on disk. But there are lots of other programs that require similar credentials files. Surely there must already be a generic solution to this problem? Something like ssh-agent, that asks the user for a passphrase and then decrypts the secrets into memory for some time. But not necessarily as fancy as ssh-agent... the agent doesn't need to do all of the crypto operations, which might differ by application or API or protocol. IMHO just decrypting the credentials file into memory would be of value. TL;DR - You might be able to stop here without reading the rest --- Some people will understand what I'm asking for from the above BRIEF section. Others, probably not. ### Surely there must be a generic solution to this problem? Surely there is something like ssh-agent that reads such secrets from an encrypted file, asks the user for password (or better), decrypts the secrets, and keeps them only in memory for some time, so that you don't constantly have to reenter the password/etc? Doesn't have to go quite as far as ssh-agent, where the agent does all or most of the cryptographic operations - and hence the protocol between ssh client and ssh-agent is not just "give me the credential", but must also describe the operations to be performed. Since there are lots of different protocols that have lots of different credentials with lots of slightly different operations, there may be an obstacle to creating a custom agent for each right away. But simply having a persistent agent ask the user and then decrypt credentials from disk into memory would be an improvement over nothing at all. Surely this has already been done, in a manner that can work with lots of different apps XYZ? But I certainly don't know of anything like this. Nor, for that matter, do any AI assistants that I have tried - although it might be a question of me not phrasing the LLM prompt or Google search correctly. For that matter, ChatGPT suggested that I do the following: * encrypt the credentials file on disk * when I want to use it * temporarily create an unencrypted credentials file - on disk * let the client program like gmi/lieer access the unencrypted credential file while it is running * and when I no longer am running the client, delete the unencrypted temporary credentials file I hope I don't need to explain how unsatisfactory this is. ### Could this be done using UNIX domain sockets or FUSE? Has it been done already? If I knew that the client application was always reading or replacing the entire credential file, I could imagine having an XYZ-agent write the unencrypted secrets to the socket all at once. or if I do not know the access pattern, e.g. if the secret is large enough that seeks a random-access are performed, I could imagine that a user domain filesystem like FUSE could be used. Q: has anyone created such a generic "decrypt secrets into memory, so it looks like an unencrypted credentials file to software that cannot handle an encrypted credentials file?". * Using UNIX domain sockets * or FUSE * or whatever Even better if such as change to the namespace were limited to a partent process and its children, such as you might be able to do in OSes like Plan9 or Brazil, although AFAIK existing UNIXes like Linux do not make this easy to do. ### Details As is my wont, I provide way too much background detail for my question. For many people reasonably knowledgeable about security this much detail should not be necessary. But sometimes it may not be clear exactly what I am talking about. Sometimes I may be using incorrect terms. And so on. Hence, I provide all this extra detail hoping to short-circuit misunderstandings. If you truly know of an answer to my question, you can probably stop without reading all the rest. Heck, I might as well admit it: I'm trying to short-circuit stupid nonanswers to my question. But previous attempts to do this I'm not always been successful. ### Motivating Example: gmi/lieer access to gmail uses an unencrypted credential file E.g. lieer, a program to synchronize gmail with local storage, stores an unencrypted credentials file for Gmail in the filesystem. This file, .credentials.gmailieer.json, is completely unencrypted ordinary plaintext. > Excerpting: > gmi init will now open your browser and request limited access to your e-mail. > … > The access token is stored in .credentials.gmailieer.json in the local mail repository. If you wish, you can specify your own api key that should be used. Of course file system permissions should make it accessible only by my UNIX login id. It is used by the gmi/lieer program to access my gmail account. But unless I am totally missing something, any program running as me can access this file. E.g. one of the umpteen sandbox escapes in web browsers might allow it to access this file. Or I might have filesystem permissions set incorrectly. Or I might have misconfigured filesystem/disk encryption, and other user IDs on my machine may be able to access it. Etc. I thought that it was standard/best practice for security that plaintext secrets should never be stored on disk. I have long been somewhat surprised by how many software systems require credentials like API keys to be stored on disk. I have usually avoided using such systems, although it gets in the way of doing things like Google API development that require such API keys. Or I might use such systems or work, but resist using them for stuff that is personal. However, I really do want to use such systems for personal stuff. Not just personal software development, but for gmi/lieer access my Gmail account, which is about as personal as I can get, much more sensitive to me than a GitHub project. This is not just an issue with gmi/lieer. Many programs, many software systems, require you to store credentials like API keys on disk. I don't think I've encountered any of them that keep them encrypted on disk. Except, of course, for ssh/ssh-agent and gpg/gpg-agent, where the credential files are protected, not only protected by file system permissions, but also by a passphrase, and are decrypted only within the ssh-agent's process memory. #### ssh-agent => no plaintext credentials on disk Except, of course, for ssh/ssh-agent and gpg/gpg-agent. + Where the key files are protected + not only protected by file system permissions, but are also encrypted by a passphrase. * When you load an ID into ssh-agent * it asks you for the passphrase, * reads the encrypted key file(s), * and decrypts them into it's process memory. * ssh-agent is persistent, so you only have to do this once in a while * ssh, if configured appropriately, * won't be able to run without asking ssh-agent to "do stuff". * communicates yo ssh-agent via a UNIX domain socket * ssh-agent actually does all or most of the public key computations * => ssg itself does not have the private keys I thought that it was standard/best practice for security that 1. Plaintext secrets should never be stored on disk * with the possible exception of swap files, * but that should be a solved problem * so even if someboday can access the raw data on disk you should be safe * e.g. if you don't have full disk or filesystem encryption * and the disk drive is accessed outside of its "home" OS 2. Plaintext private keys may be stored in ssh-agent's process memory * not in the ssh client program * and should not be accessible by any other programs, * even running as the same user in the same machine * possibly also not by more privileged users like root or admin * with the possible exception of debuggers * but that also should be a solved problem (although not so much in my experience) #### Going beyond ssh-agent… Skip this section, It isn't really necessary for my question, except it helps me organize the issues in my mind. Also, if somebody can tell me that these items (3) and (4) below are in much wider use and I currently know, I'd love to hear about it. Items (1) and (2) are, AFAIK, the state of the art, or at least practice. But they leave some hardware/logic analyzer security holes vulnerable, which have been addressed by certain academic and industry projects, but which as far as I know are much less common: 3. In most present-day systems plaintext secrets may be stored in DRAM + unless the programmer has been very careful to keep them only in registers + and has control of context switches that might save the registers to memory + but various hardware memory encryption proposals and products prevent even this from happening + e.g. data may be stored unencrypted in cache, but may be encrypted between cache and DRAM. 4. and similarly various proposals and products ensure that all of the traffic on buses and connections etc. where you could attach a logic analyzer are encrypted. * 2.5: I'm actually a little bit uncomfortable that the ssh client/agent communication is done via a UNIX domain socket + AFAIK any process running with the appropriate user ID can access that socket, and can get the ssh-agent to do stuff + AFAIK the UNIX domain socket is protected only by filesystem permissions + AFAIK the ssh-agent and ssh program do not talk via an encrypted channel + Although the fact that the UNIX domain socket can be somewhat random reduces exposure. And I know that some operating systems - not standard LINUX, AFAIK - allow permissions to be restricted not just by user ID but also by executable ID, or position in the process tree. + You can of course use JNIX user IDs to accomplish this, but as far as I know this is not commonly done. #### Example: plaintext file containing gmail credentials for gmi/lieer credential gmi/lieer, a program to synchronize gmail with local storage, stores an unencrypted credentials file for Gmail in the filesystem > Excerpting: > gmi init will now open your browser and request limited access to your e-mail. > … > The access token is stored in .credentials.gmailieer.json in the local mail repository. If you wish, you can specify your own api key that should be used. The credential lieer stores looks like the below. I hope that I have edited out anything that is sensitive. "Gibberish" is of course what looks like random letters and numbers with occasional punctuation, the sort of stuff one associates with a credential. {"access_token": "xyzzy ~200 bytes of gibberish", "client_id": "~40 bytes of gibberish.apps.googleusercontent.com", "client_secret": "~20 bytes of gibberish", "refresh_token": "~100 bytes of gibberish", "token_expiry": "2024-09-15T07:16:24Z", "token_uri": "https://accounts.google.com/o/oauth2/token ", "user_agent": "Lieer", "revoke_uri": "https://oauth2.googleapis.com/revoke ", "id_token": null, "id_token_jwt": null, "token_response": {"access_token": "~200 bytes of gibberish", "expires_in": 3599, "scope": "https://www.googleapis.com/auth/gmail.readonly https://www.googleapis.com/auth/gmail.modify https://www.googleapis.com/auth/gmail.labels ", "token_type": "Bearer"}, "scopes": ["https://www.googleapis.com/auth/gmail.labels ", "https://www.googleapis.com/auth/gmail.readonly ", "https://www.googleapis.com/auth/gmail.modify "], "token_info_uri": "https://oauth2.googleapis.com/tokeninfo ", "invalid": false, "_class": "OAuth2Credentials", "_module": "oauth2client.client" } This is completely plaintext, although of course it is accessible only by my Linux user id. It is used by the gmi program to authenticate to gmail. If not present, I cannot acces my gmail. I don't get asked for my password, etc. Unless I am missing something, this credential could allow almost any program that can read this file to access my Gmail. this concerns me. It's not just gmi/lieer -- many programs. I'm not going to bother listing more examples. But just googling API KEY should yield a lot of them. ### Is it just obsolete legacy software? Possibly, but IMHO not completely. E.g. the gmi/lieer source code and/or documentation indicates that it using an old Gmail API, and should be upgraded. Possibly more recent APIs solve this problem - but not as far as I can tell. Possibly there is already a generic OpenAuth-agent - but not that I can find. AFAICT Google really prefers to keep the OpenAuth stuff in its own libraries, used by Google Chrome and other web browsers, and has not really done much to support command line or other non-browser utilities. They would really prefer that you did not use such utlities, unless Google wrote them. They only grudgingly support such utlities, allowing you to obtain API KEYs, etc. If there are security holes caused by storing such credentials unencrypted on disk, they will just use that as more evidence to justify locking things down, and locking other software out. Anyway: If there is a generic OpenAuth-agent (probably not called that) - I would love to hear about it. But anyway, furthermore: even if there is a generic OpenAuth-agent, there are a lot of existing programs that assume an unencrypted creditials file on disk. There would be value in having a generic solution fir these, until they can be upgraded. Assuming they can be.

I just installed arch, and I am trying to configure my shell, zsh. I am currently using zinit as my plugin manager with powerlevel10k. I was trying to automate the activation of the ssh-agent and the addition of keys to it. This is my current .zshrc file:

neofetch

# Enable Powerlevel10k instant prompt. Should stay close to the top of ~/.config/zsh/.zshrc.
# Initialization code that may require console input (password prompts, [y/n]
# confirmations, etc.) must go above this block; everything else may go below.
if [[ -r "${XDG_CACHE_HOME:-$HOME/.cache}/p10k-instant-prompt-${(%):-%n}.zsh" ]]; then
  source "${XDG_CACHE_HOME:-$HOME/.cache}/p10k-instant-prompt-${(%):-%n}.zsh"
fi

# Set the directory to store zinit and plugins
# ---  Defined in the .zshenv file

# Download Zinit if it's not there yet
if [ ! -d "$ZINIT_HOME" ]; then
    mkdir -p -- $ZINIT_HOME:h
    git clone https://github.com/zdharma-continuum/zinit  "$ZINIT_HOME"
fi

# Source/Load zinit
source "${ZINIT_HOME}/zinit.zsh"

# Add in Powerlevel10k
zinit ice depth=1; zinit light romkatv/powerlevel10k

# Add in zsh plugins
zinit light zsh-users/zsh-syntax-highlighting
zinit light zsh-users/zsh-completions
zinit light zsh-users/zsh-autosuggestions
zinit light Aloxaf/fzf-tab

# Add in snippet
zinit snippet OMZP::git
zinit snippet OMZP::sudo
zinit snippet OMZP::archlinux
zinit snippet OMZP::command-not-found
zinit snippet OMZP::ssh-agent

# Load completions
autoload -U compinit && compinit

# Replay all cached completions ( recommended by documentation )
zinit cdreplay -q

# To customize prompt, run p10k configure or edit ~/.config/zsh/.p10k.zsh.
[[ ! -f ~/.config/zsh/.p10k.zsh ]] || source ~/.config/zsh/.p10k.zsh

# Keybind - emacs style, enables ^f ^b ^a ^e ...
bindkey -e
bindkey '^p' history-search-backward
bindkey '^n' history-search-forward

# History
# -- some changes already in .zshenv file
setopt appendhistory # append to history file instead of overwritting
setopt sharehistory  # share command history between sessions
setopt hist_ignore_space # ignore commands starting with space 
setopt hist_ignore_dups
setopt hist_ignore_all_dups
setopt hist_save_no_dups
setopt hist_find_no_dups # Don't show duplicates in history search

# Completion styling
zstyle ':completion:*' matcher-list 'm:{a-zj}={A-Za-z}'
# Set the default colors to LS_COLORS
eval "$(dircolors -b)"
zstyle ':completion:*' list-colors $LS_COLORS
zstyle ':completion:*' menu no
zstyle ':fzf-tab:complete:cd:*' fzf-preview 'ls --color $realpath' 
zstyle ':fzf-tab:complete:__zoxide_z:*' fzf-preview 'ls --color $realpath' 
  # ssh-agent configurations
zstyle :omz:plugins:ssh-agent quiet yes
zstyle :omz:plugins:ssh-agent lazy yes
zstyle :omz:plugins:ssh-agent agent-forwarding yes
zstyle :omz:plugins:ssh-agent identities ~/.ssh/github_rsa

# Aliases
alias ls='ls --color'
alias c='clear'
alias b='cd ..'

# Shell integrations
eval "$(fzf --zsh)" # Fuzzy finding
eval "$(zoxide init --cmd cd zsh)"

As you can see, for ssh-keys I am using: zinit snippet OMZP::ssh-agent and the following settings:

zstyle :omz:plugins:ssh-agent quiet yes
zstyle :omz:plugins:ssh-agent lazy yes
zstyle :omz:plugins:ssh-agent agent-forwarding yes
zstyle :omz:plugins:ssh-agent identities ~/.ssh/github_rsa

~/.ssh/github_rsa is the location of a valid key and has no password associated with it. My ~/.ssh/config file is super simple. It only contains the line AddKeysToAgent yes. ---- Initially the problem I was facing was that no key was added to the agent. Now, after some testing I found that the key only gets added to the agent if it has the default name id_ed25519, otherwise nothing happens ( at least with the values I tested for ) . I couldn't test the loading of more than one key since they need to have different names, which means, different from the default which by my tests, doesn't work. As suggested, I tried removing the setting zstyle :omz:plugins:ssh-agent lazy yes even if not recommended when using powerlevel10k. Weirdly enough, if the key has the default name it gets loaded anyways

Running Plasma 5.27.10 on Debian testing/trixie. An ssh-agent is launched via user service /usr/lib/systemd/user/ssh-agent.service and its socket is exposed in my session's environment variables. All good so far. OK situation: when I start a terminal program (e.g. XTerm, zutty, Konsole) via the Application Launcher ("Plasma Start Menu") the ssh-agent variables are exposed in the bash environment as expected:

$ export | egrep SSH
declare -x SSH_AGENT_LAUNCHER="openssh"
declare -x SSH_AUTH_SOCK="/run/user/1000/openssh_agent"

Not OK situation: if, however, I start the _same_ terminal program using a shortcut key (configured in System Settings -> Shortcuts) the bash environment has changed. A few environment variables have disappeared but what most concerns me is the loss of ssh-agent socket export:

$ export | egrep SSH

Obviously all SSH connections in this terminal instance start asking me for the password to my private key file, which is counter-productive. Why is Plasma removing ssh-agent's environment variables when launching an app via shortcut? More importantly, how do I stop it from doing that? ------ _Extra details, possibly not relevant._ List of variables that are _removed_ from shortcut-launched environment (compared to Application Launcher):

FONTCONFIG_PATH="/etc/fonts"
GTK2_RC_FILES="/etc/gtk-2.0/gtkrc:/home/user/.gtkrc-2.0:/home/user/.config/gtkrc-2.0"
GTK_RC_FILES="/etc/gtk/gtkrc:/home/user/.gtkrc:/home/user/.config/gtkrc"
SESSION_MANAGER="local/nut:@/tmp/.ICE-unix/1583,unix/nut:/tmp/.ICE-unix/1583"
SSH_AGENT_LAUNCHER="openssh"
SSH_AUTH_SOCK="/run/user/1000/openssh_agent"

List of variables _added_ in a shortcut launched environment (compared to Application Launcher):

KGLOBALACCELD_PLATFORM="org.kde.kwin"
QSG_RENDER_LOOP="basic"

ssh-add alone is not working: Error connecting to agent: No such file or directory How should I use that tool?

Running Fedora on WSL2, I find that the socket activation on ssh-agent doesn't quite work properly: the first request that triggers the actual service starting fails. This may be a git fetch or git pull request, or else an ssh-add call. This shows up as a long timeout on the client call rather than as an immediate failure. Because the systemd config contains both ssh-agent.socket *and* ssh-agent.service, attempting to disable ssh-agent.socket and enable ssh-agent.service directly doesn't work, as it just turns the socket activation back on rather than configuring the service to start automatically:

~$ systemctl --user is-enabled ssh-agent.socket
enabled
~$ systemctl --user is-enabled ssh-agent.service
indirect
~$ systemctl --user enable ssh-agent.service
~$ systemctl --user is-enabled ssh-agent.service
indirect
~$ systemctl --user disable ssh-agent.socket
Removed "/home/acoghlan/.config/systemd/user/sockets.target.wants/ssh-agent.socket".
~$ systemctl --user enable ssh-agent.service
Created symlink /home/acoghlan/.config/systemd/user/sockets.target.wants/ssh-agent.socket → /usr/lib/systemd/user/ssh-agent.socket.

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 have ssh keys set up and I can see my key in KWalletManager under ksshaskpass. How do I get it so that I am not asked for my ssh passphrase eg. every time I do something in Git. (It says: "Enter passphrase for key ...") What I would like is that my KDE login is the only time I am asked for a password (as in Cinnamon and Gnome). I guess that this should result in some kind of interaction between KWallet and ssh so that my passphrase is auto-entered into ssh. I've tried searching for information but could not find a step by step solution for Kubuntu. What do I need to do?