I'm trying to use gnome-keyring to memorize my GPG passphrase in a headless Ubuntu server (22.04.1 LTS GNU/Linux 5.15.0-57-generic x86_64). The reason I'm trying to do this with gnome-keyring and not using the gpg-agent cache is that I'd like for the GPG certificate to be immediately accessible to be used by some systemd cronjobs when I reboot my server.
I've followed the Gnome/Keyring instructions but using pinentry-gnome3 doesn't seem to work:
No Gcr System Prompter available, falling back to curses
I've also tried using pinentry-gtk-2 like it is mentioned in GnuPG instructions and although I don't get any error, the passphrase is not stored.
When doing some debugging, I've found some weird behavior. Trying to store something in my keyring gives me this error:
$ secret-tool store --label='test' foo bar
secret-tool: Cannot create an item in a locked collection
Anyone can help me? I'm also willing to drop using gnome-keyring for something else, but I haven't found anything that would fit my use case.
Related
I have read the guindance that the keyring package has in its project for headless linux systems.
So the main recommendation is to install the gnome-keyring package in order to work with the Secret Service Backend.
sudo apt install gnome-keyring
Then, as I already have the dbus package installed I just run:
dbus-run-session -- sh
But, as I am in WSL 2 I get a weird prompt, it seems that PS1 is not parsed and I get something like this:
\[\e]0;\u#\h: \w\a\]\[\033[01;32m\]\u#\h\[\033[00m\]:\[\033[01;34m\]\w\[\033[00m\]$
In a normal Debian or Ubuntu instance I would get $
I send the password to unlock the keyring
echo 'db' | gnome-keyring-daemon --unlock
I also tried to enter the password manually through stdin as this answer points out, with the same result:
gnome-keyring-daemon --unlock
Now the guide says "run your application in the same D-Bus session as the daemon". I don't know if I need to do something special to achieve that. I just run python after entering the password.
$ python
>>> import keyring
>>> keyring.get_keyring()
<keyring.backends.SecretService.Keyring object at 0x7f383b89f220>
>>> keyring.set_password("system", "username", "password")
But at this point I get this error:
dbus-daemon[9337]: [session uid=1000 pid=9337] Activating service name='org.freedesktop.secrets' requested by ':1.4' (uid=1000 pid=9339 comm="python ")
GNOME_KEYRING_CONTROL=/home/db/.cache/keyring-TPE3M1
dbus-daemon[9337]: [session uid=1000 pid=9337] Successfully activated service 'org.freedesktop.secrets'
dbus-daemon[9337]: [session uid=1000 pid=9337] Activating service name='org.gnome.keyring.SystemPrompter' requested by ':1.5' (uid=1000 pid=9356 comm="/usr/bin/gnome-keyring-daemon --start --foreground")
Unable to init server: Could not connect: Connection refused
(gcr-prompter:9364): Gtk-WARNING **: 09:36:04.690: cannot open display:
dbus-daemon[9337]: [session uid=1000 pid=9337] Activated service 'org.gnome.keyring.SystemPrompter' failed: Process org.gnome.keyring.SystemPrompter exited with status 1
** (gnome-keyring-daemon:9356): WARNING **: 09:36:04.701: couldn't create system prompt: GDBus.Error:org.freedesktop.DBus.Error.Spawn.ChildExited: Process org.gnome.keyring.SystemPrompter exited with status 1
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/path/to/env/lib/python3.9/site-packages/keyring/core.py", line 60, in set_password
get_keyring().set_password(service_name, username, password)
File "/path/to/env/lib/python3.9/site-packages/keyring/backends/SecretService.py", line 87, in set_password
collection = self.get_preferred_collection()
File "/path/to/env/lib/python3.9/site-packages/keyring/backends/SecretService.py", line 67, in get_preferred_collection
raise KeyringLocked("Failed to unlock the collection!")
keyring.errors.KeyringLocked: Failed to unlock the collection!
And the processes tree look like this
I also tried with
dbus-run-session -- bash
With the same result
Possible WSL 2 Issue
I also found an issue on WSL2 project where "jaraco" says that the guidance that I followed may give some hints, but I could not get it to work.
Alternative Backend
I tried with other backend as well, though in some places they say that this backend is not recommendable:
“alternate”, possibly-insecure backends, originally part of the core package, but available for opt-in"
pip install keyrings.alt
With similar result. The keyring backend was different:
>>> keyring.get_keyring()
<keyring.backends.chainer.ChainerBackend object at 0x7ffbad5fd040>
Any alternative or recommendation? Am I missing some step? Is this possible to make in WSL 2? I think I will try in a debian machine directly to check if it is a problem of WSL or all Debian headless distros. Anybody make it work on Debian without Gnome desktop installed?
The next step would be to automate all the process, but first I need to get this to work
Update
Well, I can confirm that in a virtual machine on Debian 11.3 works fine. So it must be something to do with WSL 2
Update 2
Ah, I have just realized that I had installed the WSL2, but my Debian System was in WSL so I had to update it to WSL2 with the following instruction. Anyway, I think the behaviour, in this case would be the same.
wsl --set-version Debian 2
Note that I have been able to get this to work (WSL2, Debian Bullseye, python3, gnome-keyring, Windows 10). I can understand parts of why it may not be working for you, but there are some minor differences in the errors you are seeing from what I can reproduce (when I try to break it). We'll come back to those if we need to, but let me go through what I've tried successfully so far.
But, as I am in WSL 2 I get a weird prompt
First, I think this is an orthogonal issue, but perhaps not. I always suspect startup configuration files for this type of weirdness, so I would try eliminating those from the equation:
dbus-run-session -- bash --noprofile --norc
If the prompt looks normal when running that, I'd look to ~/.profile since it sounds like it it happens both Bash and Dash (sh) for you and Dash doesn't have an rc file.
Again, I'm assuming that's not the problem with the keyring, but it doesn't hurt to eliminate it as a potential contributor.
As for the main keyring problem, that, I believe, is because:
Gnome Keyring is attempting to ask for a password. It does this with a graphical password prompt, which fails because ...
You are running Windows 10 without an X server, or if you are running an X server, then the DISPLAY variable is "lost". That's the cannot open display error in the trace. If you were on Windows 11, the graphical prompt would display. You could also configure Windows 10 WSL to use a third-party X server like VcXsrv. Or you could run with Xrdp. See this Super User question (and others) for more info.
Of course, that would no longer count as "headless", which is your question. So we need to figure out why gnome-keyring is asking for a password. I can think of at least possible three reasons, but there may be others:
The default collection (keyring) doesn't exist yet. I'm fairly sure that's not the case for you, since it should have been created when you ran the --unlock. Of course, you can verify this by checking ~/.local/share/keyrings.
gnome-keyring-daemon hasn't yet been started, and needs the keyring password. Again, you've clearly run that here. You've done the right thing by running the dbus-run-session first, then inside that session, run the --unlock. You can, of course, verify that it is running with a ps -efH or similar.
The password that was passed via --unlock is wrong.
So with the first two eliminated, we're left with the assumption there's an issue with the unlock password. If you created the collection with the initial --unlock, then the first password you used should be the one set on the collection.
There are some "gotchas" here. First, contrary to what the answer you linked says, I'm convinced that the newline is added to the password. If you somehow initially set the password without a newline, you'd need to unlock it with echo -n. E.g.:
echo -n 'db' | gnome-keyring-daemon --unlock
Second, it doesn't sound like this was the case for you, but if you create the keyring through the normal frontend, then it appears to me that the password may be salted. I have not been able to use gnome-keyring-daemon --unlock (in any of its forms) to unlock a collection where the password was entered through the graphical prompt. To clarify:
If I initially create the keyring via gnome-keyring-daemon --unlock, then I can unlock it either through the GUI askpass program that it uses (on Windows 11 or with a Windows 10 VcXsrv installation), but ...
If I initially create the keyring via an initial access of it which prompts for the password through the GUI, then I can subsequently only unlock it through the GUI. I can no longer use gnome-keyring-daemon --unlock.
Assuming this is a new keyring in WSL2, then my advice would be to remove it and try again:
dbus-run-session -- bash --noprofile --norc
# Back them up first if you'd like
rm -rf ~/.local/share/keyrings
echo -n 'db' | gnome-keyring-daemon --unlock
python3
Note that you can test the keyring module directly from the shell via:
python3 -m keyring set system username
# Will prompt for the secret
python3 -m keyring get system username
# Should return the secret
If things are working from there, they'll work from your code. If it fails, it should do so with the same error at least. This might save some time in troubleshooting if this doesn't work.
I have installed Hadoop on an Ubuntu machine. I set up passphraseless ssh. I can use the command "ssh localhost" and it gives me information without needing to enter a password. However when I go to Hadoop and type "sudo bin/start-all.sh" it asks me for my password (because I used sudo which is fine), but after I enter that, it will do a couple things and then ask me for the root password which I believe it's not suppose to do. I've searched for a couple days now and I only end up with answers for when "ssh localhost" doesn't work. I haven't found anything for my problem. Any help is very much appreciated.
UPDATE:
It seems that I need sudo passphraseless ssh which is not the same as just passphraseless ssh. However, I am still unable to find out how to make this happen.
I just came back to check and realized I didn't post the solution I found. When installing Hadoop and generating keys, avoid using SUDO where ever it is not absolutely necessary. If you use SUDO, it will attempt to use the root keys which are not the same as the ones generated not using SUDO. Hadoop will automatically use the current user's keys and they won't work, so it prompts for a password.
When I stop using
**sudo** ./start-dfs.sh
And used:
./start-dfs.sh
I solved the shh communication problem with the namenode
So, I followed this tutorial to install a gitolite server.
But my client machine is a Windows machine, not a Linux box.
So, instead of using ssh-keygen, I used Eclipse "ssh2" utility (in windows, preferences, general, network connections, ssh2).
I generated the .pub file and used to setup gitolite (like in the tutorial).
But it doesn't seems to work, I always get a "Connection refused: connect" when I try to connect to my server from windows using this URL :
ssh://gitolite#192.168.0.193:22/gitolite-admin
I opened the .pub files generated by Eclipse and what I find funny is that there is always 2 equals signs at the end.
For example, here's one generated public key :
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAAAgQCQbDy+Nfoq+AitTrAbxy0PwRuBmgnm/vJk27KNOB3EzsZFKQ7+89I12nbxc8N+7z4Seq9fhNrYHfM7PvzgdI8F5QLxWbl2QV0UapBpjWmX+7WEE9bjEHIf7re3FpRzVdJrCAwscaUawmsIGi1rvw8ZFrbfPdS6ITiI10WcfTEdCw== RSA-1024
Is it possible to try another key pair without having to reinstall gitolite?
Can I generate the key pairs on my linux box and just upload the private key generated on my Windows machine?
Any other help on how I can diagnose the problem would be great.
UPDATE #1 :
I found out that no ssh server was running on my server. You can see that with :
sudo nmap -sS xxx.xxx.xxx.xxx -p 22
If the port's state is closed, then your SSH service is either closed or doesn't exists.
You can also try to connect with Putty (on windows) with SSH on your Linux machine, you'll see if the SSH server is working properly.
If your SSH service is not started, you can start the service with :
sudo service ssh start
If the service doesn't exists, you'll need to install an ssh server. I installed mine (on Ubuntu) like this :
sudo apt-get purge openssh-server
sudo apt-get install openssh-server
After installing openssh, everything was working fine on my box.
First, if you have msysgit installed, you perfectly can use ssh-keygen (included in this msysgit module).
The official help page for installing gitolite can also help.
Don't worry about the two == at the end of the public key. It is normal, and what follows those two == is always ignored (for instance, you can place a comment here for you to remember what that public key is for, if you want).
Now:
Is it possible to try another key pair without having to reinstall gitolite?
.
Yes. See "lost admin key/access":
Make yourself a new keypair and copy the public key to the server as 'alice.pub'.
Log on to the server, and run gitolite setup -pk alice.pub.
.
That's it; the new alice.pub file replaces whatever existed in the repo before.
Can I generate the key pairs on my linux box and just upload the private key generated on my Windows machine?
.
No, you need both private and public key on your %HOME%/.ssh folder (which means you must have HOME environment variable defined on Windows)
I would then recommend an %HOME%/.ssh/config file to use your keys.
Any other help on how I can diagnose the problem would be great.
.
The official doc has many tips.
I have a few ssh debugging tips as well.
I'm using libspotify 12.1.103.gd51f6226 Release Linux-armv6-bcm2708hardfp on my Raspberry Pi and I think that everything worked out alright with the instruction in the readme.
I changed out appkey.c for my appkey as given by spotify but when I run the spshell example and try to login, I get an error
FATAL, TERMINATING: failed to log in to Spotify: Cannot connect to Spotify
Logged out
Exiting...
I'm sure that I'm using the correct username (I also tried email) and password (I also tried changing the password) and I've tried the jukebox example as well and get a similar error. I'm able to log into the website and the windows app just fine.
The one place that I think that I might have gone wrong is:
After this, ensure your PKG_CONFIG_PATH is set tocd
include the libspotify control file, and that the lib directory is
in the library search path.
I'm pretty sure that I did that okay and I don't get any errors during the build.
Any ideas?
I had the exact same problem, which you can see from my comments on this question. For me it turned out to be a problem with my username which contains a non-ascii letter ö. But since my plan all along was to use pyspotify I managed to log in using their jukebox example and hardcoding my username where appropriate and adding the nice little u infront of it, and now I can login to spotify, see line ~460 in the jukebox example:
session_m = Jukebox(options.username, options.password, True)
Which i changed to this:
session_m = Jukebox(u"username_with_ö", options.password, True)
Now my problem is another which is that I can't access /dev/dsp but that is an entirerly different problem. :)
EDIT
apt-get install alsa-oss solve the above mentioned problem, my raspberry is now playing music!
I can compile and login.
What I did was to simply extract the tar.gz to
And then..
sudo apt-get install libasound2-dev libreadline-dev
cd <libspotify folder>/share/doc/libspotify/examples
vim appkey.c
And then add the application key that you generate. But that seemed to work for you.
make LIBSPOTIFY_PATH=../../../..
spshell/spshell
Then I can login and do a lot of things, I haven't tried any audio yet since I don't have any speakers/headphones available.
If you install it instead using
cd <libspotify folder>
make install prefix=/usr/local
as described in the README also run
sudo ldconfig
to update the library cache, and then just do a normal compile.
cd <libspotify folder>/share/doc/libspotify/examples
make
If you suspect that you have compiled stuff the wrong way, do a "make clean" first.
Don't know if this is to any help but that is how far I have come.
I want to run a script on remote server using SSH.
I have write all the code which runs properly using system command.
To run my code on remote server I need some packages which I need to install on remote server.
To do so I need login into remote terminal as a ROOT user. When I try to do using Ruby script so I get something like following
[not_root_user#remote_server]$ su
Password:
I need some command using which I can able to login into the remote server something like following
[not_root_user#remote_server]$ su -p ******
[root#remote_server]#
Is there any linux command which accepts the password in it?
So you want your script to act as root?
It's not really recommended, but you can use expect: http://en.wikipedia.org/wiki/Expect
The wiki there has a walkthrough for a basic automated telnet session that you could adapt to your needs.
However, you're going to have your root password in plain text, which could be a security issue. If you go that route, I'd definitely obliterate all copies of that script from the universe once this package is installed.
But if you're allowing direct root logins, you've already got a bit of a security problem. Sudo works out-of-the-box on every modern linux distro I've used, I'd stick with that, if possible.
Another option which is equally tasteless would be to set up root-to-root login without a password via ssh.
Sudo would be my first option to getting around this. Although not the best option.
You can also use Key authentication with SSH, and if password authentication is turned off there is no need to enter a password.