Authentication Problem, Software Boutique and Synaptic

I am told I don't have the required privileges to perform installation through Software Boutique; Synaptic not even starting. I did mess with the passwords when tired, so I may just need to delete the file requiring the password--keyring not unlocking, so I ran command to remove the file

rm ~/.local/share/keyrings/login.keyring

I have no problem with the sudo password, but the keyring that is asked for when logging in, I do not know, since I was tired. It is weird that Synaptic doesn't start now--it used to give me a message when opened that I cannot install software, maybe it's pk-exec file.

org.freedesktop.PolicyKit.Error.Failed: ('system-bus-name', {'name': ':1.161'}): org.debian.apt.install-or-remove-packages

the error listed when "Details" is clicked on.

Personally, I would try re-installing the synaptic package via command line

sudo apt-get reinstall synaptic

It would likely have logic to get the required keyfiles as part of the install, and use the existing package info files for what is installed already.

If that doesn't work, you need to "rebuild" the keyfiles. You might be able to locate that on the Distro install disk. If not, you might need to start by downloading a "template" file from Ubuntu's main image repository, then tweak for your preferred mirror site(s).

Someone else could have a better alternative to solve your issue. I'm not an expert. :slight_smile:

N.B. Do not perform a complete un-install before the re-install. That would "hose" your installation.

2 Likes

It seems your credentials / sudo / authority are broken. I recommand to not try to repair. You should reinstall UM. These things are too fragile to repair.

3 Likes

Do you still have a policykit agent among your startup applications?

1 Like

I guess I should tick the Policy Authentication Agent as the screenshot shows? I also have the SSH keyring unchecked--would ticking this option make the recurring prompt disappear? the Secret Storage Service is unchecked too.

1 Like

On my un-modified installation, I have the following related Apps selected in "Startup Applications":

  • Certificate and Key Storage
  • PolicyKit Authentication Agent
  • Secret Storage Service
  • SSH Key Agent
3 Likes

Yes, you have to enable it. I think, this can fix your org.freedesktop.PolicyKit.Error.Failed error. Have you disabled this agent earlier? Do you still have the mate-polkit package installed?

apt list --installed | grep mate-polkit

Also, revert to the defaults mentioned by @ericmarceau and test your system.

Do you have autologin enabled?

3 Likes

Hi. Yes, autologin is active--I'm the only person using this computer and for cybersecurity, I figure all they have to crack is the password to the router; would requiring my password at login do enough to make it difficult?

anthony@anthony-OptiPlex-9010:~$ apt list --installed | grep mate-polkit

WARNING: apt does not have a stable CLI interface. Use with caution in scripts.

mate-polkit-common/jammy,now 1.26.0-1 amd64 [installed,automatic]
mate-polkit/jammy,now 1.26.0-1 amd64 [installed]

@ironfoot Cool, thanks. Everything is working now for Boutique and Synaptic--and the Keyring prompt is gone. The only thing is that the Advanced Menu still does not work. The file and folder .config/mate-menu/applications.list is still there, though. What about the autologin--should I require it for security, even though I'm the only one here?

As long as you have

  • denied remote-login as root
  • denied sudo from remote session

the need for a login password is to protect the contents of your computer from inexpert interlopers in your residence.

To protect from expert interlopers, or computer thieves from accessing your disk, you need a BIOS boot password.

I have inserted the following at the end of my /etc/security/access.conf:

#############################################################################
#############################################################################
#
###	Permit root login from local			### Look at /etc/hosts for host IP aliases
+:root:LOCAL localhost OasisMega1
#
###     Permit designated users to access from local
+:ericthered:LOCAL localhost OasisMega1
#
###     Permit all local services/users to access from local
#+:ALL:LOCAL localhost OasisMega1
+:ALL:LOCAL ALL
#
###	Deny access to all from any remote
-:ALL:ALL

And again, the following appended to /etc/ssh/ssh_config:

###     Group 1 - Restrictive
    PermitRootLogin no                          ## OasisAdmin
    ForwardAgent no                             ## OasisAdmin
    ForwardX11 no                               ## OasisAdmin
    ForwardX11Trusted no                        ## OasisAdmin
    DenyUsers root                              ## OasisAdmin
    DenyGroups root                             ## OasisAdmin

###     Group 2 - Permissive
    AllowUsers nonexistent                      ## OasisAdmin
    AllowGroups nonexistent                     ## OasisAdmin

###     Deploy any modifications using:  systemctl restart sshd

... And, let's not forget /etc/ssh/ssh_config.d/ssh_client.conf:

###     CLIENT - Group 1 - Restrictive

### REF:	https://www.digitalocean.com/community/tutorials/how-to-harden-openssh-client-on-ubuntu-20-04
ForwardX11 no
ForwardX11Trusted no
Tunnel no
ForwardAgent no
GSSAPIAuthentication no
HostbasedAuthentication no
# SendEnv
StrictHostKeyChecking ask

###     CLIENT - Group 2 - Permissive


Lastly, appending the following to /etc/ssh/sshd_config.d/sshd_server.conf:

###     SERVER - Group 1 - Restrictive
Ciphers -arcfour*,-*cbc,-ecdhe-*-aes128-sha256,-ecdhe-*-aes256-sha384

DenyUsers root
DenyGroups root
PermitRootLogin no

###     SERVER - Group 2 - Permissive
AllowUsers nonexistent
AllowGroups nonexistent
1 Like

Thanks for the excellent info. I can copy/paste the code to the files you mentioned to make my machine more secure, even though it's my machine and not yours?

denied remote-login as root
denied sudo from remote session

I did a search for remote-login and found settings in Login window; I don't think that's what you meant with those two commands. What about these two settings--what files would I need to edit?

You need to replace any reference to OasisMega1 or OasisMini with your own hostname identifier string.

Other than that, those are applicable generally, unless you want to modify your accessibility from remote. If that is what you want to do, then you have to look to someone else for guidance on howto. :slight_smile:

Those were conceptual descriptions, not literal references.

The first of those two is implemented in /etc/security/access.conf with the first line forcing only localhost login for root and not allowing any SSH from remote using the first line in /etc/ssh/ssh_config.

The second is, I believe, implemented in both /etc/ssh/sshd_config.d/sshd_server.conf and /etc/ssh/ssh_config using "DenyUsers root".

Others with a deeper knowledge can confirm if those are the minimum definitions required to control the sudo from remote.

However ... this article has much which I never pursued, which could harden the installation even more, specifically for sudo.

1 Like

As long as you have

  • denied remote-login as root
  • denied sudo from remote session

I found really good instructions for the remote-login concern

Disabling remote-login

and this for Denying sudo from remote session

Denying sudo for remote login

The others I will do, too, just for fun to mess with the computer. These four files, I'm wondering how those steps compare to what is possible with Ubuntu Pro--the OS mentions something about two options under Ubuntu Pro that hardens the computer to government-level, I think. Thanks again for the great information.

I am not asking about autologin to check your 'security'. When your lightdm autologin is activated, your login.keyring is not unlocked automatically because you don't enter your password. Some apps may want to access your login keyring, and you may see a prompt to unlock it.

Simply copying and pasting something from the Internet and applying it to your system is not a path to security, it is a path to disaster. You must understand what you are doing. @ericmarceau has posted some configs for SSH server, but Ubuntu desktop system does not even have SSH server preinstalled (only SSH client).

2 Likes

@ironfoot I modified those files because @ericmarceau suggested them--I see he's a regular, like you--experts about Ubuntu,. Maybe you don't see it that way, but I do. Since I view him as another expert trying to help people, he told me to remove the hostname and change it to mine, and I did see his name later in the code (I think that I didn't see the characters, as the letters were tiny and I have bad eyes). I just didn't see it--it would have been obvious to change it, so I don't expect that was untoward. So since he's a regular and expert, like you, the code is fine to attach to my files, isn't it? It's not like I found them from a Google search.

Yes, as Chrome or Brave, with autologin enabled. Then, we can have another issue, for exemple:

That's why, today, I recommand to disable autologin.

3 Likes

Please ... do not consider me an expert! I am far from it.

I am only a retired experienced user/admin sharing experiences from the school of hard knocks ... and some of that knowledge becomes dated over time in both applicability or relevance. That is why I often make the comments (when I think other opinions may be more closely aligned with your needs) like I did above:

1 Like

Philippe, I'm grateful that you've shared the reference that added reason to my instinctive choice to avoid autologin!

3 Likes

Hi @ericmarceau but you all say this :smile:

Someone else could have a better alternative to solve your issue. I'm not an expert. :slight_smile:

  1. The sync procedure wants your keyring unlocked.
  2. You cancel the request.
  3. It doesn't sync.

This makes sense because the browser may need to sync saved passwords or whatever it stores in the keyring.

2 Likes