SSH falha no CoreOS ao substituir variáveis cloud-config do etcd

Question

Eu tenho uma configuração mínima de nuvem que funciona sem problemas no DigitalOcean. Eu adicionei alguns hardening para SSH, o que requer a reinicialização de sshd.socket para se tornar efetiva:

units:
  - name: sshd.socket
    command: restart

Adicionar esta unidade sozinha (sem alterações na configuração real do sshd) faz com que o provisionamento com a mesma configuração de nuvem falhe ao tentar isso no Hetzner: ssh: connect to host xx.xx.xx.xx port 22: Connection refused . Ele ainda se conecta bem em DigitalOcean embora.

Quando eu removo esta unidade, a conexão com a máquina Hetzner funciona bem, e adicioná-la novamente falha de forma consistente.

Substituição variável

A única diferença entre as duas plataformas que eu conheço é que no DigitalOcean as variáveis $public_ipv4 e $private_ipv4 são substituídas por endereços IP reais, o que não é o caso de instalações bare-metal como a Hetzner.

A partir da Documentação do CoreOS :

Note: The $private_ipv4 and $public_ipv4 substitution variables referenced in other documents are only supported on Amazon EC2, Google Compute Engine, OpenStack, Rackspace, DigitalOcean, and Vagrant.

Então, eu substituo as variáveis pelo endereço IP estático. Eu uso o endereço IP público porque essa é a única interface disponível além do loopback.

No entanto, quando eu provisiono sem substituir essas variáveis pelo endereço IP público, também se conecta bem.

Inspecionar o diário revela alguns erros relacionados à resolução de nomes:

systemd[1]: Starting etcd2...
etcd2[874]: recognized and used environment variable ETCD_ADVERTISE_CLIENT_URLS=http://:2379,http://:4001
etcd2[874]: recognized and used environment variable ETCD_DATA_DIR=/var/lib/etcd2
etcd2[874]: recognized and used environment variable ETCD_DISCOVERY=https://discovery.etcd.io/616b3957c5c78e7738207011f9c51841
etcd2[874]: recognized and used environment variable ETCD_INITIAL_ADVERTISE_PEER_URLS=http://:2380
etcd2[874]: recognized and used environment variable ETCD_LISTEN_CLIENT_URLS=http://0.0.0.0:2379,http://0.0.0.0:4001
etcd2[874]: recognized and used environment variable ETCD_LISTEN_PEER_URLS=http://:2380
etcd2[874]: recognized and used environment variable ETCD_NAME=39b2a003672546f8a0b648dbc66e8f6f
etcd2[874]: etcd Version: 2.2.0
etcd2[874]: Git SHA: e4561dd
etcd2[874]: Go Version: go1.4.2
etcd2[874]: Go OS/Arch: linux/amd64
etcd2[874]: setting maximum number of CPUs to 1, total number of available CPUs is 12
etcd2[874]: listening for peers on http://:2380
etcd2[874]: listening for client requests on http://0.0.0.0:2379
etcd2[874]: listening for client requests on http://0.0.0.0:4001
etcd2[874]: resolving :2380 to :2380
etcd2[874]: resolving :2380 to :2380
etcd2[874]: error #0: dial tcp: lookup discovery.etcd.io: Temporary failure in name resolution
etcd2[874]: cluster status check: error connecting to https://discovery.etcd.io, retrying in 2s
etcd2[874]: error #0: dial tcp: lookup discovery.etcd.io: Temporary failure in name resolution
etcd2[874]: cluster status check: error connecting to https://discovery.etcd.io, retrying in 4s
etcd2[874]: found self 61dbc8c9c2aca1e8 in the cluster
etcd2[874]: found 1 needed peer(s)

Mas eles não parecem fatais: systemctl status etcd2.service mostra que o serviço está ativo:

core@localhost ~ $ systemctl status etcd2.service
● etcd2.service - etcd2
   Loaded: loaded (/usr/lib64/systemd/system/etcd2.service; disabled; vendor preset: disabled)
  Drop-In: /run/systemd/system/etcd2.service.d
           └─20-cloudinit.conf
   Active: active (running) since Tue 2016-03-22 14:10:33 UTC; 7min ago
 Main PID: 874 (etcd2)
   Memory: 20.3M
      CPU: 1.771s
   CGroup: /system.slice/etcd2.service
           └─874 /usr/bin/etcd2

etcd2[874]: added local member 61dbc8c9c2aca1e8 [http://:2380] to cluster 216c373aaf11ccfa
systemd[1]: Started etcd2.
etcd2[874]: 61dbc8c9c2aca1e8 is starting a new election at term 1
etcd2[874]: 61dbc8c9c2aca1e8 became candidate at term 2
etcd2[874]: 61dbc8c9c2aca1e8 received vote from 61dbc8c9c2aca1e8 at term 2
etcd2[874]: 61dbc8c9c2aca1e8 became leader at term 2
etcd2[874]: raft.node: 61dbc8c9c2aca1e8 elected leader 61dbc8c9c2aca1e8 at term 2
etcd2[874]: published {Name:39b2a003672546f8a0b648dbc66e8f6f ClientURLs:[http://:2379 http://:4001]} to cluster 216c373aaf11ccfa
etcd2[874]: setting up the initial cluster version to 2.2
etcd2[874]: set the initial cluster version to 2.2

Os contêineres que se conectam a outros serviços, como o Logstash, falham: the scheme http does not accept registry part: :9200 (or bad hostname?)

Cloud-config

Esta é uma configuração de nuvem simplificada, mas ainda demonstra o problema (verificado isso).

#cloud-config

ssh_authorized_keys:
  - "ssh-rsa A valid SSH key here"
write_files:
coreos:
  etcd2:
    # NOTE: replace $discovery_url with a url generated at https://discovery.etcd.io/new?size=X
    discovery: $discovery_url
    listen-client-urls: http://0.0.0.0:2379,http://0.0.0.0:4001
    advertise-client-urls: http://my.public.ip.address:2379,http://my.public.ip.address:4001
    initial-advertise-peer-urls: http://my.public.ip.address:2380
    listen-peer-urls: http://my.public.ip.address:2380          # Remove this flag or use localhost and the connection issue goes away
  units:
    - name: etcd2.service
      command: start
    - name: fleet.service
      command: start
    - name: sshd.socket
      command: restart   # Remove this unit and all issues go away (but no SSH hardening in that case)

Uma coisa que notei é que quando eu removo a bandeira listen-peer-urls , o problema de conexão também desaparece, embora o logstash ainda não seja iniciado pela mesma razão.

Este documento diz que o valor padrão para esses sinalizadores são URLs com localhost , mas o nome das variáveis de substituição usadas em plataformas como DigitalOcean parecem sugerir que esse deve ser um endereço que pode ser acessado por máquinas de mesmo nível.

Quando eu uso localhost para esses sinalizadores, posso conectar, mas os outros problemas ainda estão lá.

Questão 1

Qual deve ser a configuração de nuvem adequada para máquinas bare-metal que tenham apenas uma interface pública e de loopback (sem rede privada)?

Questão 2

Qual é a relação entre o sshd e o etcd que causa essa falha?

    

Answer 1

What should be the proper cloud-config for bare metal machines that have a public and loopback interface only (no private network)?

Insira o IP público da máquina no lugar dessas variáveis.

What is the relationship between sshd and etcd here that causes this failure?

Você pode compartilhar o log do sshd? Por que não está começando?