Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ssh_authorized_keys: and no_create_home: true doesnt work #316

Open
keithy opened this issue Nov 15, 2019 · 6 comments
Open

ssh_authorized_keys: and no_create_home: true doesnt work #316

keithy opened this issue Nov 15, 2019 · 6 comments

Comments

@keithy
Copy link

keithy commented Nov 15, 2019

but it could

https://unix.stackexchange.com/a/422795

@keithy
Copy link
Author

keithy commented Nov 15, 2019

Workaround
(note: SSH still tries and fails to change directory to the non-existent users home directory)

    - name: sshd-config-dropins.service
      enabled: true
      contents: |
        [Unit]
        Description=Compose sshd_config
        ConditionFirstBoot=yes
        After=multi-user.target
        Before=boot-complete.target
        [Service]
        Type=oneshot
        ExecStart=-sh -c 'find /etc/ssh/sshd_config.d -type f -name *.conf -exec cat {} + >> /etc/ssh/sshd_config'
        [Install]
        WantedBy=multi-user.target
        RequiredBy=boot-complete.target 

drop in

    - path: /etc/ssh/sshd_config.d/extra_keys.conf
      mode: 0600
      contents:
        inline: |
          #
          # Added from ignition
          Match User *
              AuthorizedKeysFile  /etc/ssh/sshd_config.d/authorized_keys_%u

example key

    - path: /etc/ssh/sshd_config.d/authorized_keys_goss-homeless
      mode: 0644
      user:
        id: 1111
      contents:
        inline: |
          command="sudo /usr/local/lib/goss/pkg/usr/local/bin/goss -g /etc/goss/goss.yaml validate ${SSH_ORIGINAL_COMMAND}" ssh-ed25519 AAAA... ...bT bob@is.your.uncle

@lucab
Copy link
Contributor

lucab commented Nov 15, 2019

Thanks for the report.
To my knowledge, I think we never stepped into this corner-case so it is great that you both reported it and attached your workaround!

I think there are no better ways to solve this other than your workaround, but we can certainly improve UX and docs.
I think a few actionable items out of this are:

  • mention in Ignition docs that sshAuthorizedKeys can't be used with noCreateHome: true
  • add a check in Ignition to explicitly reject this case
  • add your workaround snippet in FCOS docs, under some "advanced usecases" section (that doesn't exist yet)

@keithy for reference, can you also post here what was the original failure mode/output/logs you saw then trying to use sshAuthorizedKeys and noCreateHome: true? Did Ignition fail? Or did you get a booted and provisioned machine with SSHd rejecting your login attempts?

@keithy
Copy link
Author

keithy commented Nov 15, 2019

It booted and provisioned machine with SSHd rejecting login attempts

Ignition doesn't raise an error

Nov 15 08:10:24 localhost ignition[690]: INFO     : files: createUsers: op(f): [started]  adding ssh keys to user "goss-homeless"
Nov 15 08:10:24 localhost ignition[690]: INFO     : files: createUsers: op(f): [finished] adding ssh keys to user "goss-homeless"

First sign of trouble

Nov 15 08:22:28 localhost audit[1914]: USER_AUTH pid=1914 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 msg='op=pubkey acct="goss-homeless" exe="/usr/sbin/sshd" hostname=? addr=192.168.1.91 termina>
Nov 15 08:22:28 localhost kernel: audit: type=1100 audit(1573806148.707:208): pid=1914 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 msg='op=pubkey acct="goss-homeless" exe="/usr/sbin/sshd" hostnam>
Nov 15 08:22:28 localhost audit[1914]: USER_AUTH pid=1914 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 msg='op=pubkey acct="goss-homeless" exe="/usr/sbin/sshd" hostname=? addr=192.168.1.91 termina>
Nov 15 08:22:28 localhost kernel: audit: type=1100 audit(1573806148.718:209): pid=1914 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 msg='op=pubkey acct="goss-homeless" exe="/usr/sbin/sshd" hostnam>
Nov 15 08:22:28 localhost sshd[1914]: userauth_pubkey: key type ssh-dss not in PubkeyAcceptedKeyTypes [preauth]
Nov 15 08:22:28 localhost audit[1914]: CRYPTO_KEY_USER pid=1914 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 msg='op=destroy kind=session fp=? direction=both spid=1915 suid=74 rport=60162 laddr=19>
Nov 15 08:22:28 localhost kernel: audit: type=2404 audit(1573806148.737:210): pid=1914 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 msg='op=destroy kind=session fp=? direction=both spid=1915 suid=>
Nov 15 08:22:28 localhost audit[1914]: CRYPTO_KEY_USER pid=1914 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 msg='op=destroy kind=server fp=SHA256:08:22:d5:f5:1c:1e:3b:d9:ca:e6:3c:52:7a:96:b4:5e:5>
Nov 15 08:22:28 localhost audit[1914]: USER_ERR pid=1914 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 msg='op=PAM:bad_ident grantors=? acct="?" exe="/usr/sbin/sshd" hostname=192.168.1.91 addr=192.>
Nov 15 08:22:28 localhost audit[1914]: CRYPTO_KEY_USER pid=1914 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 msg='op=destroy kind=server fp=SHA256:d4:ae:33:68:93:c0:11:e8:f7:15:00:52:4a:b9:5f:3f:f>
Nov 15 08:22:28 localhost audit[1914]: CRYPTO_KEY_USER pid=1914 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 msg='op=destroy kind=server fp=SHA256:bc:b4:98:05:ea:72:99:1e:7e:45:c7:8f:b5:ba:92:40:8>
Nov 15 08:22:28 localhost sshd[1914]: Connection closed by authenticating user goss-homeless 192.168.1.91 port 60162 [preauth]

@keithy
Copy link
Author

keithy commented Nov 15, 2019

I know you guys are focusing on RHCOS where you have a mothership to sort things out later, but I was kind of hoping not to have to make everything into a workaround.

Given that FCOS is such a paired down system, I do think that some thought could go into adding things to compensate, and enable more.

One candidate would be to support the sshd dropins out of the box (it has been requested as an sshd feature), a package/portable services installer is next on my list, and then the safe layered chroot login shell ( http://gitlab.com/keithy/layerbox )

I think that there is a compromise solution to this, and that is to enable ignition to have a registry of "includes", or multiple ignition.files, so that a "workaround" or package loading solution, can be supplied as a plug-in called up from the main ignition file.

@lucab
Copy link
Contributor

lucab commented Nov 18, 2019

@keithy your feedback is appreciated, but I'd rather not throw all those topics into this ticket.

SSHd supporting config fragments would indeed be nice. Most of the time we rely (and block) on relevant upstream developers implementing this kind of features. Do you know where that has been requested, so that we can track that ticket?

EDIT: we are already tracking the "SSHd config fragments" in #138 (comment) and https://bugzilla.mindrot.org/show_bug.cgi?id=2468#c8.

@keithy
Copy link
Author

keithy commented Nov 18, 2019

That's the one. ( https://openssh-bugs.mindrot.narkive.com/XaKiymgd/bug-2468-new-option-to-include-external-files-to-sshd-config ).

I have a plan for creating an ecosystem/market of plug-in modules that can be included at the ignition provisioning stage. Will release something later on this week. This provides a downstream place to publish such things.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants