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

bootstrapping instance without ssh key fails coreos-metadata-sshkeys unit #2312

Closed
zyclonite opened this Issue Jan 9, 2018 · 5 comments

Comments

Projects
None yet
3 participants
@zyclonite

zyclonite commented Jan 9, 2018

Issue Report

Bug

Container Linux Version

NAME="Container Linux by CoreOS"
ID=coreos
VERSION=1576.5.0
VERSION_ID=1576.5.0
BUILD_ID=2018-01-05-1121
PRETTY_NAME="Container Linux by CoreOS 1576.5.0 (Ladybug)"
ANSI_COLOR="38;5;75"
HOME_URL="https://coreos.com/"
BUG_REPORT_URL="https://issues.coreos.com"
COREOS_BOARD="amd64-usr"

Environment

AWS EC2

Expected Behavior

bootstrapping a new instance without a ssh-key
all units run/start without any failure

Actual Behavior

since version 1576.4.0 we get

Failed Units: 1
  coreos-metadata-sshkeys@core.service
systemd[1]: Starting CoreOS Metadata Agent (SSH Keys)...
coreos-metadata[726]: Error: writing ssh keys
coreos-metadata[726]: Caused by: failed to update authorized keys
coreos-metadata[726]: Caused by: update-ssh-keys: no keys found in "/home/core/.ssh/authorized_keys.d"
systemd[1]: coreos-metadata-sshkeys@core.service: Main process exited, code=exited, status=1/FAILURE

Reproduction Steps

  1. you need a ldap server setup (enabling you to login)
  2. use https://console.aws.amazon.com/ec2/home?region=eu-west-1#launchAmi=ami-32d1474b to launch your instance
  3. configure with the below ignition config
  4. choose to "Proceed without a key pair" and confirm

ignition-config.json

(file contents removed due to size and sensitive data)

{
  "ignition": {
    "config": {},
    "timeouts": {},
    "version": "2.1.0"
  },
  "networkd": {},
  "passwd": {},
  "storage": {
    "files": [
      {
        "filesystem": "root",
        "group": {},
        "path": "/etc/sssd/sssd.conf",
        "user": {
          "id": 0
        },
        "contents": {
          "source": "<...>",
          "verification": {}
        },
        "mode": 384
      },
      {
        "filesystem": "root",
        "group": {},
        "path": "/etc/ssh/sshd_config",
        "user": {
          "id": 0
        },
        "contents": {
          "source": "<...>",
          "verification": {}
        },
        "mode": 384
      }
    ]
  },
  "systemd": {
    "units": [
      {
        "enable": true,
        "name": "sssd.service"
      }
    ]
  }
}

Other Information

@bgilbert

This comment has been minimized.

Show comment
Hide comment
@bgilbert

bgilbert Jan 9, 2018

Member

kola doesn't test this. It tries putting the SSH key only in platform metadata, and putting it only in userdata, but there are no tests that use no SSH keys at all.

Member

bgilbert commented Jan 9, 2018

kola doesn't test this. It tries putting the SSH key only in platform metadata, and putting it only in userdata, but there are no tests that use no SSH keys at all.

@sdemos

This comment has been minimized.

Show comment
Hide comment
@sdemos

sdemos Jan 11, 2018

Member

A workaround for this issue is to mask coreos-metadata-sshkeys@core.service in your ignition config. If you don't have any ssh keys for it to add to core, it wouldn't do anything anyway.

The fundamental issue here is that coreos-metadata shouldn't call update-ssh-keys at all unless it has ssh keys to add. Right now, it only checks if a user has been provided when deciding whether or not to try and write the ssh keys. It assumes that if a user has been provided then there are ssh keys to retrieve and write to disk, which is a faulty assumption. Instead it should only open the authorized keys directory if it has keys to write to it.

Member

sdemos commented Jan 11, 2018

A workaround for this issue is to mask coreos-metadata-sshkeys@core.service in your ignition config. If you don't have any ssh keys for it to add to core, it wouldn't do anything anyway.

The fundamental issue here is that coreos-metadata shouldn't call update-ssh-keys at all unless it has ssh keys to add. Right now, it only checks if a user has been provided when deciding whether or not to try and write the ssh keys. It assumes that if a user has been provided then there are ssh keys to retrieve and write to disk, which is a faulty assumption. Instead it should only open the authorized keys directory if it has keys to write to it.

@zyclonite

This comment has been minimized.

Show comment
Hide comment
@zyclonite

zyclonite Jan 11, 2018

masking is a valid option, i can live with the failed service as well... the behavior simple changed in the most recent releases, this was the main reason for reporting it

zyclonite commented Jan 11, 2018

masking is a valid option, i can live with the failed service as well... the behavior simple changed in the most recent releases, this was the main reason for reporting it

@bgilbert

This comment has been minimized.

Show comment
Hide comment
@bgilbert

bgilbert Jan 11, 2018

Member

@zyclonite Yep, it's a regression, and we'll get it fixed. Thanks for reporting.

Member

bgilbert commented Jan 11, 2018

@zyclonite Yep, it's a regression, and we'll get it fixed. Thanks for reporting.

@bgilbert

This comment has been minimized.

Show comment
Hide comment
@bgilbert

bgilbert Jul 6, 2018

Member

Fixed upstream in coreos/coreos-metadata#97. Leaving open until the change merges to overlay.

Member

bgilbert commented Jul 6, 2018

Fixed upstream in coreos/coreos-metadata#97. Leaving open until the change merges to overlay.

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