He estado usando conexiones SSH basadas en PKI por más de 10 años. De repente, después de una actualización del servidor, algunas de las conexiones dejaron de funcionar. Estoy usando las mismas claves PKI que he usado durante años (cada servidor tiene sus propias claves, tengo un pequeño conjunto de claves personales).
Trabajando - se ve así:
C:\Users\michael>ssh2 -p 2222 [email protected] date
Authentication successful.
Fri Nov 25 10:30:42 2016
No funciona parece que:
C:\Users\michael>ssh2 [email protected] date
warning: Authentication failed.
Disconnected; key exchange or algorithm negotiation failed (Algorithm negotiation failed.).
¿Qué cambió?
Respuestas:
Después de una actualización, los efectos secundarios pueden entrar en juego. Con OpenSSH, los valores predeterminados cambian con frecuencia. OpenBSD (que mantiene / desarrolla OpenSSH) tiene una política de OpenBSD para no preocuparse por la compatibilidad con versiones anteriores. Esto puede "romper" las cosas que, según leyeron, funcionan bien.
Hay una pista masiva: que no me di cuenta cuando esto me sucedió por primera vez (usando la interfaz GUI, y simplemente hice clic y 'estaba enojado' con 'actualización estúpida: la nueva versión está rota'. Resulta que la nueva versión no estaba roto, pero OpenBSD / OpenSSH comenzó a cambiar los valores predeterminados de intercambio de claves a partir de OpenSSH-6.7p1, consulte: http://www.openssh.com/txt/release-6.7 , notablemente:
Mi problema es que tengo un cliente antiguo que no tiene ninguno de los nuevos valores predeterminados, por lo que no se puede conectar.
Dos vías de solución: arreglar / parchar el servidor o - arreglar / parchar el cliente.
Solución de servidor: recupere la configuración "antigua" para que los clientes "antiguos" puedan continuar conectándose, es decir, amigable con los clientes existentes, edite el archivo sshd_config y agregue (suficiente) los cifrados antiguos.
Las líneas clave para cambiar / agregar en sshd_config son:
Solo agrega:
Solución n. ° 2: arreglar / reemplazar el cliente
Una manera fácil de ver qué cifrados admite su cliente actual (suponiendo CLI)
ssh -hy ver si eso proporciona algo como:Otro comando útil es:
ssh -VEl mío era un cliente muy antiguo para mi escritorio. Mirando arriba, puede ver que no admite ninguno de los algoritmos preferidos, 15 años después, ni siquiera uno -cbr (rotativo), solo -cbc (copia en bloque).
Si su cliente no tiene una opción para proporcionar las claves, etc. compatibles (OpenSSH debería tener la opción
-Q), simplemente inicie una conexión con usted mismo, por ejemplo,ssh -v localhosty hay líneas como esta para decirle que se sabe qué:Y lo que se encontró (y se usó):
Extra: información de depuración de una conexión fallida - más detalles
O, lo que se intentó, pero falló.
Editar: agregado 02-ene-2017
Nueva sección: ¿qué pasa con las teclas que dejan de funcionar?
En mi servidor tengo un cliente 'antiguo' y el cliente 'más reciente' instalados, y obtengo un comportamiento diferente al conectarse a un servidor. Aquí el problema no son los errores de coincidencia de cifrado, sino el uso de un par PKI arcaico , basado en DSA.
En resumen, openssh-7 (.3) ya no envía (por defecto, tal vez en absoluto) claves públicas DSA.
A continuación, comparo el resultado de dos versiones de openssh
/ usr / bin / ssh (versión anterior, lado izquierdo) y
/ opt / bin / ssh (nueva versión, lado derecho): el comando es:
A medida que escanea a través de la salida a continuación, espero que note que los pasos y los mensajes son generalmente los mismos. La diferencia clave viene después de la cadena SSH2_MSG_SERVICE_ACCEPT
Lo que quiero que note es que la versión anterior ofrece (y es aceptada por el servidor 'antiguo', el par de claves basado en DSA, mientras que el nuevo servidor nunca ofrece la clave basada en DSA.
Nota: la 'solución' para esto es agregar (al menos uno de) los pares PKI basados en rsa, ecdsa o ed25519.
fuente
ssh2si me habrían aceptado - principalmente para la facilidad de hacerscptransferencias desde la misma ventana quessh