¿Puedo agregar automáticamente un nuevo host a known_hosts?

Aquí está mi situación: estoy configurando un arnés de prueba que, desde un cliente central, lanzará varias instancias de máquinas virtuales y luego ejecutará comandos en ellas a través de ssh. Las máquinas virtuales tendrán nombres de host y direcciones IP previamente no utilizados, por lo que no estarán en el ~/.ssh/known_hostsarchivo del cliente central.

El problema que tengo es que el primer sshcomando ejecutado contra una nueva instancia virtual siempre aparece con un mensaje interactivo:

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)?

¿Hay alguna forma de evitar esto y hacer que el nuevo host sea conocido por la máquina del cliente, tal vez usando una clave pública que ya está integrada en la imagen de la máquina virtual? Realmente me gustaría evitar tener que usar Expect o lo que sea para responder el mensaje interactivo si puedo.

Establezca la StrictHostKeyCheckingopción en no, ya sea en el archivo de configuración o mediante -o:

ssh -o StrictHostKeyChecking=no [email protected]

En mi opinión, la mejor manera de hacer esto es la siguiente:

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

Eso asegurará que no haya entradas duplicadas, que esté cubierto tanto para el nombre de host como para la dirección IP, y también hará un hash de la salida, una medida de seguridad adicional.

Para los flojos:

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

-H cambia el nombre de host / dirección IP

Como se mencionó, usar el escaneo de teclas sería la forma correcta y discreta de hacerlo.

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

Lo anterior hará el truco para agregar un host, SOLO si aún no se ha agregado. Tampoco es seguro para la concurrencia; no debe ejecutar el fragmento en la misma máquina de origen más de una vez al mismo tiempo, ya que el archivo tmp_hosts puede bloquearse, lo que finalmente hace que el archivo conocido_hosts se hinche ...

Puede usar el ssh-keyscancomando para tomar la clave pública y agregarla a su known_hostsarchivo.

Así es como puedes incorporar ssh-keyscan en tu juego:

---
# 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 }}'

esta sería una solución completa, aceptando la clave de host solo por primera vez

#!/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([]) }}'

Tuve un problema similar y descubrí que algunas de las respuestas proporcionadas solo me llevaron a una solución automatizada. Lo siguiente es lo que terminé usando, espero que ayude:

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

Agrega la clave known_hostsy no solicita la contraseña.

Entonces, estaba buscando una forma mundana para evitar la interacción manual del host desconocido de clonar un repositorio git como se muestra a continuación:

brad@computer:~$ git clone [email protected]: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)?

Tenga en cuenta la huella digital de la clave RSA ...

Entonces, esto es algo de SSH, esto funcionará para git sobre SSH y solo cosas relacionadas con SSH en general ...

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

Primero, instale nmap en su controlador diario. nmap es muy útil para ciertas cosas, como detectar puertos abiertos y esto: verificar manualmente las huellas dactilares SSH. Pero, volviendo a lo que estamos haciendo.

Bueno. Estoy comprometido en los múltiples lugares y máquinas que lo he comprobado, o la explicación más plausible de que todo es Hunky Dory es lo que está sucediendo.

Esa 'huella digital' es solo una cadena acortada con un algoritmo unidireccional para nuestra conveniencia humana, a riesgo de que más de una cadena se resuelva en la misma huella digital. Sucede, se llaman colisiones.

En cualquier caso, volvamos a la cadena original que podemos ver en contexto a continuación.

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

Entonces, con anticipación, tenemos una forma de solicitar una forma de identificación del host original.

En este punto, manualmente somos tan vulnerables como automáticamente: las cadenas coinciden, tenemos los datos base que crean la huella digital y podríamos pedir esos datos base (para evitar colisiones) en el futuro.

Ahora, para usar esa cadena de una manera que evite preguntar sobre la autenticidad de un host ...

El archivo conocido_hosts en este caso no utiliza entradas de texto sin formato. Sabrás las entradas hash cuando las veas, se ven como hashes con caracteres aleatorios en lugar de xyz.com o 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==

La primera línea de comentarios aparece exasperantemente, pero puede deshacerse de ella con una simple redirección a través de la convención ">" o ">>".

Como he hecho todo lo posible para obtener datos no contaminados que se utilizarán para identificar un "host" y confianza, agregaré esta identificación a mi archivo conocido_hosts en mi directorio ~ / .ssh. Como ahora se identificará como un host conocido, no recibiré el mensaje mencionado anteriormente cuando eras joven.

Gracias por quedarte conmigo, aquí tienes. Estoy agregando la clave RSA de bitbucket para que pueda interactuar con mis repositorios git allí de forma no interactiva como parte de un flujo de trabajo de CI, pero haga lo que haga lo que quiera.

#!/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

Entonces, así es como te mantienes virgen por hoy. Puede hacer lo mismo con github siguiendo instrucciones similares en su propio tiempo.

Vi tantas publicaciones de desbordamiento de pila que le dicen que agregue la clave mediante programación a ciegas sin ningún tipo de comprobación. Cuanto más verifique la clave de diferentes máquinas en diferentes redes, más confianza tendrá en que el host es el que dice que es, y eso es lo mejor que puede esperar de esta capa de seguridad.

INCORRECTO ssh -oStrictHostKeyChecking = sin nombre de host [comando]

INCORRECTO ssh-keyscan -t rsa -H nombre de host >> ~ / .ssh / known_hosts

No hagas ninguna de las cosas anteriores, por favor. Tienes la oportunidad de aumentar tus posibilidades de evitar que alguien escuche tus transferencias de datos a través de un hombre en el medio del ataque. Aprovecha esa oportunidad. La diferencia es verificar literalmente que la clave RSA que tiene es la del servidor de buena fe y ahora sabe cómo obtener esa información para compararla y poder confiar en la conexión. Solo recuerde que más comparaciones de diferentes computadoras y redes generalmente aumentarán su capacidad de confiar en la conexión.

Hago un script de una sola línea, un poco largo pero útil para hacer esta tarea para hosts con múltiples IP, usando digybash

(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

Lo siguiente evita entradas duplicadas en ~ / .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

¿Cómo estás construyendo estas máquinas? ¿puedes ejecutar un script de actualización dns? ¿Puedes unirte a un dominio IPA?

FreeIPA hace esto automáticamente, pero esencialmente todo lo que necesita es SSHFP dns records y DNSSEC en su zona (freeipa proporciona opciones configurables (dnssec está deshabilitado por defecto)).

Puede obtener los registros SSHFP existentes de su host ejecutando.

ssh-keygen -r jersey.jacobdevans.com

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

luego, una vez publicado, agregaría VerifyHostKeyDNS yesa su ssh_config o ~ / .ssh / config

Si / cuando google decide activar DNSSEC, puede ingresar sin un indicador de hostkey.

ssh jersey.jacobdevans.com

PERO mi dominio aún no está firmado, así que por ahora verías ...

debug1: clave de host del servidor: ecdsa-sha2-nistp256 SHA256: H1D3kBF9 / t0ynbz2IqfUdVHhL / WROQLGan2ijkfeT0s

debug1: se encontraron 4 huellas digitales inseguras en DNS

debug1: huella digital de clave de host coincidente

encontrado en DNS La autenticidad del host 'jersey.jacobdevans.com (2605: 6400: 10: 434 :: 10)' no se puede establecer. La huella digital de la clave ECDSA es SHA256: H1D3kBF9 / t0ynbz2IqfUdVHhL / WROQLGan2ijkfeT0s. Huella digital de clave de host coincidente encontrada en DNS. ¿Estás seguro de que deseas continuar conectando (sí / no)? No

Para hacer esto correctamente, lo que realmente quiere hacer es recopilar las claves públicas del host de las máquinas virtuales a medida que las crea y colocarlas en un archivo en known_hostsformato. Luego puede usar -o GlobalKnownHostsFile=..., señalando ese archivo, para asegurarse de que se está conectando al host al que cree que debería conectarse. Sin embargo, cómo hacerlo depende de cómo esté configurando las máquinas virtuales, pero leerlo del sistema de archivos virtual, si es posible, o incluso hacer que el host imprima el contenido /etc/ssh/ssh_host_rsa_key.pubdurante la configuración puede ser el truco.

Dicho esto, esto puede no valer la pena, dependiendo del tipo de entorno en el que esté trabajando y quiénes sean sus adversarios anticipados. Hacer una simple "almacenar en la primera conexión" (a través de un escaneo o simplemente durante la primera conexión "real") como se describe en varias otras respuestas anteriores puede ser considerablemente más fácil y aún proporcionar un poco de seguridad. Sin embargo, si hace esto, le sugiero que cambie el archivo de hosts conocidos del usuario ( -o UserKnownHostsFile=...) a un archivo específico para esta instalación de prueba en particular; Esto evitará contaminar su archivo de hosts conocidos personales con información de prueba y facilitará la limpieza de las claves públicas ahora inútiles cuando elimine sus máquinas virtuales.

Todo esto

• ssh-key-scan
• ssh-copy-id
• Advertencia clave ECSDA

el negocio me seguía molestando, así que opté por

Un guión para gobernarlos a todos

Esta es una variante del script en https://askubuntu.com/a/949731/129227 con la respuesta de Amadu Bah https://serverfault.com/a/858957/162693 en un bucle.

llamada de ejemplo

./sshcheck somedomain sitio1 sitio2 sitio3

El script recorrerá los sitios de nombres y modificará el archivo .ssh / config y .ssh / known_hosts y hará ssh-copy-id a petición: para la última característica, solo deje que las llamadas de prueba ssh fallen, por ejemplo, presionando enter 3 veces en La solicitud de contraseña.

secuencia de comandos 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

Aquí se explica cómo hacer una colección de hosts

definir una colección 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

Luego defina dos tareas para agregar las claves a los hosts conocidos:

- 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}}"

Lo mejor sería verificar la huella digital de cada nuevo servidor / host. Esta es la única forma de autenticar el servidor. Sin ella, su conexión SSH puede estar sujeta a un ataque de hombre en el medio .

Si está realmente seguro de que desea ignorar la comprobación de la huella digital, entonces la segunda mejor opción, menos segura, es usar StrictHostKeyChecking=accept-new , que se introdujo en OpenSSH versión 7.6 (2017-10-03) :

El primer "aceptar nuevo" aceptará automáticamente claves hasta ahora invisibles, pero rechazará las conexiones para las claves de host modificadas o no válidas.

No utilice el valor anterior StrictHostKeyChecking=noque nunca verifica la autenticidad del servidor. (Aunque el significado de esta =noconfiguración se cambiará algunas versiones más adelante ).