Stuff I'm Up To

Technical Ramblings

SSH Tunnelling – autossh — January 31, 2020

SSH Tunnelling – autossh

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.

This is where autossh comes in.

Continue reading
Lsyncd and Docker — January 29, 2020
Gnome Keyring and ssh-agent —

Gnome Keyring and ssh-agent

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.

Filesystem Synchronisation — January 28, 2020
OpenSSH keys and known_hosts — January 24, 2020

OpenSSH keys and known_hosts

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.

Creating a Key Pair

$ 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.

Updating a known_host File

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.

Using ssh-agent to Remember Your Password

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.

Docker Health Checks — January 21, 2020
Saltstack and Debconf — January 20, 2020

Saltstack and Debconf

You 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

Saltstack on Debian 10 — January 17, 2020

Saltstack on Debian 10

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:

On the Master

$ sudo apt install gnupg2 python-pip python3-tornado
$ sudo pip install --upgrade --force-reinstall pyzmq

On the Minion

$ 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
Linux LDAP Auth — January 16, 2020

Linux LDAP Auth

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.

/etc/nsswitch.conf

passwd: compat ldap
group: compat ldap
shadow: compat ldap
...
sudoers: files ldap

/etc/pam.d/common-password

Remove use_authok from any line in the file common-password.

/etc/pam.d/common-session

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

Cephfs —
gdm3 Tweaks — January 15, 2020

gdm3 Tweaks

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.

Hide a User from the gdm3 Login Screen

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

Put the gdm3 Login Screen on Your Preferred Monitor

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/

polkit-agent-helper-1[6160] —

polkit-agent-helper-1[6160]

After 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 user name 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 uses 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