I recently upgraded an old Debian system sitting in the lab to a modern release. I had neglected to keep it updated, and it was flagged on an internal scan for having out of date software. To prevent this oversight in the future, I added it to our puppet deployment (so it would get software updates and be kept in line with our standards) and set it up in our monitoring cluster (so that we’d know if puppet or the updates broke). ...
After upgrading some bastion hosts to Debian 10, connections to some older network gear failed with the following error: ssh_dispatch_run_fatal: Connection to 192.0.2.93 port 22: Invalid key length It turns out that newer versions of ssh (client) now have a minimum key length that they will negotiate. This device had its ssh host key generated many years ago, and a shorter key length was used: % Key pair was generated at: 18:12:01 EST Dec 27 2007 I needed to generate a new key with a longer key length, so I (temporarily) installed ssh1 on the bastion host, connected to the device, and regenerated a new key. ...
After upgrading a nameserver to Debian 10, I noticed some AppArmor errors in /var/log/auth.log: Jul 29 09:58:18 koala audit[1676]: AVC apparmor="DENIED" operation="mknod" profile="/usr/sbin/named" name="/etc/bind/namedb/dyn/example.com.jnl" pid=1676 comm="isc-worker0029" requested_mask="c" denied_mask=" c" fsuid=112 ouid=112 It appears that a default ISC bind install now restricts named to read-only access on /etc/bind. According to /etc/apparmor.d/usr.sbin.named: [...] # /etc/bind should be read-only for bind # /var/lib/bind is for dynamically updated zone (and journal) files. # /var/cache/bind is for slave/stub data, since we're not the origin of it. # See /usr/share/doc/bind9/README.Debian.gz /etc/bind/** r, /var/lib/bind/** rw, /var/lib/bind/ rw, /var/cache/bind/** lrw, /var/cache/bind/ rw, [...] The relevant portion of /usr/share/doc/bind9/README.Debian.gz: ...
After upgrading some bastion hosts to Debian 10, connections to some older network gear failed. Connecting to some ASA firewalls generated the error: Unable to negotiate with 203.0.113.203 port 22: no matching key exchange method found. Their offer: diffie-hellman-group1-sha1 This was a simple fix: lab-5585-1# conf t lab-5585-1(config)# ssh key-exchange group dh-group14-sha1 lab-5585-1(config)# end Some older devices, Catalyst 3750 switches and ASA 5540 firewalls, complained of no matching cipher: %SSH-3-NO_MATCH: No matching cipher found: client chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com server aes128-cbc,3des-cbc,aes192-cbc,aes256-cbc This could be fixed on the device with the ip ssh server algorithm encryption ... (3750) and ssh cipher encryption ... (ASA) commands, but I decided to fix this on the bastion host instead by adding Ciphers +aes256-cbc to /etc/ssh/ssh_config. ...
I have a nice netboot setup where we can PXEboot hosts to an automated installer. The last step ensures the puppet agent is running and pointed at the correct puppetmaster. The .preseed files are generated from an erb template that ends in the following: [...] <% if @distcodename == "jessie" -%> d-i preseed/late_command string \ echo -e 'DAEMON_OPTS="--server <%= @puppetmaster %>"' > /target/etc/default/puppet ; \ rm -f /target/var/lib/puppet/state/agent_disabled.lock <% else -%> d-i preseed/late_command string \ in-target sed -i '/\[main\]/a server = <%= @puppetmaster %>' /etc/puppet/puppet.conf ; \ in-target ln -s /lib/systemd/system/puppet.service /etc/systemd/system/multi-user.target.wants/puppet.service <% end -%> Older distribution versions allowed us to populate the --server option in /etc/default/puppet. This is addressed in the first part of the if clause. ...