Cuando me conecto a un servidor SSH, sé que estoy enviando mi publicación para que sea comparada con el archivo authorized_keys.
La pregunta es ¿cuánto de la clave pública se envía a través del cable? ¿Incluye usuario y nombre de host del propietario de la clave?
¿Cómo puedo registrar estos datos?
Ok, me empujaron a escribir una respuesta para aclarar las cosas. No es que el otro esté completamente equivocado, pero no muestra la imagen completa de lo que está sucediendo en el protocolo SSH.
La autenticación para el servidor ssh funciona en dos pasos. La primera es la validación si su clave pública está en el archivo authorized_keys , la segunda comprueba si la firma proporcionada por la parte privada apropiada es válida. En el registro de depuración del servidor, puede ver:
sshd[9951]: debug1: test whether pkalg/pkblob are acceptable
sshd[9950]: debug1: matching key found: file /home/user/authorized_keys, line 1
sshd[9950]: Found matching RSA key: 8b:3c:20:c5:03:c4:c0:03:74:83:0a:8f:2d:d8:48:a2
sshd[9951]: Postponed publickey for vagrant from 10.0.2.2 port 54361 ssh2
refiriéndose al primer paso ( test whether pkalg/pkblob are acceptable ). Y luego una
sshd[9950]: debug1: matching key found: file /home/user/authorized_keys, line 1
sshd[9950]: Found matching RSA key: 8b:3c:20:c5:03:c4:c0:03:74:83:0a:8f:2d:d8:48:a2
sshd[9950]: Accepted publickey for user from 10.0.2.2 port 54361 ssh2
sshd[9950]: debug3: mm_answer_keyverify: key 0x7f54ce6ac570 signature verified
está comprobando la firma real realizada por la parte privada de la clave.
Parafraseando ligeramente mi respuesta de otra pregunta en sec.SE
Pero tenga en cuenta, que el primer paso no es obligatorio. Si especifica solo clave privada , o si fuerza el uso de una clave específica, se omite el primer paso y, en este caso, la pregunta anterior es correcta.
Todas las comunicaciones anteriores (autenticación) ya están cifradas. Va en el cable, pero no es posible interceptarlo en el medio. El servidor tiene que verlo, si ofrece esta clave.
Si le preocupa su clave pública, tenga en cuenta que, por ejemplo, Gitbub está exponiendo las claves públicas en la url https://github.com/<username>.keys . No es un gran problema como dice un nombre (público). En base a esto, hay un servicio , que lo identifica incluso fuera de github, pero aún debe realice el primer paso (conéctese a un servidor que no sea de confianza, lo que suele ser una mala idea).
Cuando te conectas al servidor SSH, no estás enviando tu clave pública para comparar. Más bien, lo que está sucediendo es el intercambio de datos del cliente / servidor cifrado con la clave pública y luego validar que el cliente tiene acceso a la clave privada correspondiente.
En SSHv1, el servidor cifra un mensaje con la clave pública del cliente y el cliente devuelve una suma de comprobación del mensaje.
En SSHv2, el cliente cifra un mensaje con la clave privada del cliente y envía una firma del mensaje. Luego, el servidor vuelve a crear el mensaje y busca en authorized_keys para validar la firma.
En esencia, lo que sucede es que el servidor realiza pruebas para ver si puede descifrar y luego responder a la información cifrada con la clave pública.
Nada de esto se envía "por cable" sin cifrar, ya que una conexión SSH cifrada se inicia antes del intercambio de estas frases.
Para ver más detalles, puede usar WireShark, Snort, Suricata u otro detector de paquetes para inspeccionar el tráfico sin procesar.