¿SSH admite claves *verdaderas* precompartidas?

Question

Es de conocimiento común que sshdejecutarlo en una máquina disponible públicamente es un delicioso vector de ataque y, por lo tanto, debe protegerse tanto como sea posible. Aparte de los consejos obvios como "configurar PermitRootLoginen no" y "cambiar a autenticación de clave pública", encontré los siguientes métodos para restringir el acceso a mi máquina para los niños que usan scripts armados con nmap:

• Cambie el puerto a otro que no sea 22. Realmente no ayuda lo mencionado anteriormente nmap.
• Deje el puerto 22 abierto, pero simplemente descarte todo lo que llegue allí y en su lugar acepte conexiones SSH desde otro puerto usandoesta muleta. Mejor que el método anterior, pero todavía no es más que un obstáculo.
• Configure el golpe de puerto. Engorroso yaúnno es perfectamente seguro, porque el tráfico que "golpea" puede ser interceptado.

Si tuviera que diseñar un sistema para acceso remoto a mi máquina, se vería así:

1. Genera un secreto aleatorio.
2. Cópielo manualmente en ambas máquinas que deben estar conectadas (esto incluso se puede hacer usando una unidad flash para una máxima retención anal).
3. Elprimer paquete(es decir, el inicio del protocolo de enlace SSH) que la máquina del Cliente envía al Servidor esyacifrado con este secreto.
4. Si el servidor recibe un paquete que no está correctamente cifrado con este secreto, simplemente cierra silenciosamente la conexión TCP.

El resultado es que esfísicamente imposiblepara que un atacante descubra siquiera que se está ejecutando un servicio SSH en el servidor. En mi headcanonestees exactamente lo que significa "clave precompartida".

En cambio, cuando intento buscar "ssh con clave previamente compartida", no obtengo más que enlaces a artículos sobre cómo migrar de PasswordAuthenticationa PubkeyAuthentication.

Answer 1

No, no es así. A nivel de protocolo, cada conexión SSHv2 estándar siempre comienza con 1) el "banner" de la versión del protocolo en ASCII simple, 2) un paquete sin cifrar que enumera todos los cifrados y métodos de intercambio de claves admitidos.

Comenzando con el paso 3podríaimplementar un método personalizado de intercambio de claves que involucre un PSK (idealmenteademásal habitual intercambio dinámico de claves DH), pero esto requeriría un demonio sshd personalizado, así como clientes personalizados. Actualmente no existe tal característica en OpenSSH, ni PuTTY, ni Bitvise WinSSHD, ni ninguna otra implementación SSHv2 con la que haya jugado hasta ahora.

La alternativa más sencilla sería utilizar un sistema VPN, ya que estos suelen admitir PSK (pero más comúnmente como claves HMAC para proteger el intercambio de claves inicial, no como claves AES para cifrar el canal de datos real, ya que eso perdería el "secreto directo"). " característica). Una vez que tenga un servicio VPN en ejecución, simplemente puede desactivar por completo las conexiones SSH directas: nadie puede descubrir un sshd que literalmente ya no está escuchando.

Por ejemplo, entre los más populares, tanto WireGuard como OpenVPN admiten el uso de una clave MAC previamente compartida para autenticar todos los intentos de conexión. Como ambos usan UDP para la negociación inicial, simplemente no responden.en absolutoa paquetes no verificables, lo que hace que el servicio sea imposible de descubrir. (Aunque creo que WireGuard ya lo hace incluso sin el modo PSK...) Tenga en cuenta que OpenVPN llama a esta característica modo "tls-auth"; no la confunda con su modo "clave estática".

También sería posible usar IPsec AH aquí: si todo lo que necesita es una clave de autenticación completamente estática, sería posible configurar una SA manualmente en ambos extremos sin necesidad de ningún protocolo de enlace IKE dinámico, solo con un ip xfrmcomando. Pero puede resultar molesto.

Como otra alternativa más, algunos sistemas operativos admitennivel TCPAutenticación de clave precompartida mediante TCP-MD5 (RFC1321) o TCP-AO (RFC5925). Sería fácil piratear el software SSH, ya que solo necesita un único conector, aunque eso nuevamente entra en el territorio de los clientes personalizados. Además, el soporte a nivel del sistema operativo es deficiente: aunque TCP-MD5 todavía es compatible porque la gente quiere usarlo con BGP, el soporte para TCP-AO puede ser prácticamente inexistente.