So, this seems to be the last one post in the whole series about passwords and SSH management in Linux.
The previous parts were about:
- Linux: the Nextcloud client, qtkeychain and the “The name org.freedesktop.secrets was not provided by any .service files” error – I found that a keyring service is able to store SSH keys passwords – and got to know that Chromium stores passwords in an “unencrypted way”
-
Linux: KeePass, SSH и хранение паролей RSA-ключей (in Russian yet, to be translated soon)
– how to work with the
ssh-agent, a bit about its integration with KeePass to store SSH keys passwords - What is: Linux keyring, gnome-keyring, Secret Service, and D-Bus – what is a keyring and how to work with it – recalled, how to work with D-Bus – and a couple of words about KeePass integration as a Secret Service
- Chromium: Linux, keyrings && Secret Service, passwords encryption and store – and finally sorted out – is it true, that Chromium stores sensitive data in a plaintext?
Actually, knowing all of this we can grab them all together and configure normal secrets management on a work laptop with Arch Linux and Openbox DE.
In this post we will configure KeePassXC for:
- a browser integration to store passwords in the KeePass instead of the Chromium’s own SQLite database
- TOTP codes generation for MFA
- will integrate the
ssh-agentwith KeePass to store RSA keys passwords - and will enable Secret Service integration to use KeePass as keyring storage for Linux
Contents
- KeePass vs KeePassXC
- KeePass and a browser’s passwords – KeePassXC-Browser
- KeePassXC MFA TOTP generator
- KeePass and ssh-agent for SSH keys passwords
- sign_and_send_pubkey: signing failed: agent refused operation
- KeePass and Secret Service integration
KeePass vs KeePassXC
I’ll use KeePassXC instead of the KeePass.
In fact, from the very beginning, I switched to the KeePassXC just because by default it looks much better in Linux with Openbox.
KeePass:
KeePassXC:
Also, KeePass is written in C# from Microsoft and under Linux requires mono to work, while KeePassXC is written in C++ (see its repository) and work in easy on any platform – Linux/BSD/macOS/Windows.
Take a look at the thread on Reddit for more details.
As a browser, I’ll use Brave based on the Chromium so there will no difference in a configuration.
KeePass and a browser’s passwords – KeePassXC-Browser
At first, there is a good question – do you really want to switch passwords storage for your browser?
I.e, you have Chromium, it has its own SQLite database, passwords stored there in an encrypted way.
Furthermore, Chromium has no issue with founding credential fields on webpages, but this happens sometimes with KeePass.
On the other hand, when using KeePass – all your passwords (and SSH keys, etc) are always with you, in the same place. Easy to backup/restore, move/share between computers, add to another browser and so on.
So, everybody will decide this himself, but let’s write the KeePass and Chromium integration process.
Go to the Tools > Settings, then to the Browser Integration, enable it:
Find the KeePassXC-Browser plugin, install it:
Go to the Settings:
- Default group for saving new passwords – usually, I’m disabling the default KeePassXC-Browser Passwords and enabling this option to be always asked where I’d like to save a new password as in my database everything is divided over groups
- Activate 2FA/OTP field icons – can enable if actively using MFA, but is it worth to do it? See the KeePass MFA TOTP generator below
- Automatically reconnect to KeePassXC – comfortable to always stay connected to the database, didn’t saw any lags/bugs yet
- Automatically fill in HTTP Basic Auth dialogs and submit them – looks useful, but I wasn’t able to make it works – an HTTP-form window always was displayed
Go back to the plugin, click Connect:
Set a connection name:
Check KeePass about connected browsers:
And it’s done – the icon is green now:
Log in somewhere and KeePass will prompt to save the password:
Save it (New), log in again – and our credentials are here now:
KeePassXC MFA TOTP generator
One more interesting thing – TOTP codes generator in the KeePassXC.
Still, there is a serious question: is it a good solution to enable it?
The main idea behind the MFA authentication is exactly to use two separate services to authenticate you, i.e. login:password from the one side, and a TOTP-code from your MFA on another.
Is it worth to keep them together in the same KeePass database – absolutely about you, but keep in mind that if somebody will get access to your KeePass – then you’ll have no chance for the MFA as the last hope to keep your data secure.
Still, such an option is present, I’m using MFA, so let’s take a look at how to configure it.
During an MFA configuration – chose something like “Show secret key” or “Can’t scan QR“, depending on a service, to see a text code instead of QR code.
Here is an example from the AWS Console:
Save the code, then in your KeePassXC find or update an entry you’d like to configure MFA for, right-click on it – TOTP > Set up TOTP:
And set the Secret Key from AWS:
Save, right-click again – Show TOTP:
And finish MFA configuration in AWS:
Try to log in, but… The button to fill up the TOTP field doesn’t works 
And it didn’t work in Chromium for Gmail too.
Well – the code in the KeePass is generated, so just manually copy it by right click or by using Ctrl+T – and we are done here.
KeePass and ssh-agent for SSH keys passwords
The idea here is to store SSH keys passwords in the KeePass, and access them via ssh-agent without being asked for a SSH-key password.
It is already described in more details in the Linux: KeePass, SSH и хранение паролей RSA-ключей post, but it’s available in Russin only at this moment (will translate it in next couple of days).
Check if ssh-agent is running:
$ ps aux | grep ssh-agent
setevoy 1505 0.0 0.0 5796 456 ? Ss Dec10 0:00 ssh-agent
If no – start it:
$ eval $(ssh-agent)
Agent pid 950428
Check if the $SSH_AUTH_SOCK variable is available, as it will point to a socket used for communication with the agent:
$ env | grep SSH
SSH\_AUTH\_SOCK=SSH\_AUTH\_SOCK=/run/user/1000/ssh-agent.socket
SSH\_AGENT\_PID=950428
Go to KeePass Tools > Settings, enable SSH Agent:
Restart KeePass and add a new key.
Generate it, set a password:
$ ssh-keygen -f /home/setevoy/rtfm-do-prod-setevoy
Generating public/private rsa key pair.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/setevoy/rtfm-do-prod-setevoy.
Your public key has been saved in /home/setevoy/rtfm-do-prod-setevoy.pub.
...
Pay attention that here is the -f used to set a key-file and it is not in the .ssh directory to make it simpler to add to the KeePass.
Check files:
$ ll /home/setevoy/rtfm-do-prod-setevoy\*
-rw------- 1 setevoy setevoy 2655 Dec 11 10:53 /home/setevoy/rtfm-do-prod-setevoy
-rw-r--r-- 1 setevoy setevoy 579 Dec 11 10:53 /home/setevoy/rtfm-do-prod-setevoy.pub
Go back to the KeePass, create a new entry, set any name, and set your key’s password in the Password field:
In the SSH Agent, a key can be added as Attachment, or as External file.
I’d suggest using Attachment as in this case the key will be stored in the database directly, and you’ll not need to copy it over your working/home/etc laptops.
In the same window switch to the Advanced, tab and attach the key file:
Go to the SSH Agent, add the key from the Attachment:
Here, pay attention to the Add key to agent when database is opened/unlocked option – worth to enable it only for keys that are used often and best to keep them less than 5, because when ssh-agent will try to connect to a host – it will try to use every key accessible in the ssh-agent, and SSH server on a remote host can close connection to “prevent a brute-force”.
Okay, try to connect to a host:
$ ssh setevoy@rtfm.co.ua
Linux rtfm-do-production 4.9.0-8-amd64 #1 SMP Debian 4.9.144-3.1 (2019-02-19) x86\_64
...
setevoy@rtfm-do-production:~$
Okay – it works.
Remember, that using this approach ssh-agent must be started beforehand of the KeePass and must export its $SSH_AUTH_SOCK variable in such a way, so KeePass can see it. Check options in the Running ssh-agent with multitype terminals.
I’m using the variant with the systemd service and the socket path will be exported via the ~/.config/openbox/environment file (as I’m using Openbox DE).
My unit-file /home/setevoy/.config/systemd/user/ssh-agent.service:
[Unit]
Description=SSH key agent
[Service]
Type=simple
Environment=SSH_AUTH_SOCK=%t/ssh-agent.socket
ExecStart=/usr/bin/ssh-agent -D -a $SSH_AUTH_SOCK
[Install]
WantedBy=default.target
And environment file – ~/.config/openbox/environment:
export QT_QPA_PLATFORMTHEME="qt5ct"
export SSH_AUTH_SOCK="${XDG_RUNTIME_DIR}/ssh-agent.socket"
The last step just for a bit of comfort – add a “short-name” for the connection to the ~/.ssh/config:
Host rtfm
Hostname rtfm.co.ua
User setevoy
We are not adding IdentityFile at all – ssh-client will ask for ssh-agent about available keys to try to log in, so we are not tied to a key-file on the disk.
Connect now using this short-name:
$ ssh rtfm
...
setevoy@rtfm-do-production:~$
Passwords were asked neither for the user nor for the key – everything is working, as expected.
sign_and_send_pubkey: signing failed: agent refused operation
A short side-note: if you’ll enable the “Require user confirmation when this key is used” option now:
Then during SSH logging in process, sometimes you can see the “sign_and_send_pubkey: signing failed: agent refused operation” error:
$ ssh rtfm
sign\_and\_send\_pubkey: signing failed: agent refused operation
Load key "/home/setevoy/.ssh/id\_rsa": Is a directory
setevoy@rtfm.co.ua's password:
It happens because ssh-agent trying to ask a user for confirmation and uses the ssh-askpass utility which can be not installed in a system:
$ file /usr/lib/ssh/ssh-askpass
/usr/lib/ssh/ssh-askpass: cannot open `/usr/lib/ssh/ssh-askpass' (No such file or directory)
Install the x11-ssh-askpass package:
$ sudo pacman -S x11-ssh-askpass
Re-try log in – and now you must see such a window with confirmation request:
Click on the ОК – and now all works.
KeePass and Secret Service integration
For a better understanding of keyrings in general and the Secret Service in particular cases – I’d strongly recommend you first to read the What is: Linux keyring, gnome-keyring, Secret Service, and D-Bus post.
At a first, let’s make sure we have no Secret Service available in our system – check the D-Bus:
$ qdbus --session org.freedesktop.DBus / org.freedesktop.DBus.GetConnectionUnixProcessID org.freedesktop.secrets
Error: org.freedesktop.DBus.Error.NameHasNoOwner
Could not get PID of name 'org.freedesktop.secrets': no such name
Okay, it’s empty.
Go to the KeePass, Tools > Settings, choose the Secret Service Integration, enable it:
Now, go to the KeePass database’s settings, and in its Secret Service Integration settings specify a collection (team, folder) which will be used to store our secrets:
Also, it’s a good idea now to start KeePass beforehand every other application in the system.
In my case, this can be done with the ~/.config/openbox/autostart file:
xrandr --output HDMI-1 --primary
xrandr --output eDP-1 --right-of DP-1
feh --bg-scale /home/setevoy/Pictures/Wallpaper/seryy-kapli-strela-ten-arch.jpg &
tint2 -c /home/setevoy/.config/tint2/setevoy-tint2-90-pecent-bottom-wrk.tint2rc &
polybar -c /home/setevoy/.config/polybar/setevoy-polybar-wrk-bars.conf bottom &
polybar -c /home/setevoy/.config/polybar/setevoy-polybar-wrk-bars.conf top &
sleep 5
keepassxc &
dropbox &
lxqt-notificationd &
xscreensaver &
qxkb &
skypeforlinux &
sleep 5
slack &
...
Run a browser:
$ chromium --password-store=gnome
And in the KeePass’ Tools > Settings check services which are using Secret Service now:
A notification from the KeePass when Chromium tries to access its password to decrypt some passwords in its SQLite database:
But here is another issue: when I’m starting Chromium via gmrun – it’s started with the --password-store=basic instead of the --password-store=gnome, although it has to check if a Secret Service is available and run “gnome” instead of the “basic” storage.
To salve it – read the Arch Wiki and create a ~/.config/chromium-flags.conf file:
--password-store=gnome
Restart the browser, go to the chrome://version/, and check options:
Okay, it worked for the Chromium – but Brave still uses the “basic” option.
For the Brave browser in Arch Linux, you can create a ~/.config/brave-flags.conf file, as mentioned in this>>> comment, so we can just to copy the existing one:
$ cp .config/chromium-flags.conf .config/brave-flags.conf
Restart Brave, check its options:
And in the Secret Service of the KeePass, the brave record appeared, so it’s using the Secret Service now:
Done.
Similar posts
- 12/11/2019 KeePass: настройка MFA, хранение паролей браузера, паролей SSH ключей и интеграция Secret Service
- 12/01/2019 SSH: RSA keys, and ssh-agent for SSH keys and their passwords management
- 12/07/2019 What is: Linux keyring, gnome-keyring, Secret Service, and D-Bus
- 12/01/2019 Linux: the Nextcloud client, qtkeychain and the “The name org.freedesktop.secrets was not provided by any .service files” error
Top comments (0)