Posso adicionar automaticamente um novo host ao known_hosts?

Aqui está minha situação: estou configurando um equipamento de teste que, a partir de um cliente central, inicia várias instâncias de máquina virtual e executa comandos nelas via ssh. As máquinas virtuais terão nomes de host e endereços IP anteriormente não utilizados, portanto não estarão no ~/.ssh/known_hostsarquivo no cliente central.

O problema que estou tendo é que o primeiro sshcomando executado em uma nova instância virtual sempre aparece com um prompt interativo:

The authenticity of host '[hostname] ([IP address])' can't be established.
RSA key fingerprint is [key fingerprint].
Are you sure you want to continue connecting (yes/no)?

Existe uma maneira de contornar isso e fazer com que o novo host já seja conhecido pela máquina cliente, talvez usando uma chave pública que já esteja inserida na imagem da máquina virtual? Eu realmente gostaria de evitar ter que usar o Expect ou o que quer que seja para responder ao prompt interativo, se puder.

Defina a StrictHostKeyCheckingopção como no, no arquivo de configuração ou via -o:

ssh -o StrictHostKeyChecking=no username@hostname.com

Na IMO, a melhor maneira de fazer isso é o seguinte:

ssh-keygen -R [hostname]
ssh-keygen -R [ip_address]
ssh-keygen -R [hostname],[ip_address]
ssh-keyscan -H [hostname],[ip_address] >> ~/.ssh/known_hosts
ssh-keyscan -H [ip_address] >> ~/.ssh/known_hosts
ssh-keyscan -H [hostname] >> ~/.ssh/known_hosts

Isso garantirá que não haja entradas duplicadas, que você esteja coberto tanto pelo nome do host quanto pelo endereço IP, e também fará o hash da saída, uma medida extra de segurança.

Para os preguiçosos:

ssh-keyscan -H <host> >> ~/.ssh/known_hosts

-H faz hash no nome do host / endereço IP

Como mencionado, o uso da digitalização de teclas seria a maneira correta e discreta de fazer isso.

ssh-keyscan -t rsa,dsa HOST 2>&1 | sort -u - ~/.ssh/known_hosts > ~/.ssh/tmp_hosts
mv ~/.ssh/tmp_hosts ~/.ssh/known_hosts

O acima será o truque para adicionar um host, SOMENTE se ele ainda não tiver sido adicionado. Também não é seguro para simultaneidade; você não deve executar o snippet na mesma máquina de origem mais de uma vez ao mesmo tempo, pois o arquivo tmp_hosts pode ser derrotado, resultando no inchaço do arquivo known_hosts ...

Você pode usar o ssh-keyscancomando para pegar a chave pública e anexá-la ao seu known_hostsarquivo.

É assim que você pode incorporar o ssh-keyscan no seu jogo:

---
# ansible playbook that adds ssh fingerprints to known_hosts
- hosts: all
  connection: local
  gather_facts: no
  tasks:
  - command: /usr/bin/ssh-keyscan -T 10 {{ ansible_host }}
    register: keyscan
  - lineinfile: name=~/.ssh/known_hosts create=yes line={{ item }}
    with_items: '{{ keyscan.stdout_lines }}'

essa seria uma solução completa, aceitando a chave do host pela primeira vez apenas

#!/usr/bin/env ansible-playbook
---
- name: accept ssh fingerprint automatically for the first time
  hosts: all
  connection: local
  gather_facts: False

  tasks:
    - name: "check if known_hosts contains server's fingerprint"
      command: ssh-keygen -F {{ inventory_hostname }}
      register: keygen
      failed_when: keygen.stderr != ''
      changed_when: False

    - name: fetch remote ssh key
      command: ssh-keyscan -T5 {{ inventory_hostname }}
      register: keyscan
      failed_when: keyscan.rc != 0 or keyscan.stdout == ''
      changed_when: False
      when: keygen.rc == 1

    - name: add ssh-key to local known_hosts
      lineinfile:
        name: ~/.ssh/known_hosts
        create: yes
        line: "{{ item }}"
      when: keygen.rc == 1
      with_items: '{{ keyscan.stdout_lines|default([]) }}'

Eu tive um problema semelhante e descobri que algumas das respostas fornecidas me levaram apenas a uma solução automatizada. A seguir, o que acabei usando, espero que ajude:

ssh -o "StrictHostKeyChecking no" -o PasswordAuthentication=no 10.x.x.x

Ele adiciona a chave known_hostse não solicita a senha.

Então, eu estava procurando uma maneira mundana de ignorar a interação manual host desconhecida de clonar um repositório git, como mostrado abaixo:

brad@computer:~$ git clone git@bitbucket.org:viperks/viperks-api.git
Cloning into 'viperks-api'...
The authenticity of host 'bitbucket.org (104.192.143.3)' can't be established.
RSA key fingerprint is 97:8c:1b:f2:6f:14:6b:5c:3b:ec:aa:46:46:74:7c:40.
Are you sure you want to continue connecting (yes/no)?

Observe a impressão digital da chave RSA ...

Então, isso é uma coisa do SSH, isso funcionará para git sobre SSH e apenas coisas relacionadas ao SSH em geral ...

brad@computer:~$ nmap bitbucket.org --script ssh-hostkey

Starting Nmap 7.01 ( https://nmap.org ) at 2016-10-05 10:21 EDT
Nmap scan report for bitbucket.org (104.192.143.3)
Host is up (0.032s latency).
Other addresses for bitbucket.org (not scanned): 104.192.143.2 104.192.143.1 2401:1d80:1010::150
Not shown: 997 filtered ports
PORT    STATE SERVICE
22/tcp  open  ssh
| ssh-hostkey:
|   1024 35:ee:d7:b8:ef:d7:79:e2:c6:43:9e:ab:40:6f:50:74 (DSA)
|_  2048 97:8c:1b:f2:6f:14:6b:5c:3b:ec:aa:46:46:74:7c:40 (RSA)
80/tcp  open  http
443/tcp open  https

Nmap done: 1 IP address (1 host up) scanned in 42.42 seconds

Primeiro, instale o nmap no seu driver diário. O nmap é altamente útil para certas coisas, como detectar portas abertas e isso - verificar manualmente as impressões digitais SSH. Mas, voltando ao que estamos fazendo.

Boa. Ou estou comprometida nos vários lugares e máquinas em que verifiquei - ou a explicação mais plausível de tudo o que está acontecendo é o que está acontecendo.

Essa 'impressão digital' é apenas uma string reduzida com um algoritmo unidirecional para nossa conveniência humana, com o risco de mais de uma string ser resolvida na mesma impressão digital. Acontece, eles são chamados de colisões.

Independentemente disso, de volta à string original que podemos ver no contexto abaixo.

brad@computer:~$ ssh-keyscan bitbucket.org
# bitbucket.org SSH-2.0-conker_1.0.257-ce87fba app-128
no hostkey alg
# bitbucket.org SSH-2.0-conker_1.0.257-ce87fba app-129
bitbucket.org ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAubiN81eDcafrgMeLzaFPsw2kNvEcqTKl/VqLat/MaB33pZy0y3rJZtnqwR2qOOvbwKZYKiEO1O6VqNEBxKvJJelCq0dTXWT5pbO2gDXC6h6QDXCaHo6pOHGPUy+YBaGQRGuSusMEASYiWunYN0vCAI8QaXnWMXNMdFP3jHAJH0eDsoiGnLPBlBp4TNm6rYI74nMzgz3B9IikW4WVK+dc8KZJZWYjAuORU3jc1c/NPskD2ASinf8v3xnfXeukU0sJ5N6m5E8VLjObPEO+mN2t/FZTMZLiFqPWc/ALSqnMnnhwrNi2rbfg/rd/IpL8Le3pSBne8+seeFVBoGqzHM9yXw==
# bitbucket.org SSH-2.0-conker_1.0.257-ce87fba app-123
no hostkey alg

Portanto, com antecedência, temos uma maneira de solicitar uma forma de identificação ao host original.

Nesse ponto, estamos manualmente tão vulneráveis ​​quanto automaticamente - as cadeias correspondem, temos os dados de base que criam a impressão digital e poderíamos solicitar esses dados de base (evitando colisões) no futuro.

Agora, para usar essa string de uma maneira que evite perguntar sobre a autenticidade dos hosts ...

O arquivo known_hosts nesse caso não usa entradas de texto sem formatação. Você saberá entradas de hash quando as vir; elas se parecem com hashes com caracteres aleatórios em vez de xyz.com ou 123.45.67.89.

brad@computer:~$ ssh-keyscan -t rsa -H bitbucket.org
# bitbucket.org SSH-2.0-conker_1.0.257-ce87fba app-128
|1|yr6p7i8doyLhDtrrnWDk7m9QVXk=|LuKNg9gypeDhfRo/AvLTAlxnyQw= ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAubiN81eDcafrgMeLzaFPsw2kNvEcqTKl/VqLat/MaB33pZy0y3rJZtnqwR2qOOvbwKZYKiEO1O6VqNEBxKvJJelCq0dTXWT5pbO2gDXC6h6QDXCaHo6pOHGPUy+YBaGQRGuSusMEASYiWunYN0vCAI8QaXnWMXNMdFP3jHAJH0eDsoiGnLPBlBp4TNm6rYI74nMzgz3B9IikW4WVK+dc8KZJZWYjAuORU3jc1c/NPskD2ASinf8v3xnfXeukU0sJ5N6m5E8VLjObPEO+mN2t/FZTMZLiFqPWc/ALSqnMnnhwrNi2rbfg/rd/IpL8Le3pSBne8+seeFVBoGqzHM9yXw==

A primeira linha de comentário aparece irritantemente - mas você pode se livrar dela com um redirecionamento simples através da convenção ">" ou ">>".

Como eu fiz o meu melhor para obter dados não contaminados para serem usados ​​para identificar um "host" e confiança, adicionarei essa identificação ao meu arquivo known_hosts no meu diretório ~ / .ssh. Como agora será identificado como um host conhecido, não receberei o prompt mencionado acima quando você era jovem.

Obrigado por ficar comigo, aqui está. Estou adicionando a chave RSA do bitbucket para que eu possa interagir com meus repositórios git de uma maneira não interativa como parte de um fluxo de trabalho de IC, mas faça o que quiser.

#!/bin/bash
cp ~/.ssh/known_hosts ~/.ssh/known_hosts.old && echo "|1|yr6p7i8doyLhDtrrnWDk7m9QVXk=|LuKNg9gypeDhfRo/AvLTAlxnyQw= ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAubiN81eDcafrgMeLzaFPsw2kNvEcqTKl/VqLat/MaB33pZy0y3rJZtnqwR2qOOvbwKZYKiEO1O6VqNEBxKvJJelCq0dTXWT5pbO2gDXC6h6QDXCaHo6pOHGPUy+YBaGQRGuSusMEASYiWunYN0vCAI8QaXnWMXNMdFP3jHAJH0eDsoiGnLPBlBp4TNm6rYI74nMzgz3B9IikW4WVK+dc8KZJZWYjAuORU3jc1c/NPskD2ASinf8v3xnfXeukU0sJ5N6m5E8VLjObPEO+mN2t/FZTMZLiFqPWc/ALSqnMnnhwrNi2rbfg/rd/IpL8Le3pSBne8+seeFVBoGqzHM9yXw==" >> ~/.ssh/known_hosts

Então é assim que você permanece virgem por hoje. Você pode fazer o mesmo com o github seguindo instruções semelhantes no seu próprio tempo.

Vi tantas mensagens de estouro de pilha dizendo para adicionar programaticamente a chave às cegas sem nenhum tipo de verificação. Quanto mais você checa a chave de máquinas diferentes em redes diferentes, mais confiança você tem que o host é o que diz ser - e isso é o melhor que você pode esperar dessa camada de segurança.

ERRADO ssh -oStrictHostKeyChecking = nenhum nome de host [comando]

ERRADO ssh-keyscan -t rsa -H nome do host >> ~ / .ssh / known_hosts

Não faça nenhuma das coisas acima, por favor. Você tem a oportunidade de aumentar suas chances de evitar alguém espionando suas transferências de dados através de um homem no meio do ataque - aproveite essa oportunidade. A diferença é literalmente verificar se a chave RSA que você possui é a do servidor de boa-fé e agora você sabe como obter essas informações para compará-las, para que possa confiar na conexão. Lembre-se de que mais comparações de diferentes computadores e redes geralmente aumentam sua capacidade de confiar na conexão.

Eu faço um script de uma linha, um pouco longo, mas útil para executar esta tarefa em hosts com vários IPs, usando digebash

(host=github.com; ssh-keyscan -H $host; for ip in $(dig @8.8.8.8 github.com +short); do ssh-keyscan -H $host,$ip; ssh-keyscan -H $ip; done) 2> /dev/null >> .ssh/known_hosts

A seguir, evite entradas duplicadas em ~ / .ssh / known_hosts:

if ! grep "$(ssh-keyscan github.com 2>/dev/null)" ~/.ssh/known_hosts > /dev/null; then
    ssh-keyscan github.com >> ~/.ssh/known_hosts
fi

Como você está construindo essas máquinas? você pode executar um script de atualização de DNS? você pode participar de um domínio IPA?

O FreeIPA faz isso automaticamente, mas basicamente tudo o que você precisa é de registros de DNS SSHFP e DNSSEC na sua zona (o freeipa fornece como opções configuráveis ​​(dnssec desativado por padrão)).

Você pode obter os registros SSHFP existentes do seu host executando.

ssh-keygen -r jersey.jacobdevans.com

jersey.jacobdevans.com EM SSHFP 1 1 4d8589de6b1a48e148d8fc9fbb967f1b29f53ebc jersey.jacobdevans.com EM SSHFP 1 2 6503272a11ba6d7fec2518c02dfed88f3d455ac7786ee5dbd72df63307209d55 jersey.jacobdevans.com EM SSHFP 3 1 5a7a1e8ab8f25b86b63c377b303659289b895736> jersey.jacobdevans.com EM SSHFP 3 2 1f50f790117dfedd329dbcf622a7d47551e12ff5913902c66a7da28e47de4f4b

depois de publicado, você adicionaria VerifyHostKeyDNS yesao seu ssh_config ou ~ / .ssh / config

Se / quando o google decidir ativar o DNSSEC, você poderá fazer o ssh sem um prompt de chave de host.

ssh jersey.jacobdevans.com

MAS meu domínio ainda não está assinado, então por enquanto você veria ....

debug1: Chave do host do servidor: ecdsa-sha2-nistp256 SHA256: H1D3kBF9 / t0ynbz2IqfUdVHhL / WROQLGan2ijkfeT0s

debug1: encontrou 4 impressões digitais inseguras no DNS

debug1: impressão digital da chave do host correspondente

encontrado no DNS A autenticidade do host 'jersey.jacobdevans.com (2605: 6400: 10: 434 :: 10)' não pode ser estabelecida. A impressão digital da chave ECDSA é SHA256: H1D3kBF9 / t0ynbz2IqfUdVHhL / WROQLGan2ijkfeT0s. Impressão digital da chave do host correspondente encontrada no DNS. Tem certeza de que deseja continuar se conectando (sim / não)? não

Para fazer isso corretamente, o que você realmente deseja fazer é coletar as chaves públicas do host das VMs enquanto você as cria e soltá-las em um arquivo no known_hostsformato. Em seguida, você pode usar o -o GlobalKnownHostsFile=..., apontando para esse arquivo, para garantir que você esteja se conectando ao host em que acredita estar conectado. Entretanto, como você faz isso depende de como você está configurando as máquinas virtuais, mas lê-lo no sistema de arquivos virtual, se possível, ou até mesmo fazer com que o host imprima o conteúdo /etc/ssh/ssh_host_rsa_key.pubdurante a configuração pode ajudar.

Dito isto, isso pode não valer a pena, dependendo do tipo de ambiente em que você está trabalhando e de quem são seus adversários esperados. Fazer um simples "armazenamento na primeira conexão" (por meio de uma varredura ou simplesmente durante a primeira conexão "real"), conforme descrito em várias outras respostas acima, pode ser consideravelmente mais fácil e ainda fornecer um pouco de segurança. No entanto, se você fizer isso, sugiro fortemente que você altere o arquivo hosts conhecidos do usuário ( -o UserKnownHostsFile=...) para um arquivo específico para esta instalação de teste específica; isso evitará poluir seu arquivo de hosts conhecidos pessoais com informações de teste e facilitará a limpeza das chaves públicas agora inúteis quando você excluir suas VMs.

Esse todo

• verificação de chave ssh
• ssh-copy-id
• Aviso de chave ECSDA

os negócios continuaram me irritando, então optei por

Um script para governar todos eles

Esta é uma variante do script em https://askubuntu.com/a/949731/129227 com a resposta de Amadu Bah https://serverfault.com/a/858957/162693 em um loop.

chamada de exemplo

./schcheck somedomain site1 site2 site3

O script fará um loop nos sites de nomes e modificará o arquivo .ssh / config e .ssh / known_hosts e executará ssh-copy-id mediante solicitação - para o último recurso, deixe as chamadas de teste do ssh falharem, por exemplo, pressionando Enter 3 vezes em a solicitação de senha.

script sshcheck

#!/bin/bash
# WF 2017-08-25
# check ssh access to bitplan servers

#ansi colors
#http://www.csc.uvic.ca/~sae/seng265/fall04/tips/s265s047-tips/bash-using-colors.html
blue='\033[0;34m'  
red='\033[0;31m'  
green='\033[0;32m' # '\e[1;32m' is too bright for white bg.
endColor='\033[0m'

#
# a colored message 
#   params:
#     1: l_color - the color of the message
#     2: l_msg - the message to display
#
color_msg() {
  local l_color="$1"
  local l_msg="$2"
  echo -e "${l_color}$l_msg${endColor}"
}

#
# error
#
#   show an error message and exit
#
#   params:
#     1: l_msg - the message to display
error() {
  local l_msg="$1"
  # use ansi red for error
  color_msg $red "Error: $l_msg" 1>&2
  exit 1
}

#
# show the usage
#
usage() {
  echo "usage: $0 domain sites"
  exit 1 
}

#
# check known_hosts entry for server
#
checkknown() {
  local l_server="$1"
  #echo $l_server
  local l_sid="$(ssh-keyscan $l_server 2>/dev/null)" 
  #echo $l_sid
  if (! grep "$l_sid" $sknown) > /dev/null 
  then
    color_msg $blue "adding $l_server to $sknown"
    ssh-keyscan $l_server >> $sknown 2>&1
  fi
}

#
# check the given server
#
checkserver() {
  local l_server="$1"
  grep $l_server $sconfig > /dev/null
  if [ $? -eq 1 ]
  then
    color_msg $blue "adding $l_server to $sconfig"
    today=$(date "+%Y-%m-%d")
    echo "# added $today by $0"  >> $sconfig
    echo "Host $l_server" >> $sconfig
    echo "   StrictHostKeyChecking no" >> $sconfig
    echo "   userKnownHostsFile=/dev/null" >> $sconfig
    echo "" >> $sconfig
    checkknown $l_server
  else
    color_msg $green "$l_server found in $sconfig"
  fi
  ssh -q $l_server id > /dev/null
  if [ $? -eq 0 ]
  then
    color_msg $green "$l_server accessible via ssh"
  else
    color_msg $red "ssh to $l_server failed" 
    color_msg $blue "shall I ssh-copy-id credentials to $l_server?"
    read answer
    case $answer in
      y|yes) ssh-copy-id $l_server
    esac
  fi
}

#
# check all servers
#
checkservers() {
me=$(hostname -f)
for server in $(echo $* | sort)
do
  os=`uname`
  case $os in
   # Mac OS X
   Darwin*)
     pingoption=" -t1";;
    *) ;;
  esac

  pingresult=$(ping $pingoption -i0.2 -c1 $server)
  echo $pingresult | grep 100 > /dev/null
  if [ $? -eq 1 ]
  then 
    checkserver $server
    checkserver $server.$domain
  else
    color_msg $red "ping to $server failed"
  fi
done
}

#
# check configuration
#
checkconfig() {
#https://askubuntu.com/questions/87449/how-to-disable-strict-host-key-checking-in-ssh
  if [ -f $sconfig ]
  then
    color_msg $green "$sconfig exists"
    ls -l $sconfig
  fi
}

sconfig=~/.ssh/config
sknown=~/.ssh/known_hosts

case  $# in
  0) usage ;;
  1) usage ;;
  *) 
    domain=$1 
    shift 
    color_msg $blue "checking ssh configuration for domain $domain sites $*"
    checkconfig
    checkservers $* 
    #for server in $(echo $* | sort)
    ##do
    #  checkknown $server 
    #done
    ;;
esac

Aqui está como fazer uma coleção de hosts

definir uma coleção de hosts

ssh_hosts:
  - server1.domain.com
  - server2.domain.com
  - server3.domain.com
  - server4.domain.com
  - server5.domain.com
  - server6.domain.com
  - server7.domain.com
  - server8.domain.com
  - server9.domain.com

Em seguida, defina duas tarefas para adicionar as chaves aos hosts conhecidos:

- command: "ssh-keyscan {{item}}"
   register: known_host_keys
   with_items: "{{ssh_hosts}}"
   tags:
     - "ssh"

 - name: Add ssh keys to know hosts
   known_hosts:
     name: "{{item.item}}"
     key: "{{item.stdout}}"
     path: ~/.ssh/known_hosts
   with_items: "{{known_host_keys.results}}"

O melhor seria verificar a impressão digital de cada novo servidor / host. Essa é a única maneira de autenticar o servidor. Sem ele, sua conexão SSH pode estar sujeita a um ataque man-in-the-middle .

Se você realmente tem certeza de que deseja ignorar a verificação da impressão digital, a segunda opção melhor e menos segura é usar StrictHostKeyChecking=accept-new, que foi introduzida no OpenSSH versão 7.6 (2017-10-03) :

O primeiro "accept-new" aceitará automaticamente chaves até então invisíveis, mas recusará conexões para chaves de host alteradas ou inválidas.

Não use o valor antigo, StrictHostKeyChecking=noque nunca verifica a autenticidade do servidor. (Embora o significado dessa =noconfiguração seja alterado algumas versões mais tarde .)