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

249

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.

gareth_bowles
fuente
55
Para un entorno de prueba que es autónomo y físicamente seguro, la aceptación automatizada de claves puede funcionar bien. Pero la aceptación automática de claves públicas en un entorno de producción o en una red no confiable (como Internet) omite por completo cualquier protección contra los ataques de intermediarios que SSH de otro modo permitiría. La única forma válida de asegurarse de estar seguro contra ataques MITM es verificar la clave pública del host a través de algún canal confiable fuera de banda. No hay una forma segura de automatizarlo sin configurar una infraestructura de firma de claves moderadamente complicada.
Eil

Respuestas:

142

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

ssh -o StrictHostKeyChecking=no [email protected]

Ignacio Vazquez-Abrams
fuente
62
Esto te deja abierto al hombre en el medio de los ataques, probablemente no sea una buena idea.
JasperWallace
99
@JasperWallace, si bien este suele ser un buen consejo, el caso de uso específico (desplegar máquinas virtuales de prueba y enviarles comandos) debería ser lo suficientemente seguro.
Massimo
8
Esto le da a Warning: Permanently added 'hostname,1.2.3.4' (RSA) to the list of known hosts.Para evitar la advertencia, y para evitar que la entrada se agregue a cualquier archivo conocido_hosts, hago:ssh -o StrictHostKeyChecking=no -o LogLevel=ERROR -o UserKnownHostsFile=/dev/null [email protected]
Peter V. Mørch
11
El voto negativo ya que esto no responde a la pregunta y se abre a serias vulnerabilidades de seguridad.
marcv81
12
@Mnebuerquo: Si estuviera preocupado por la seguridad, entonces no tendría nada que ver con esta pregunta. Tendría la clave de host correcta frente a usted, recopilada de la consola del sistema al que desea conectarse, y la verificaría manualmente en la primera conexión. Ciertamente no harías nada "automáticamente".
Ignacio Vazquez-Abrams
230

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.

Yardena
fuente
44
¿Por qué necesitas los 3 ssh-keyscan's? ¿No puedes seguir con el primero ya que funciona tanto para el nombre de host como para el ip?
Robert
66
¿Puede estar seguro de que la máquina que responde a la solicitud ssh-keyscan es realmente con la que desea hablar? Si no, te has abierto a un hombre en el medio ataque.
JasperWallace
2
@JasperWallace Sí, para eso necesita al menos la huella digital o incluso mejor la clave pública, en cuyo caso puede agregarla directamente a conocido_hosts, convirtiendo esta pregunta en discutible. Si solo tiene la huella digital, deberá escribir un paso adicional que verifique la clave pública descargada con su huella digital ...
1
Las llamadas a mi ssh-keyscanestaban fallando porque mi host de destino no admite el tipo de clave de la versión predeterminada 1. Agregar -t rsa,dsaal comando solucionó esto.
fase veinte
55
Esta es probablemente una mala idea. Te estás abriendo a un ataque de hombre en el medio actualizando estas claves. Para evitar entradas duplicadas, verifique el estado de devolución de en su ssh-keygen -F [address]lugar. medium.com/@wblankenship/…
retrohacker
93

Para los flojos:

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

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

Fivef
fuente
2
"ssh-keyscan -H <host> >> ~ / .ssh / known_hosts" produce una entrada más parecida a lo que ssh hace con la interacción del usuario. (El -H cambia el nombre del host remoto.)
Sarah Messer
3
Vulnerable a los ataques MITM. No estás comprobando la huella digital clave.
Mnebuerquo
8
@Mnebuerquo Usted dice qué hacer pero no cómo, lo que sería útil.
Ray
44
@jameshfisher Sí, es vulnerable a los ataques MITM, pero ¿alguna vez ha comparado la huella digital RSA, que se le mostró con la real del servidor, cuando hacía esto manualmente? ¿No? Entonces esta respuesta es la forma de hacerlo por usted. En caso afirmativo, no debe usar esta respuesta y hacerlo manualmente o implementar otras medidas de seguridad ...
cinco de
2
@Mnebuerquo Estaría realmente contento si también nos hiciera saber una mejor manera de manejar esto, cuando necesitemos clonar un repositorio utilizando scripts por lotes sin asistencia y queremos omitir este aviso. ¡Por favor, arroje algo de luz sobre una solución real si cree que esta no es la correcta!
Waqas Shah
42

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 ...

ysawej
fuente
¿Hay alguna forma de verificar si la clave está en conocido_hosts antes ssh-keyscan ? La razón es que requiere algo de tiempo y una conexión de red adicional.
utapyngo
1
La versión original del póster de este archivo tenía cat ~/.ssh/tmp_hosts > ~/.ssh/known_hosts, pero una edición posterior lo cambió a >>. Usar >>es un error. Derrota el propósito de la unicidad en la primera línea y hace que descargue nuevas entradas known_hostscada vez que se ejecuta. (Acabo de publicar una edición para volver a cambiarla.)
paulmelnikow
1
Esto está sujeto a los mismos ataques MITM que los demás.
Mnebuerquo
@utapyngo ssh-keygen -F le dará la huella digital actual. Si vuelve a estar en blanco con el código de retorno de 1, entonces no lo tiene. Si imprime algo y el código de retorno es 0, entonces ya está presente.
Rich L
1
Si se preocupa tanto por MITM, implemente registros DNSSEC y SSHFP o use algún otro medio seguro de distribuir las claves y esta solución kludge será irrelevante.
Zart
19

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

Alex
fuente
3
Asegúrese de verificar la huella digital para asegurarse de que sea la clave correcta. De lo contrario, te abres a los ataques MITM.
Mnebuerquo
3
@Mnebuerquo Fair point en el contexto general, pero ¿por qué alguien trataría de reunir claves programáticamente si ya supieran cuál es la clave correcta?
Brian Cline el
Esta no es la manera de hacerlo. MITM
jameshfisher
8

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 }}'
Zart
fuente
1
¿Está cargando un archivo válido conocido de known_hosts, o está haciendo ssh-keyscan y volcando la salida en conocido_hosts sin verificar las huellas digitales?
Mnebuerquo
1
Esto es simplemente volcar la salida de un escaneo de teclas, sí. Entonces, en efecto, es lo mismo que StrictHostKeyChecking = no, solo con la actualización silenciosa de conocido_hosts sin jugar con las opciones ssh. Esta solución tampoco funciona bien debido a que ssh-keyscan devuelve varias líneas, lo que hace que esta tarea siempre se marque como 'cambiada'
Zart
Esta no es la manera de hacerlo. MITM
jameshfisher
3
@jameshfisher Estaría muy contento si también nos hiciera saber una mejor manera de manejar esto, cuando necesitamos clonar un repositorio usando scripts por lotes sin asistencia y queremos omitir este aviso. ¡Por favor, arroje algo de luz sobre una solución real si cree que esta no es la correcta! Por favor, háganos saber "cómo" hacerlo, si cree que esta no es la forma correcta de hacerlo.
Waqas Shah
Es un método perfectamente válido para agregar valores a conocido_hosts, pero sí, es susceptible a MITM. Sin embargo, para uso interno está bien.
Cameron Lowell Palmer el
7

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([]) }}'
mazac
fuente
1
Esta no es la manera de hacerlo. MITM
jameshfisher
6

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.

VenomFangs
fuente
2
Vulnerable a los ataques MITM. No estás revisando la huella digital.
Mnebuerquo
66
Nadie verifica la huella digital.
Brendan Byrd
Esta no es la manera de hacerlo. MITM
jameshfisher
5

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.

BradChesney79
fuente
Creo que esta es la mejor solución para este problema. Sin embargo, tenga mucho cuidado al usar Nmap en algo como Amazon EC2, ¡recibí una advertencia sobre el escaneo de puertos que hace Nmap! ¡Complete su formulario antes de hacer escaneo de puertos!
Waqas Shah
...bueno sí. No sé por qué harías el escaneo de puertos desde EC2. Si ha iniciado sesión en su cuenta, puede obtener las claves de las máquinas reales. Esto es más para máquinas sobre las que no tienes control. Supongo que tendría una máquina local no sujeta a restricciones de escaneo de puertos AWS para usar. Pero, si se encuentra en esa situación límite en la que debe ejecutar nmap con AWS, supongo que esta advertencia sería útil.
BradChesney79
Usar nmap para leer la clave de host SSH de su estación de trabajo y luego confiar en ese valor no es diferente a conectarse a través de SSH con StructHostKeyChecking desactivado. Es igual de vulnerable a un ataque de hombre en el medio.
Micah R Ledbetter
... @ MicahRLedbetter, por eso sugerí que "más comparaciones de diferentes computadoras y redes generalmente aumentarán su capacidad de confiar en la conexión". Pero ese es mi punto. Si solo revisa su host de destino a partir de un conjunto de condiciones ambientales, ¿cómo podría saber si hay alguna discrepancia? ¿Tienes alguna sugerencia mejor?
BradChesney79
1
Este es el teatro de seguridad. Hacer algo complicado para crear la apariencia de una mayor seguridad. No importa cuántos métodos diferentes use para pedirle al host su clave. Como preguntarle a la misma persona varias veces si puede confiar en ella (tal vez llame, envíe un correo electrónico, envíe un mensaje de texto o envíe un correo postal). Siempre dirán que sí, pero si le preguntas a la persona equivocada, no importa.
vastlysuperiorman
5

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
Felipe Alcacibar
fuente
5

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
Amadu Bah
fuente
1
Esta no es la manera de hacerlo. MITM
jameshfisher
Me gusta más esta respuesta. Para la configuración inicial de un VPS aleatorio sin importancia para nadie más que para mí, el riesgo MITM es muy pequeño. Una objeción infinitesimal ... la primera línea debe sermkdir -p ~/.ssh/known_hosts;
Martin Bramwell
5

¿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

Jacob Evans
fuente
4

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.

Curt J. Sampson
fuente
4

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
Wolfgang Fahl
fuente
2

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}}"
Vackar Afzal
fuente
0

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

Dominik
fuente