Probablemente esté confundiendo un poco lo que está sucediendo entre el cliente y el servidor cuando se comunican a través de un canal encriptado ( ssh o tls no importa mucho, de todos modos el patrón involucra dos tipos de cifrados).
En esencia, hay dos tipos de construcciones criptográficas que se utilizan: cifrados simétricos y asimétricos (omitiría describir otros detalles esenciales relacionados con la integridad de un dato, etc.).
Lo que generalmente sucede es lo siguiente (ejemplo ssh con verificación de clave y el registro de contraseña inhabilitado):
Crypto asimétrico
-
El cliente tiene una clave privada (generalmente un archivo llamado id_rsa ) y el servidor tiene una clave pública correspondiente (ubicada en un archivo known_hosts ).
-
Cuando el cliente desea ssh en un host particular, establece una conexión TCP para el envío de su propio nombre de usuario. El servidor hace coincidir una clave pública correspondiente de known_hosts con este nombre de usuario en particular y envía algún tipo de desafío al cliente.
-
Este desafío solo se puede resolver con una clave privada correspondiente que el cliente debería tener en su máquina. El cliente resuelve el desafío y envía los resultados al servidor que verifica la solución y permite que el usuario inicie sesión (o rechace al cliente si la solución no es correcta, lo que significa que la clave privada es incorrecta).
Después de ese punto, si al usuario se le otorgó un acceso, el criptográfico simétrico comienza a desempeñar su papel.
Criptografía simétrica
-
El usuario fue autenticado por un servidor y la clave de sesión se genera en el lado del servidor, que luego se envía a un cliente cifrado con su clave pública (nuevamente desde un known_hosts ).
-
Esta clave de sesión es una clave secreta mucho más rápida que el cifrado asimétrico simétrico (es decir, AES). Esta clave se usa para cifrar todo el tráfico entre ambos lados, ya que se transfirió de manera segura a un cliente y ambos lados ahora tienen ese secreto que solo ellos conocen.
-
Después del final de una sesión (el usuario cierra sesión) la clave de la sesión no desempeña ningún rol y no se utiliza para ninguna otra sesión (se genera de forma aleatoria y la probabilidad de que la misma clave se genere dos veces es insignificante).
Es una descripción muy simplificada, pero al menos dejaría las cosas un poco más claras.
Lo que sucede es que el cripto asimétrico solo autentica a un usuario y ayuda a intercambiar claves secretas de forma segura. Toda la comunicación se encripta con la misma clave secreta de sesión de algunos cifrados simétricos.
A partir de su pregunta acerca de omitir el almacenamiento de un secreto en un cliente y el uso de una transferencia segura en un solo sentido:
-
ssh es un protocolo de comunicación y el patrón descrito anteriormente es parte de su 'modo de operación'. No se puede cambiar (corríjame si me equivoco)
- si solo quiere enviar algunos datos a un host remoto sin siquiera autenticar al remitente (lo cual no es recomendable) puede descubrir algo como un script de shell que cifra los datos con alguna clave pública (del lado del cliente,
gpg es un camino a seguir) y lo envía a través de un telnet a un servidor que lo descifra con su clave privada (nuevamente, gpg ).
Aunque el patrón descrito anteriormente se puede asegurar con suficiente esfuerzo ( hmac , compendios, firmas, etc.) realmente tiene poco sentido molestarse con todo esto, ya que todavía tiene que almacenar secret en algún lugar ( esta vez está en el lado del servidor, o incluso en ambos lados si se usa algo como hmac ).