What DE are you using. There is an extension for Gnome to remove title bars.
I don’t use KDE, but i am sure that they have something similar.
I get the feeling that “the thing” refers to GNOMEs top bar that is adapting to the applications main menu (I don’t know how they formally call it).
But then again even after reading that post 5 times I’m not sure.
Screenshot might be in order.
2 Likes
OK, so here’s my issue. I’ll try to explain it intelligently, but remember, I am just starting to understand linux.
I have Proxmox installed (Debian based) and it is running Plex in a LXC container. In order for Plex to be able to use my GPU it is passed through to the container. In order for this configuration to work properly both versions of the drivers (IE on Promox main host and LXC) have to be exactly the same or the calls for work aren’t interrupted correctly and it breaks the pass through.
I looked into disabling the or putting on hold the package for the driver. My problem is it isn’t on the list. I believe that is because I installed it manually from a .run file to get it to install correctly the way I need (IE the LXC needs it to be installed without the kernel module etc).
I know that my buster-backports repository is the source of the driver that is being installed.
I need some help in “identifying and ignoring” that particular driver. Is this even possible?
I know I should be able to use apt-mark hold or some derivative, but I’m still learning. I did some google searches but they all apply to if the package is listed and installed…
I appreciate your help.
Are you running the official proprietary driver? If so, then you will probably need to run that on both the host and the LXC. Is there a reason why you cannot upgrade/downgrade the Kernels to the same version and drop the proprietary kernel?
1 Like
Yes I was, and am using the Nvidia proprietary driver. I just installed it on both the server and LXC after completely removing the nvidia drivers with sudo apt-get remove --purge '^nvidia-.*' then re-installing.
It was my error. I thought I had used the backports driver so I tried that route and it failed. It was also on my to-do list for the server I overlooked. So it was a double install causing errors in versions, and a problem that has been there since I did the forced updates for packages on Proxmox to update the other programs such as ZFS.
All in all it was fixed when I followed my playbook I had and didnt use the backports version. Thanks for the help I forgot to update here.
1 Like
My SSH Agent on Fedora doesn’t seem to remember the keys I add to it… or at least one (I don’t really use any others), and I don’t really know why.
I was following GitHub’s guide (since it’s to push into my repos there):
After doing the ssh-add step the push works fine, so access rights are all good. But after a PC restart I get permission denied again, need to re-add my keys (that are still there, I don’t move them obviously 
). How do I make it remember? 
Gnome, and KDE too, run their own key management daemons. These replace ssh-agent. You want to add your keys to these and set them to unlock on login.
For Gnome the app is Seahorse.
Hm I think that would be KDE Wallet then? Just checked it and honestly no idea how to even add stuff to that, and the stuff that’s already there I have no idea how it got there (it’s also none of my actual passwords lol).
Funny enough when I search for KDE Wallet and SSH Keys, I find a guide from Solus:
https://getsol.us/articles/software/kwallet/en/
That’s just suggesting to use an autostart-script to add the key on startup… but that can’t really be the point of the SSH agent, right? I thought it’s supposed to store them 
edit:
Also to be clear, the identities completely disappear from the ssh-agent, it’s not just that it isn’t started on login or anything:
[tarulia@localhost]~% ssh-add -L
The agent has no identities.
I don’t think that’s how that’s supposed to work? Unless I’m misunderstanding what the SSH Agent is supposed to do…
The identities are only stored in RAM. They need to be loaded from disk and decrypted using the passphrase.
Mine are autoloaded by Gnome and I think it happens without me noticing because I used the same passphrase as my login password, and that may be done automatically.
But you can also add keys with different passphrases.
I get that with the passphrase, but as I understand it that message above it means the keys are not even added. If they were added it should simply ask me for the passphrase first time I use that identity, no? Or am I misunderstanding the whole concept of the ssh-agent?
I thought it was adding the keys, and then using it automatically whenever needed, asking for the password if it hasn’t already been provided previously…
From what I can tell though the agent doesn’t even know the keyfile exists until I readd it, much less uses it
Nope. That is not how ssh-agent works.
You can get what you want with Gnome or KDE though, and their key handlers.
2 Likes
If you already tried it with KDE and it didn’t work for you, sorry. I don’t know what to say. I haven’t used KDE in several years and maybe it depends on the distro. I think I was using a Ubuntu based KDE, and it seemed to pick up my SSH keys automatically. But like I said, it’s been a while.
This is how ssh-agent works. It doesn’t persist beyond the shell session in which it’s called. It’s intended to prevent having to re-enter the password within a single session.
That said, people do things like wrap their window manager in ssh-agent so that it will persist through a GUI login. Here is an example of this in an xinitrc file (not applicable to you, but just to illustrate):
2 Likes
Please excuse my ignorance, but could you use
ssh-copy-id
To copy the key file?
I am not sure about just adding for a session; I only play with boxes I permanently own.
Again, this might not be for the task/workflow you are asking for, I just use it to ssh into boxes without needed to provide a pass phrase every time
1 Like
Is that working for you across reboots? I haven’t used it in a while (use yubi) but I remember having to put the password in on each shell session.
Yeah. Persistent. I am reasonably sure I used a passphrase when generating the key set, and I need to have already configured my user on the target, but in copy, it only asks for my remote login pass, not the ssh key.
Looking on the web, it looks like maybe a key generated without a passphrase would work with ssh-add, but it might still need to be added every boot?
I’m just a home gamer 
and if wrong, let me know
Keys with Passphrases
If the key being added has a passphrase, ssh-add will run the ssh-askpass program to obtain the passphrase from the user. If the SSH_ASKPASS environment variable is set, the program given by that environment variable is used instead.
From random website Ssh-add program usage with ssh-agent and SSH keys. How to enable SSH public key authentication and single sign-on.
I think I might be failing to get my point across here.
I don’t have an issue entering the password when I want to use the key, I know that that’s by design and that’s fine with me.
My issue is that the agent doesn’t even know the key, hence can’t ask me to enter a password. I (again) would be fine entering the password to use the key, but I don’t get to that step in the first place because the agent forgets that the key exists after a reboot.
And either I misunderstand what the agent is supposed to do or I just can’t express what my issue is 
This is what I thought, but I have to add the key every time instead of just entering my password.
I’ll try that later, thanks.
This is a permanent box (daily system) that I every once in a while need to push a git branch to my GitHub.
1 Like
So i just read the manpage on that command and please correct me if I’m wrong, but it doesn’t seem like this is what I’m looking for or what would solve the issue.
First off I’m not sure that would work in the case of GitHub. From the description it seems it is copying the keys from local to the remote, to login there, but I can’t imagine GitHub allowing that?
It assembles a list of one or more fingerprints (as described below) and tries to log in with each key, to see if any of them are already installed
Well herein lies the first issue: I can’t login even though the key is known to GitHub, because the (local) ssh-agent forgets it exists. When doing ssh-add <keyfile>, the login with GitHub works again (after of course entering the password).
It then assembles a list of those that failed to log in, and using ssh, enables logins with those keys on the remote server.
But I don’t have any other keys installed (because I didn’t need any), so that wouldn’t do anything (again, if GitHub even allowed that, since they handle this over their webinterface).
1 Like
yeah, no, I suggested the wrong tool for the job. my bad man
1 Like
ssh-agent does not remember what keys you’ve loaded between restarts. It is not designed to do so. It makes no attempt to do so.
After loading ssh-agent you need to do an ssh-add on each key you want loaded, and you must enter the correct password at the time of loading it.
If you install a graphical ssh-askpass program like openssh-askpass, it’ll typically automatically load keys in the few default locations (i.e. $HOME/.ssh/id_rsa) and prompt you for a password if needed, but it won’t look for more.
Personally, I script ssh-agent and ssh-add at login. It takes consider effort to share the same ssh-agent between my desktop, my remote SSH sessions into the same box, virtual consoles, etc, but it can be done, and is worth the effort for me.
Assuming you don’t want to script it, you might be happier with specifying an IdentityFile in $HOME/.ssh/config, and using the AddKeysToAgent option. e.g.
Host myserver9 Hostname server9.example.com IdentityFile $HOME/.ssh/id_github1 AddKeysToAgent yes User mihawk Compression yes
See: man ssh_config for all the details of this, and hundreds of other options.
3 Likes