Best way to enable password auth on SSH?

I know everyone is going to give me grief over this, but I have a customer who insists on password auth. I saw that the treefile.json has a postprocess script to disable password auth, which means if I change the /etc/ssh/ssh_config, it is going to get changed right back.

After looking into editing the treefile.json, I realize that it is a dead-end. I don’t know enough about the lifecycle of FCOS to know where I should put a script to undo the effects of rpm-ostree postprocessing. Any suggestions?

No - modified configuration files in /etc are preserved by libostree.

No - modified configuration files in /etc are preserved by libostree.

I will have to do more testing. What I saw was that when Zincati updated the system, the following postprocessing script locked me out again:

#!/usr/bin/env bash
set -xeuo pipefail

sed -Ei 's/^(PasswordAuthentication|PermitRootLogin)[[:blank:]]/#&/' /etc/ssh/sshd_config

echo -e '\
# Disable password logins by default\
PasswordAuthentication no\
PermitRootLogin prohibit-password' >> /etc/ssh/sshd_config

The easiest way I could see to do this was with an fcct like:

variant: fcos
version: 1.0.0
passwd:
  users:
    - name: core
      password_hash: $6$BE6EFk9JQ2.0qQOf$ic90ZkRVexv1ZN7B/WxH3/XG1hbzSVUwSju6jK7YvAnFCVPMrMSb.KQMOIqZ66y3pCkyRglFwYdWJG7Rb0p0n1
systemd:
  units:
    - name: sshd.service
      dropins:
      - name: allowpasswordauth.conf
        contents: |
          [Service]
          Environment=OPTIONS='-oPasswordAuthentication=yes'

The password in that hash is supercomplicatedpassword. I tested this across an upgrade and I did not lose the ability to log in via password as the core user.

1 Like

Awesome! Thank you for this!

1 Like

It’s unfortunate that there’s an /etc/ssh_config.d for the client side, but no corresponding /etc/sshd_config.d for the server. Failing that though I’d probably recommend appending to /etc/sshd_config over setting the environment; the config file is more central to how things work versus the likely Fedora-specific $OPTIONS variable.

Certainly that would be the simpler answer. I looked at doing that first before I posted up the systemd unit override, but I don’t think it worked. I think we’d have to resort to a sed statement.

Appending to sshd_config doesn’t work in this case, because we ship an uncommented PasswordAuthentication directive by default, and sshd uses the first instance of a directive it sees.

We can (and should) support sshd_config.d starting with OpenSSH 8.2 in Fedora 32.

1 Like

https://github.com/coreos/fedora-coreos-config/pull/349

Proper docs now exist for this: Configuring Users :: Fedora Docs

3 Likes