Este es mi ultimo recurso. He estado tratando de resolver el problema aquí por horas.
Este es el trato: he copiado mi clave privada de la máquina n. ° 1 en la máquina n. ° 2. La máquina n. ° 1 puede conectarse a través de ssh a un servidor con mi clave pública, pero la máquina n. ° 2 proporciona el siguiente resultado, cuando intenta conectarse al servidor:
$ ssh -vvv -i /home/kevin/.ssh/kev_rsa [email protected] -p 22312
OpenSSH_5.3p1 Debian-3ubuntu6, OpenSSL 0.9.8k 25 Mar 2009
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to 192.168.1.244 [192.168.1.244] port 22312.
debug1: Connection established.
debug3: Not a RSA1 key file /home/kevin/.ssh/kev_rsa.
debug2: key_type_from_name: unknown key type '-----BEGIN'
debug3: key_read: missing keytype
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
...
Permission denied (publickey).
Obviamente hay más resultados de depuración que he omitido, y puedo proporcionarlos a pedido. Sin embargo, estoy convencido de que no le gusta mi archivo de clave privada.
También sospeché que tiene que ver con cómo lo copié de la máquina n. ° 1 a la máquina n. ° 2. Copié / pegué el texto de la clave privada en una unidad flash. Este podría ser el problema, sin embargo, cuando dupliqué este método en otro archivo de clave privada que funcionaba, e hice una diferencia en el original, al copiado / pegado, son idénticos.
He estado luchando con esto. Si pudiera obtener un poco más de información sobre por qué no le gusta mi clave, podría solucionarlo, estoy seguro. Alguien tiene alguna idea sobre esto? ¿Hay algún metadato en alguna parte que le diga a ssh que un archivo es de hecho una clave RSA?
fuente
/var/log/auth.logen el servidor?Respuestas:
En mi experiencia, los dos errores de autenticación basados en claves más comunes son
$HOME/.sshdirectorioPermisos de archivo
OpenSSH hace mucho en un intento de protegerte de ti mismo. La forma más impactante para el usuario de esto es imponer restricciones estrictas sobre quién tiene acceso a su carpeta ssh local. Realmente solo quiere que usted, y solo usted, acceda al directorio. Bueno, y cualquiera con uid = 0, pero no hay una buena forma de evitarlo. Entonces, lo que debe hacer es simplemente cambiar sus permisos:
chmod -R go-rwx ~/.sshesto eliminará los derechos de lectura, escritura y ejecución de cualquier archivo debajo del directorio .ssh de todos los usuarios, excepto el propietario, es decir, usted .Problemas de claves autorizadas
El archivo que contiene su clave pública, por lo general,
$HOME/.ssh/authorized_keysdebe ajustarse a un formulario muy específico para que SSH entienda cómo aceptar la clave privada. Cada clave debe constar de, al menos, 2 camposCada clave, junto con todas sus opciones y componentes, debe aparecer una por línea en este archivo. Como las teclas tienden a ser muy largas, a menudo se ajustarán y aparecerán como dos líneas en su terminal. Esto a veces causará estragos cuando intente copiar / pegar, ya que a veces se insertan una o más líneas nuevas donde la tecla se ajusta en su pantalla. Solucionar este problema puede ser un poco más complicado para un principiante de shell.
Intente ejecutar
wc -l ~/.ssh/authorized_keysEsto imprimirá el número de líneas en el archivo. Compare ese número con el número de claves que espera tener en el archivo. Si solo va a aceptar esta clave, también puede hacer una copia del archivo de clave pública, ya que tiene el mismo formato que su archivo de claves autorizado. Algo así como
scp -p ~/.ssh/kev_rsa.pub remotehost:~/.ssh/authorized_keys, si tiene su clave pública en el mismo sistema, puede hacer
cat ~/.ssh/kev_rsa.pub >> ~/.ssh/authorized_keysAdemás, busque en el archivo de registro en el host remoto y vea si se informa algún error allí. Los archivos probablemente serán
/var/log/secure.logo/var/log/auth.fuente
make a copy of the private key filedebe ser clave pública (como se muestra en sus ejemplos)Sin embargo, es probable que deba generar un nuevo par de claves para que la máquina 2 se conecte al servidor. A menudo, la clave pública enumerará el usuario y el nombre de la máquina de aquellos que los generaron. Esto debería ser evidente en su archivo Author_keys en el servidor.
fuente
Los mensajes de depuración que proporciona significan que se lee un archivo de clave privada con la suposición de que en realidad se trata de un archivo de clave pública / hosts autorizados. Esto puede no ser un error fatal (recibo tales mensajes incluso para conexiones que funcionan). ¿Dice algo sobre "Ofrecer" o "enviamos"?
fuente
Intente comparar los archivos de configuración ssh entre los dos servidores.
es decir. algo así como cat / etc / sshd_config
fuente