Devuan generate new ssh keys for freeipa host

If a Devuan system is a freeipa client, but you cannot ssh -o GSSAPIAuthentication=yes to it, even though all the regular troubleshooting steps work, and the logs don’t show you anything, the host ssh keys might be wrong in freeipa.

Generate new ssh keys for freeipa host

All the steps can be taken on the host in question.
As root, make sure you can kinit -k to get a kerberos key with the host keystore. If this step doesn’t work, you need to go fix that, which is beyond the scope of this post.

kinit -k
# klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: host/d2-03a.ipa.example.com@IPA.EXAMPLE.COM

Valid starting       Expires              Service principal
12/31/2019 07:25:47  01/01/2020 07:25:47  krbtgt/IPA.EXAMPLE.COM@IPA.EXAMPLE.CO

Now, generate new ssh keys. Apparently on Devuan systems, restarting the daemon is not good enough. On CentOS, if you delete the ssh host keys, restarting the daemon will just generate new ones which can cause some interesting effects when connecting to a host that did so. However, on Devuan you have to run:

rm -rf /etc/ssh/ssh_host_*_key*
dpkg-reconfigure openssh-server
service ssh restart

And then, with the fresh keytab from the kinit -k earlier, it’s a piece of cake to modify this host in freeipa to use a new set of ssh public keys!

LC_ALL="" LC_CTYPE="C.UTF-8" ipa host-mod --sshpubkey="$( cat /etc/ssh/ssh_host_rsa_key.pub )" --sshpubkey="$( cat /etc/ssh/ssh_host_ecdsa_key.pub )" --sshpubkey="$( cat /etc/ssh/ssh_host_ed25519_key.pub )" $( hostname -s )
----------------------
Modified host "d2-03a"
----------------------
  Host name: d2-03a.ipa.example.com
  Principal name: host/d2-03a.ipa.example.com@IPA.EXAMPLE.COM
  Principal alias: host/d2-03a.ipa.example.com@IPA.EXAMPLE.COM
  SSH public key: ssh-rsa
                  AAAAB3NzaC1yc4EAAAADAQABAAABg[truncated]
                  root@d2-03a, ecdsa-sha2-nistp256
                  AAAAE@VjZHNhLXNoYTItbmlzdHAyNTYAAAAI[truncated]
                  root@d2-03a, ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIBU/CbzrNnMivn5kAiHTU6WSadY/FWPG8qZ3sGleDbHr
                  root@d2-03a
  SSH public key fingerprint: SHA256:tMcJ2uFNmx6K+dF+Gm6WUBO4AvBmGVj9247mvg5LxU4 root@d2-03a (ssh-rsa),
                              SHA256:uJeRc0dkao/DmnQm2hyQUSfeC0HgIZppB2NVyA+BoTA root@d2-03a (ecdsa-sha2-nistp256),
                              SHA256:j+trvcJAQx5PeaJbUJ8xImBDgCJ2U/nW3h5D3m2kTj4 root@d2-03a (ssh-ed25519)
  Password: False
  Keytab: True
  Managed by: d2-03a.ipa.example.com

My ipa command kept complaining about all these language problems. Maybe I failed to set them correctly in my preseed. Whatever.

References

Internet searches

freeipa new ssh host key

Weblinks

6.8. Managing Public SSH Keys for Hosts
How To: Ubuntu / Debian Linux Regenerate OpenSSH Host Keys – nixCraft

Man pages

ipa help host-mod

Use su with ssh X-forwarding

This is a shameless ripoff of Howto use su with ssh x-forwarding [coderwall.com]

If you ssh to a server and want to do X forwarding, make sure the server allows it in /etc/ssh/sshd_config:

X11Forwarding yes

And then your ssh command should include -X, or make sure your ~/.ssh/config includes:

ForwardX11 yes

Command:

ssh -X servername

And once on the server, prepare your xauth file to be shared the other user before switching and merging it.

xauth extract /tmp/x $DISPLAY
chmod 0644 /tmp/x
su otherusername
xauth merge /tmp/x

References

Web searches

ssh x forwarding with su

sshd_config match negate address

tl;dr

Match Address *,!192.168.1.0/24

Negating address in match statement in sshd_config

I was locking down my ssh server configuration on a host, so that it will not accept password auth from outside a certain IP address range.
I had to learn how to get the Match Address directive to work with a negation. To make it work, you need to insert a wildcard before you then state the exclusion.

Match Address *,!192.168.1.0/24

And then I added the directives for this matched IP address range.

   AuthenticationMethods publickey
   PubkeyAuthentication yes
   PasswordAuthentication no
   X11Forwarding no

References

Weblinks

  1. https://serverfault.com/questions/408284/how-can-the-address-condition-in-a-match-conditional-block-in-sshd-config-be-neg

Man pages

  1. sshd_config
  2. ssh_config

sshd_config Match AD group

Overview

Last updated: 2019-01-14

I use CentOS 7. One of the biggest reasons I join my servers to Active Directory is for the users and groups. Getting sshd_config to work with AD-defined groups is easy and just needs the smallest amount of work.

If you want to use sftp, and have rules for just a specific AD group, you need to specify the group name exactly as it is cased.
[root@amazon|/var/log]# getent group Web_Dev_Grp
web_dev_grp:*:5829038:asmith,rltompki,fkowalks,bangel,lfrederi

So use the “web_dev_grp” as shown in your sshd_config:
Match Group web_dev_grp
ChrootDirectory /var/www
ForceCommand internal-sftp

If you want to match multiple groups, you can use this format:
Match Group web_dev_grp,linux_admins_grp

Be sure to read ssh_config(5) on PATTERNS and sshd_config(5) on Match for more details.