After updating my workstation, I noticed that keychain reported that it could not load one of the GnuPG keys I passed it on.
* keychain 2.8.1 ~ http://www.funtoo.org * Found existing ssh-agent: 2167 * Found existing gpg-agent: 2194 * Warning: can't find 0xB7BD4B0DE76AC6A4; skipping * Known ssh key: /home/swift/.ssh/id_dsa * Known ssh key: /home/swift/.ssh/id_ed25519 * Known gpg key: 0x22899E947878B0CE
I did not modify my key store at all, so what happened?more ...
While working on the second edition of my first book, SELinux System Administration - Second Edition I had to test out a few commands on different Linux distributions to make sure that I don't create instructions that only work on Gentoo Linux. After all, as awesome as Gentoo might be, the Linux world is a bit bigger. So I downloaded a few live systems to run in Qemu/KVM.
Some of these systems however use cloud-init which, while interesting to use, is not set up on my system yet. And without support for cloud-init, how can I get access to the system?more ...
After reorganizing my salt configuration, I received the following error:
[ERROR ] Template was specified incorrectly: False
Enabling some debugging on the command gave me a slight pointer why this occurred:
[DEBUG ] Could not find file from saltenv 'testing', u'salt://top.sls' [DEBUG ] No contents loaded for env: testing [DEBUG ] compile template: False [ERROR ] Template was specified incorrectly: False
I was using a single top file as recommended by Salt, but apparently it was still looking for top files in the other environments.
Yet, if I split the top files across the environments, I got the following warning:
[WARNING ] Top file merge strategy set to 'merge' and multiple top files found. Top file merging order is undefined; for better results use 'same' option
So what's all this about?more ...
Part of a system's security is to reduce the attack surface. Following this principle,
I want to see if I can switch from using regular salt minions for a saltstack managed
system set towards
salt-ssh. This would allow to do some system management over SSH
instead of ZeroMQ.
I'm not confident yet that this is a solid approach to take (as performance is also
important, which is greatly reduced with
salt-ssh), and the security exposure of the
salt minions over ZeroMQ is also not that insecure (especially not when a local firewall
ensures that only connections from the salt master are allowed). But playing doesn't hurt.
A short while ago I got the notification that pulling new CVE information was no longer possible. The reason was that the NVD site did not support uncompressed downloads anymore. The fix for cvechecker was simple, and it also gave me a reason to push out a new release (after two years) which also includes various updates by Christopher Warner.
So cvechecker 3.6 is now available for general consumption.more ...
I administer a couple of systems which provide interactive access by end users, and for this interactive access I position OpenSSH. However, I also use this for administrative access to the system, and I tend to have harder security requirements for OpenSSH than most users do.
For instance, on one system, end users with a userid + password use the sFTP server for publishing static websites. Other access is prohibited, so I really like this OpenSSH configuration to use chrooted users, internal sftp support, whereas a different OpenSSH is used for administrative access (which is only accessible by myself and some trusted parties).more ...
With Mike's news item on OpenSSH's deprecation of the DSA algorithm for the public key authentication, I started switching the few keys I still had using DSA to the suggested ED25519 algorithm. Of course, I wouldn't be a security-interested party if I did not do some additional investigation into the DSA versus Ed25519 discussion.more ...