Maintaining a secure connection to a remote host using SSH to securely tunnel traffic for underlying services like MSQL, PostgreSQL or just for remote support is made far easier by using a tool designed to bring up the connection and monitor and maintain it.
Continue readingThis is where autossh comes in.
Following on from Filesystem Synchronisation where a Docker container was setup to handle receiving files over rsync+ssh this handles the sending client side that monitors and sends changed files over to the server using lsyncd.
Every time I fire up a zsh shell terminal in gnome-shell I can’t add my ssh key to an existing ssh-agent instance.
$ ssh-add
Could not open a connection to your authentication agent.
The gnome-keyring-daemon is running, but it just doesn’t seem to set the environment variable SSH_AUTH_SOCK.
I’d have to run ssh-agent and start one listening on a temporary socket and pass the environment settings around terminal sessions. Turns out this is a known issue and the fix is relatively easy.
For zsh add the environment variable to your ~/.zshrc
export SSH_AUTH_SOCK=/run/user/$(id -u)/keyring/ssh
Now any call to ssh-add in a terminal works as expected.
You might want to do the same for other shells in ~/.profile etc.
I need a repeatable process for handling synchronising files between systems. Something modular and stable. A couple of Docker containers using lsyncd and sshd should do the job.
As I’ve been working on Docker containers I’ve been having to use local containerised versions of ssh key pairs and known_hosts. I need to be able to carry out key creation etc. without upsetting my own personal keys under ~/.ssh.
This may be bread and butter stuff to many long time Linux admins, but it’s not something I’ve had to do on a daily basis until recently.
$ ssh-keygen -f rsa -b 4096 -f [key name]
Where I can specify the location and name of the key files to create eg.
$ ssh-keygen -t rsa -b 4096 -f folder/id_rsa
Will give me the id_rsa and id_rsa.pub files in the folder called folder.
If I’m using two containers and need to get the remote containers key finger prints into my local containers known_hosts I can use ssh-keyscan to grab the fingerprints and then direct them to a file. Be careful as the order of the parameters is important, especially if you have ssh daemons on different ports on the remote.
$ ssh-keyscan -H -p 22 [remote host] >> folder/known_hosts
You can change the port that the keyscan pulls fingerprints from by changing the -p 22 to your required port.
This can even be scripted into your containers “entrypoint” so the connection is always ready and avoid the messages:
ECDSA host key for IP address ‘192.168.122.99’ not in list of known hosts.
Host key verification failed.
After a while relentlessly typing your keys passphrase gets wearing. Use the ssh-agent in your current environment to provide it for you.
$ eval `ssh-agent` $ ssh-add
You’ll be asked for your password and then the agent will pass it along to all the future requests for that session.
When wanting to monitor the condition of your containers using Nagios there are some really nice features you can enable to check that your containers are up, not abusing the cpu etc. But wouldn’t it be nice to check out what’s going on inside the container too?
Continue readingYou can get Saltstack to manipulate package deployments using debconf. What you’ll need is to know the questions that debconf has about a package so you can provide the answers.
For example, installing libpam-ldap requires a number of answers to configure the service. My state file (.sls) contains something like this:
debconf-utils:
pkg.installed
libpam-ldap:
debconf.set:
- data:
'libpam-ldap/binddn': {'type': 'string', 'value': 'cn=admin,dc=domain,dc=tld'}
'libpam-ldap/dblogin': {'type': 'boolean', 'value': False}
'libpam-ldap/dbrootlogin': {'type': 'boolean', 'value': False}
'libpam-ldap/override': {'type': 'boolean', 'value': True}
'libpam-ldap/pam_password': {'type': 'string', 'value': 'crypt'}
'shared/ldapns/base-dn': {'type': 'string', 'value': 'dc=domain,dc=tld'}
'shared/ldapns/ldap-server': {'type': 'string', 'value': 'ldap://ldap/'}
'shared/ldapns/ldap_version': {'type': 'string', 'value': '3'}
Which sets out that the package to be installed in this example, and configured is libpam-ldap. The questions listed have the answers applied in the format 'question': {answer}.
To get a list of the questions you can use debconf-show [package] eg.
$ sudo debconf-show libpam-ldap * libpam-ldap/rootbindpw: (password omitted) * libpam-ldap/bindpw: (password omitted) * libpam-ldap/override: true * shared/ldapns/base-dn: dc=domain,dc=tld * libpam-ldap/pam_password: crypt * libpam-ldap/dblogin: false * libpam-ldap/rootbinddn: cn=admin,dc=domain,dc=tld * libpam-ldap/dbrootlogin: false * libpam-ldap/binddn: cn=admin,dc=domain,dc=tld * shared/ldapns/ldap_version: 3 * shared/ldapns/ldap-server: ldap://ldap
Following the installation guide caused a few quirks and failures on my Debian 10 install. There are a few missing packages and the bootstrap version of the install puts in an incorrect repository. I had to follow the specific installation guidance for Debian 10, after I’d added in the missing packages.
Some additional apt and pip package requirements for the salt-master that are not listed, but do appear under the Github issues are as follows:
$ sudo apt install gnupg2 python-pip python3-tornado $ sudo pip install --upgrade --force-reinstall pyzmq
$ sudo apt install gnupg2
Gnupg2 is required to install the repository key. For some reason this was missing from my base install of Buster.
For a quick and dirty solution in my virtual test environment I added an entry into my /etc/hosts file that would allow it to find my salt master by its default name of salt.
salt 192.168.122.187
Once completed you can follow the post installation configuration guide and add the necessary keys to the minion and get it talking to the master.
When you get them talking you can start issuing salt instructions to the minion to make it do what you need.
$ sudo salt minion.domain pkg.list_pkgs
$ sudo salt minion.domain pkg.install nginx
$ sudo salt minion.domain pkg.remove nginx-common
Up until now all of my Linux authentication has been local file based auth. I’ve added LDAP to services and applications, but logging into a Linux box has always had local users.
Following a process to install LDAP as the pam authenticator for Debian Buster included the following steps.
$ sudo apt install libnss-ldapd libpam-ldap ldap-utils
Then provide the details meeting your LDAP needs. Such as:
LDAP URI: ldap://ldap.domain.tld/
Search Base: dc=domain,dc=tld
DN and password of the Admin account if required: cn=admin,ou=People,dc=domain,dc=tld
Now you need to modify some configuration files.
Edit /etc/nsswitch.conf to add in references to ldap, we’re also going to use it for sudo and have added that into the config.
passwd: compat ldap group: compat ldap shadow: compat ldap ... sudoers: files ldap
Remove use_authok from any line in the file common-password.
Add the following line:
session optional pam_mkhomedir.so skel=/etc/skel umask077
For good measure restart nscd after making any changes to the above files.
$ sudo systemctl restart nscd
References: https://www.server-world.info/en/note?os=Debian_10&p=openldap&f=3
Ceph uniquely delivers object, block, and file storage in one unified system.
When setting up a new Debian Gnome it’s nice to make things look the way you want. Here’s a few changes I make to sort out my desktop.
This is how to hide a single user from the login screen – not hide all users. This is different to how it was done in earlier versions.
Create/edit a file with the users login name in /var/lib/AccountsService/users eg.
$ sudo vi /var/lib/AccountsService/users/myuser
Add the following or just change the SystemAccount value to true.
[User] Language= XSession= SystemAccount=true
When Debian gets installed sometimes my monitors appear the wrong way around and my primary display is monitor 2. In user mode I can change this easy enough, but the gdm login remains the wrong way around.
The process is straight forward. Move things around as your user and then copy your user config to the gdm user. This is Debian-gdm for Buster but may just be gdm on other flavours.
$ sudo cp ~/.config/monitors.xml ~Debian-gdm/.config/
and for Ubuntu
$ sudo cp ~/.config/monitors.xml ~gdm/.config/
On Manjaro / Arch:
$ sudo cp ~/.config/monitors.xml /var/lib/gdm/.config/Prevent gdm from showing a list of users to logon with by creating /etc/dconf/db/gdm
user-db:user
system-db:gdm
file-db:/usr/share/gdm/greeter-dconf-defaultsThen create /etc/dconf/db/gdm.d/00-login-screen
[org/gnome/login-screen]
# Do not show the user list
disable-user-list=trueUpdate the config:
sudo dconf updateAfter installing Gnome 42 on Mint it took me a long time to disable the user list. I went through installing gconf-editor and using gsettings and nothing turned it off.
sudo gsettings get org.gnome.login-screen disable-user-list
sudo gsettings set org.gnome.login-screen disable-user-list trueEventually I found /usr/share/gdm/greeter.dconf-defaults and uncommented the line to disable the user list.
# Login manager options
# =====================
[org/gnome/login-screen]
#logo='/usr/share/images/vendor-logos/logo-text-version-64.png'
# - Disable user list
disable-user-list=trueAfter setting up LDAP authentication on my machine, things went as expected, and I was able to authenticate at the GDM login and sudo from the command line etc. But when I called up a program that required elevated privileges in Gnome the authentication always failed, regardless of the password I used, and the dialog looked strange because it didn’t list the username it wanted the credentials for.
In particular, when I opened software packages or timeshift I’d get the authentication dialog, and it would fail.
Using journalctl -f and tailing /var/log/auth.log helped me figure out what was going on.
Jan 15 12:41:14 desktop-11 polkit-agent-helper-1[7398]: Jan 15 12:41:14 desktop-11 polkit-agent-helper-1[7398]: pam_unix(polkit-1:auth): authentication failure; logname= uid=1103 euid=0 tty= ruser=someonestrange rhost= user=someonestrange Jan 15 12:41:14 desktop-11 polkit-agent-helper-1[7398]: pam_ldap: error trying to bind as user "uid=someonestrange,ou=People,dc=domain" (Invalid credentials)
The user it was trying to authenticate as happens to be the first user on our LDAP schema.
Googling around for polkit and how it works, I found that the users that can authenticate are held in the config file /etc/polkit-1/localauthority.conf.d/51-debian-sudo.conf
[Configuration]
AdminIdentities=unix-group:sudo
Which seems obvious enough, but now we’re using LDAP and sudo-ldap it’s trying to use members of a local group called sudo. As this has only one member – the first user used to install the local Debian system with, it selected that user. The selected users ID of 1000 was then used by polkit, but the auth process went and used user ID 1000 on LDAP – which is our someonestrange.
At least now I know what’s going on. I could probably fix it by investigating how polkit works and seeing if I could set it to use an LDAP group, but the quickest fix was just to add my LDAP user account to the local sudo group, and then I could authenticate in Gnome.
$ sudo gpasswd -a myuser sudo
Stuff I'm Up To 