Kevin Keane's questions

Frequentemente crio e destruo máquinas virtuais e me conecto a elas via SSH.

O sistema operacional é RedHat Enterprise Linux versões 7 ou 8 (acontece com ambos) no lado do cliente e do servidor e, claro, openssh como servidor SSH.

A primeira conexão SSH sempre relatará a falta de chaves de host, a menos que eu use ssh-keyscan para pré-preencher meu arquivo known_hosts. É claro que isso é esperado.

Em seguida, configuro o sistema (geralmente usando o Ansible, mas também observei o problema antes mesmo do Ansible ser executado) e, inevitavelmente, toda vez, ao reconectar, o SSH relata que uma das chaves do host foi alterada.

Warning: the ED25519 host key for 'redacted' differs
from the key for the IP address 'redacted' Offending key for IP
in /redacted/.ssh/known_hosts:424 Matching host key in
/redacted/.ssh/known_hosts:362

Também verifiquei o /etc/ssh do lado do servidor e descobri que todas as chaves do host têm o mesmo carimbo de hora, portanto, a chave do host ED25519 não foi alterada.

-rw-r-----.  1 root ssh_keys  480 Aug  6 17:26 ssh_host_ecdsa_key
-rw-r--r--.  1 root root      162 Aug  6 17:26 ssh_host_ecdsa_key.pub
-rw-r-----.  1 root ssh_keys  387 Aug  6 17:26 ssh_host_ed25519_key
-rw-r--r--.  1 root root       82 Aug  6 17:26 ssh_host_ed25519_key.pub
-rw-r-----.  1 root ssh_keys 2.6K Aug  6 17:26 ssh_host_rsa_key
-rw-r--r--.  1 root root      554 Aug  6 17:26 ssh_host_rsa_key.pub

Estou procurando entender por que known_hosts primeiro é preenchido com uma chave ED25519 diferente daquela usada em conexões subsequentes.

Não estou procurando correções da natureza "editar seu arquivo known_hosts". Eu sei como fazer isso (consulte também Como corrigir o aviso sobre a chave do host ECDSA se quiser saber mais). Na grande escala que às vezes estou trabalhando (às vezes centenas de sistemas) é muito tedioso. Além disso, simplesmente manipular o arquivo known_hosts sem entender o motivo pelo qual uma chave foi alterada pode ser uma preocupação de segurança.

O que estou procurando é uma compreensão mais profunda do que está acontecendo e como evitar que isso aconteça, ou pelo menos como resolvê-lo automaticamente (sem comprometer a segurança!)

Atualização inspirada em Frank Thomas:

O problema acontece independentemente de eu ter reutilizado um endereço IP usado anteriormente ou um novo (a maioria é nova na minha situação).

Outra observação possivelmente relevante: no meu arquivo known_hosts, as chaves de host rsa e edcsa estão associadas ao FQDN. Existem duas entradas para as chaves do host ed25519. Um está associado ao FQDN, enquanto o outro está associado ao endereço IP.

O problema parece sempre se referir à versão da chave associada ao endereço IP.

Mais detalhes sobre como meu arquivo known_hosts é preenchido:

Primeiro, exclua todas as entradas de known_host existentes. O nome de host dos hosts getent obviamente retornará o endereço IP e o nome do host.

for host in $h $(getent hosts $h)
do
  /usr/bin/ssh-keygen -R $host 2>&1 >/dev/null
done

Em seguida, recupere as novas chaves:

/usr/bin/ssh-keyscan $h 2>/dev/null >> ~/.ssh/known_hosts

Isso apenas preenche o rsa e a chave do host ED25519 pelo nome do host.

A chave do host ECDSA e a chave ED25519 por endereço IP são preenchidas pela primeira conexão SSH. Isso parece funcionar bem para a chave do host ECDSA, mas aparentemente não para a chave ED25519.

Estou procurando integrar o provisionamento por inicialização PXE de um RedHat Satellite Server com um Windows Deployment Server.

Para fazer isso, quero que o carregador de inicialização syslinux (não UEFI) do WDS carregue outro carregador de inicialização EFI (grub2/grubx64.efi) em vez de um kernel Linux. Isso deve ser carregado via TFTP, pois o sistema a ser provisionado ainda não possui nenhum carregador de inicialização instalado no disco rígido.

Isso é possível?

Fundo:

Em uma configuração ideal somente para Satellite, o Satellite Server gosta de ter controle sobre o DHCP para definir seu próprio próximo servidor e opções de arquivo. Em seguida, ele carrega um dos carregadores de inicialização PXE por TFTP, que por sua vez inicia o kernel. O Servidor Satellite manipularia o servidor DHCP para definir o carregador de inicialização correto (no nosso caso, sempre o mesmo, grub2/grubx64.efi), e também para definir os argumentos de kernel corretos que o grub usaria.

Temos um ambiente misto e nosso DHCP sempre apontará para um carregador de inicialização syslinux. Posso adicionar algo ao menu do syslinux, mas não posso substituir o syslinux.

A solução ingênua seria replicar a linha de comando do kernel no syslinux, mas isso não funciona porque a linha de comando do kernel é diferente para cada host (inclui o endereço MAC).

Portanto, eu preciso de uma maneira de obter o syslinux para carregar o carregador grub2/grubx64.efi, o que iniciaria o resto do processo.

Em meu manual do Ansible, preciso alterar as permissões em muitos arquivos, mas alguns subdiretórios precisam de permissões de leitura e gravação, enquanto a maioria precisa de somente leitura. Seguindo outra sugestão do superusuário, tenho esta solução:

- name: A few directories need group-write permissions
  file:
    path: "{{item}}"
    mode: "u+rwX,g+rwX,o+rX,o-w"
    recurse: True
  with_items:
    - /opt/myapp/path1/excludeddir1
    - /opt/myapp/path1/excludeddir2
    - /opt/myapp/path2/excludeddir1
    - /opt/myapp/path2/excludeddir2

- name: For performance, set a lot of directories directly
  file:
    path: "{{item}}"
    mode: "u+rwX,go+rX,go-w"
    recurse: True
  with_items:
    - /opt/myapp/path1/readonlydir1
    - /opt/myapp/path1/readonlydir2

#############################################
# This step generates a very large list
- name: Find all files in my directory
  find:
    paths:
      - "/opt/myapp/path1"
      - "/opt/myapp/path2"
    recurse: True
    file_type: any
    follow: False
  register: filestochange

#############################################
# This step is painfully slow
- name: Clear group-write permissions where needed
  file:
    path: "{{ item.path }}"
    mode: "u+rwX,go+rX,go-w"
    follow: False
  when:
    - not item.islnk
    - "'/opt/myapp/path1/excludeddir1' not in item.path"
    - "'/opt/myapp/path1/excludeddir2' not in item.path"
    - "'/opt/myapp/path2/excludeddir1' not in item.path"
    - "'/opt/myapp/path2/excludeddir2' not in item.path"
    - "'/opt/myapp/path1/readonlydir1' not in item.path
    - "'/opt/myapp/path1/readonlydir2' not in item.path
  loop: "{{ filestochange.files }}"
  loop_control:
    label: "{{ item.path }}"

Os subdiretórios envolvidos possuem um total de aproximadamente 100k arquivos.

O código acima funciona, mas é, não surpreendentemente, dolorosamente lento. A implementação original, em sua maioria ingênua, durou dois dias seguidos.

Minha primeira otimização foi definir as permissões para alguns subdiretórios que não precisam de exceções e, posteriormente, ignorá-los no loop. Isso ajudou até certo ponto; o tempo agora caiu para uma ou duas horas.

Como próxima otimização, gostaria de remover essas mesmas entradas da lista que o módulo find gera antes mesmo de alimentá-lo no loop, mas não encontrei uma maneira de fazer isso.

O módulo de arquivo tem um atributo de exclusão, mas isso parece corresponder apenas a nomes de arquivos, não a nomes de diretórios.

Portanto, estou procurando uma maneira de remover itens de uma lista que correspondam a certos padrões curinga.

É claro que também estou aberto a outras sugestões de como otimizar ainda mais isso.

Observação: essa implementação ingênua NÃO funciona, pois redefiniria e, em seguida, definiria as permissões.

- name: Set everything to G read-only
  file:
    path: "{{item}}"
    mode: "u+rwX,go+rX,go-w"
    recurse: True
  with_items:
    - /opt/myapp/path1
    - /opt/myapp/path2

- name: A few directories need group-write permissions
  file:
    path: "{{item}}"
    mode: "u+rwX,g+wrX,o+rX,o-w"
    recurse: True
  with_items:
    - /opt/myapp/path1/excludeddir1
    - /opt/myapp/path1/excludeddir2
    - /opt/myapp/path2/excludeddir1
    - /opt/myapp/path2/excludeddir2

Estou tentando descobrir como usar o Ansible para definir permissões em uma árvore de diretórios para que o padrão seja 644 como padrão (755 para diretórios, é claro), exceto para um diretório que precisa de permissões 664/775.

A implementação ingênua seria esta:

file:
    path: "mypath"
    mode: "u+rwX,go+rX,go-w"
    recurse: True

file:
    path: "mypath/exception"
    mode: "g+w"
    recurse: True

No entanto, isso obviamente não é idempotente. A cada execução, mypath/exception terá as permissões de gravação de grupo removidas e imediatamente adicionadas novamente.

A alternativa é enumerar cada subdiretório individual em mypath/*, o que espero evitar.

Existe outra maneira de fazer isso de maneira idempotente?