Esta puede ser una pregunta estúpida, pero tengo que hacerla de todos modos:
ya configuré una clave pública ssh para mi máquina cliente A. Copié la clave pública en el servidor remoto, todo funciona bien, puedo iniciar sesión desde la máquina A.
Ahora también quiero acceder a ese servidor desde otra máquina y, siguiendo las mejores prácticas, quería generar otra clave para la máquina cliente B, en lugar de usar la clave de la máquina A nuevamente. Por supuesto, puedo generar el par de claves, pero no puedo copiar esa nueva clave pública al servidor porque la máquina cliente B no tiene acceso al servidor, solo A lo tiene.
La única solución que veo en este momento parece ser llevar la nueva clave pública en una memoria USB a la máquina cliente A y copiarla al servidor desde allí, pero eso parece ser un poco tedioso y no muy práctico cuando hay n máquinas ubicadas. bastante lejos unos de otros.
¿Cuál es el enfoque correcto para hacer eso?
Tanto el cliente como el servidor ejecutan Linux.
Respuesta1
No estoy seguro de que exista un enfoque correcto, aún necesita acceder al servidor de alguna manera y dado que la máquina A es solo un punto de acceso por ahora, aún necesita obtenerlo físicamente al menos una vez, así como otras n máquinas. Entonces, ¿por qué no recopilar todas las claves públicas en la memoria USB y moverlas a la máquina A para distribuirlas a los directorios de configuración .ssh de inicio de los usuarios del servidor?
Sin memoria USB también hay algunas opciones.
Var. n.º 1. Habilite temporalmente el inicio de sesión con contraseña en el servidor desde la máquina A. Genere pares de claves y copie claves públicas al servidor desde las máquinas B, C, D, etc., de forma normal. Deshabilite el inicio de sesión con contraseña en el servidor.
Var. n.º 2. Si incluso el inicio de sesión con contraseña temporal se considera una falla de seguridad, cree un usuario temporal en el servidor que solo tenga acceso a su directorio de inicio y habilite el inicio de sesión con contraseña solo para este usuario. Genere pares de claves y copie claves públicas al servidor desde las máquinas B, C, D, etc. al directorio de inicio de este usuario. Pubkey no es confidencial y su posible ocultamiento se considera una situación segura; sin embargo, su suplantación de identidad no lo es, por lo que puedes considerar cifrarlo o firmarlo de alguna manera (gpg). Inicie sesión en el servidor desde la máquina A, difunda la clave pública a los usuarios del servidor, deshabilite el usuario temporal utilizado.
Var. n.º 3. Si reiniciar el servidor ssh no es una opción, puede convertir la máquina A en un servidor ssh temporal y utilizarla como estación intermedia para copiar las claves públicas ssh al servidor real.
Var. 4. Utilice otro canal de comunicación (otro servidor remoto, tal vez incluso uno público, correo electrónico, etc.). Una vez más, pubkey no es confidencial, pero asegúrese de firmarlo para protegerlo contra la suplantación de identidad.
Respuesta2
Bueno, TENDRÁS que transferir la clave pública al servidor remoto.de alguna manera.
Sin embargo, dado que la clave pública no es confidencial (de ahí el nombre), no dude en copiarla en una memoria USB, cargarla en algún lugar, ponerla en una nota, etc.
¡Solo asegúrese de que la clave que agregue en el servidor sea la que cargó desde su cliente!
Respuesta3
Normalmente muevo claves ssh copiando y pegando. pero también puedes enviarlos por correo electrónico, http, netcat, etc, son solo mensajes de texto.
Si puede obtener la clave pública de la máquina C en la máquina B, puede realizar ssh de B a A e instalar la clave para C.