¿Cómo agregar un host SSH conocido en un script bash?


13

Estoy creando un script bash para aprovisionar un nuevo servidor en el que puedo implementar una aplicación web. Una cosa que siempre tengo que hacer es usar GitHub como un host conocido ssh git@github.com. ¿Cómo puedo automatizar este proceso en un script bash y hacerlo de manera idempotente?

Respuestas:


17

La forma más sencilla de hacerlo sería hacer algo como esto.

ssh-keyscan remote_server >>~/.ssh/known_hosts

Si este cuadro es nuevo, es posible que también deba crear el ~/.sshdirectorio antes de ejecutar ssh-keyscan .

Tenga en cuenta que ssh-keyscan puede tomar un número arbitrario de nombres de host. Obtendrá todas las llaves que pueda.


1
PD: para el aprovisionamiento, debe usar algo como títere en lugar de un script bash. Para Puppet, esto podría manejarse fácilmente con el recurso sshkey . Consulte también esta pregunta para obtener un método para administrar el servidor en masa conocido_hostsfaultfault.com/a/416782/984
Zoredache

2
Eso seguramente me sonó bien, pero después de pasar unas horas cada uno en títeres y competidores, volví corriendo a los guiones y la cordura. Si esas herramientas son intuitivas, aparentemente no tengo intuición. YMMV.
Ron Burk

Usa bash. Constantemente me encuentro con problemas en diferentes versiones de cosas como títeres o ansibles. Siempre volvemos a bash ... 3 compañías que funcionan ahora de esta manera y bash siempre es confiable para nosotros.
Ligemer

4

¿Estás tratando de automatizar la aceptación de la nueva clave? Si es así, puede usar -oStrictHostKeyChecking = no.
Hacerlo es una muy mala idea, ya que ahora estás completamente abierto a los ataques de hombre en el medio.

Una mejor opción sería simplemente administrar un archivo conocido_hosts y reutilizar ese archivo cuando aprovisione nuevos servidores. Péguelo en github y escriba un script simple para descargar ese archivo antes de enviarlo a github.

La comprobación estricta de la clave del host es algo bueno.


¿Puedes dar más detalles sobre el "archivo de gestión de hosts_conocidos"? Creo que eso es lo que quiero hacer, pero cuando vi el archivo, su contenido parecía una especie de hash / key y no parecía algo que estaba destinado a ser administrado manualmente.
Andrew

2
Aprovisione un nuevo servidor, ssh manualmente en github como lo haría. Acepte la clave del host cuando se le solicite. Cerrar sesión. Copie ~ / .ssh / known_hosts de ese servidor recién aprovisionado en otro lugar (github, servidor web, no importa mientras pueda obtenerlo). La próxima vez que aprovisione un servidor, copie ese archivo antes de enviarlo a github. No necesita editar el archivo.
yoonix

Esto es mejor que mi respuesta (más seguro). Sin embargo, una mejora adicional en la respuesta de yoonix es analizar 'ssh-keyscan github.com' y almacenar la clave devuelta en ~ / .ssh / known_hosts de esa manera, no es estático en un archivo en algún lugar para que necesite actualizar.
Sirex

Eso también funcionaría, pero no lo consideraría mejor. Potencialmente, te estás preparando para un ataque de hombre en el medio si estás agarrando una nueva clave de host cada vez.
yoonix

1
Para aclarar mi último comentario (demasiado tarde para editar): agarrar una nueva clave de host cada vez que aprovisiona un host no es funcionalmente diferente de establecer StrictHostKeyChecking = no. Con cualquiera de ellos, confía ciegamente en cualquier clave que se envíe cada vez que aprovisione. Si cree que un ataque MITM es poco probable, lea estos dos artículos. Github sería un objetivo ENORME.
yoonix

1

No estoy seguro de entender la pregunta, pero creo que desea ignorar el aviso de conocido_host o evitarlo por completo, en cuyo caso:

ssh -o StrictHostKeyChecking = no

u otras sugerencias en: http://www.joedog.org/2012/07/ssh-disable-known_hosts-prompt/


Quiero una forma no interactiva de aceptar la clave de host de GitHub (ya que esto sucederá en un script bash).
Andrew

entonces esto funcionará, aunque no aceptará la clave, la ignorará por completo. La respuesta de Yoonix es mejor
Sirex
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.