I can not remove gcr as it would break some of my apps that use gnome-keyring. I believe this is happening independently of that. I havenāt had that app (requiring gcr) installed before and still this was an issue.
Yeah, I can confirm. Killing gcr does not change anything. I have also tried to restart ssh-agent after killing gcr and nothing changes.
SSH_AUTH_SOCK points to non-existing ssh-agent pid.
ls /tmp/ssh-*/agent.*
/tmp/ssh-cxKJ50y1bONH/agent.152578 /tmp/ssh-SM7TDO6GPDMm/agent.144124 /tmp/ssh-vt37l1auORoj/agent.144070
$ ps aux|grep ssh
x 152579 0.0 0.0 8436 3620 ? Ss 13:40 0:00 ssh-agent
x 152843 0.0 0.0 9212 2220 pts/5 S+ 13:42 0:00 grep --color=auto ssh
These are pids that do not exist, there is no agent pid that actually is running.
Why is that?
It is started automatically on login via .bashrc same as it was on my previous computer.
I am testing via any graphical app such as Filezilla or Git Cola (git repos via SSH). None of these work seamlessly, but pop up a password input for each key.
I havenāt used Bash in ages but in ZSH the ..zshrc is only read by interactive shells, e.g. in a terminal.
It is not read by the login shell and thus environment set by it will not be part of what the Plasma session āseesā.
You could check by running env > /tmp/env.txt in KRunner (ALT+F2) and then looking at that file.
Yeh thatās likely the problem. Unless youāve got something very fancy there, and my powers of mental telepathy arenāt working.
As krake said, if you want Plasma to see it, you need to start it in a way that the var will be seen by Plasma. Putting it in bashrc means itās only seen by that one shell. This is why youāre seeing multiple PIDs and multiple instances.
There are two commonly advised ways to do it. One is a systemd service, the other is a shell script in ~/.config/plasma-workspace/env directory. If you run a web search for āssh-agent autostart KDEā, youāll find examples.
Relatable, sorry. My search engine threw up an AI answer for me at the top, but I know thereās a lot about how this fails, out there.
It will work on KDE login but not SDDM - This is why I use a systemd service, but that being said, itās harder and you probably donāt actually need that (turns out I donāt either) so I guess the env script is a good way to go.
When we say āit will workā this command isnāt one Iām familiar with, I just start ssh-agent, so YMMV. I took a look at the manpage and I see that it doesnāt actually set the environment var, but rather, outputs a shell script to a known location, such that subsequent shells can source that script to set the var for themselves. That, aināt gonna get the result you want.
It seems like if you wanted to use that app, youād follow the manual:
keychain is a manager for ssh-agent, typically run from ~/.bash_profile.
When keychain is run, it checks for a running ssh-agent, otherwise it starts one. It saves the ssh-agent environment variables to ~/.keychain/${HOSTNAME}-sh, so that subsequent logins and non-interactive shells such as cron jobs can source the file and make passwordless ssh connections.
Source that file from that kwin env script.
I think? Honestly Iāve never seen this app before. Iām pretty sure that would work. The second part Iām sure about because thatās exactly right according to the manual. The first part Iām not certain because Iām not sure that the bash_profile will execute, and run keychain and create the shell script, prior to kwin attempting to source it? Probably.
Sorry, reading more, it seems like you could be using --eval with keychain, then it will output the commands to set the vars and you can run them with eval (this is more like how OG ssh-agent works). To steal an example from the Arch wiki you linked and meld it with the last command you showed:
So, no. Putting that line in ~/.config/plasma-workspace/env/ssh-keys.sh made KDE to stop booting and SDDM login would be shown after some time again. I had to delete that file.
Iāll have to leave keychain for shells and use something else for KDE.
A point of warning here. Scripts in there may be sourced by sh. On Ubuntu-derived, and I imagine debian-derived, systems this is dash; I donāt know what sh is on Manjaro. Any shebang is ignored, and if sh is not bash any bashisms cause the script to terminate silently.
I am on Neon, but I think itās the same. Hopefully Iāll be able to find some solution to this as it is a bit annoying that KDE is unaware of ssh-agent running.
Thatās not necessary, and wonāt really work very well. You just need to figure out how to start this application correctly. Just because this one first try wasnāt correct, doesnāt mean itās time to give up.
Because I am on Neon as well but on X11 and here ssh-agent is started by the X session setup regardless of which desktop is being started and without any config of my own.
Yeh youāre right it is POSIX spec. Turns out they both are, nowā¦ I am just confused.
I happened to be learning the linux shell when BASH was the new hotness and frequently replacing Bourne sh and we had to learn three different ways to do it depending on which version of which shell it was. The whole experience just left me going 'idk Iāll just try the other one if one fails" I thought you were trying to politely tell me Iād screwed it up but I guess the original should work, too.
Based on what krake is saying though, it sounds like on Neon, ssh-agent is standard, so maybe trying to get keychain to work isnāt the best option.
I thought you were trying to politely tell me Iād screwed it up but I guess the original should work, too.