Putty: el servidor rechazó nuestra clave Error

Creé un par de claves usando puttygen.exe(el cliente es Windows 8). En el servidor (Ubuntu 12.04.3 LTS), puse mi clave pública ~/.ssh/authorized_keys. La clave pública es esta:

ssh-rsa AAAAB3NzaC1yc2EAAAABJQAAAQEAopfM6RHOgnuc4Aftn3t4k5UIAT3StCAbn/vg/IMbphbXadshC+79sIlRq3P4zGzMjFTP4hKnzu6ehLV5lmj/qorq3SKT+bPO5Qrac3VbIlrGvuBFDDjP82I2Hwg3HzlsFTstqk++KToapaTYZ7jENEYyPl2wnzITJnt//+4U1o6juoXTKgdNE02hHnRZyHOV/bnkZyJJCEwJv5U0eXSThQnhmXtUxGT8U0HQNFiXfqIIVllhWiCnyrhhIaKz/CIJNAd2VmzyJzQtJtTQX8aWSNVrZju6Sv2/RncTNvsACdNgjjh/FH8PQXaep00jlJ3MOdsC8vz6VSPFbh6iKy1oLQ== rsa-key-20131231

Entonces es correcto (una línea, sin comentarios, comienza con ssh-rsa, etc.)

.ssh El nivel de permiso de dir es 700, el permiso de archivo autorizado_keys es 600. Tanto el directorio como el archivo son propiedad del usuario real al que intento iniciar sesión.

Cuando intento conectarme, obtengo 'server refused our key'y el servidor solicita la contraseña. Eso es todo. No se registra nada /var/log/auth.logal intentar iniciar sesión con la clave.

He buscado en todas partes y todos los artículos y consejos mencionan configurar chmod 600 y 700 para el archivo / directorio y formatear la clave correctamente. He hecho todo esto y sigo recibiendo el error "Rechazo nuestra clave" y no tengo ideas.

Bien, hubo un pequeño error tipográfico en mi clave. Aparentemente, al pegar en el archivo, la primera letra se cortó y comenzó con sh-rsa en lugar de ssh-rsa.

nrathathaus: su respuesta fue muy útil, muchas gracias, esta respuesta se le atribuye :) Hice lo que dijo y configuré esto en sshd_conf:

LogLevel DEBUG3

Al mirar los registros, me di cuenta de que sshd lee la clave correctamente pero la rechaza debido al identificador incorrecto.

Agregar algunos pensamientos como otras respuestas ayudó, pero no encajaban exactamente.

En primer lugar, como se menciona en la respuesta aceptada, editar

/etc/ssh/sshd_config

y establecer el nivel de registro:

LogLevel DEBUG3

Luego intente autenticarse y, cuando falle, busque el archivo de registro:

/var/log/secure

Tendrá los errores que está buscando.

En mi caso, también tuve que cambiar los permisos de / home / user de 0755 a 0700.

En mi caso, es un problema de permisos.

Cambié el nivel de registro a DEBUG3, y /var/log/secureveo esta línea:

Authentication refused: bad ownership or modes for directory

Busqué en Google y encontré esta publicación:

https://www.daveperrett.com/articles/2010/09/14/ssh-authentication-refused/

chmod g-w /home/your_user
chmod 700 /home/your_user/.ssh
chmod 600 /home/your_user/.ssh/authorized_keys

Básicamente, me dice que:

• deshacerse del wpermiso de grupo de su directorio de inicio de usuario
• cambiar el permiso 700del .sshdirectorio
• cambiar el permiso 600del authorized_keysarchivo.

Y eso funciona.

Otra cosa es que incluso habilité el inicio de sesión de root, no puedo ponerme roota trabajar. Mejor use otro usuario.

Al ejecutar Windows 8.1 me encontré con el server refused our keyproblema.

Siguiendo la guía: https://winscp.net/eng/docs/guide_windows_openssh_server Fue fácil establecer una conexión usando el inicio de sesión de Windows usernamey password. Sin embargo, al autenticarse con el usernameen combinación con a private key, la respuesta fue server refused our key.

Hacer que funcione con una clave pública se redujo a los permisos en el archivo: C:\ProgramData\ssh\administrators_authorized_keys

Esta es una página útil: https://github.com/PowerShell/Win32-OpenSSH/wiki/Troubleshooting-Steps

Detenga los dos servicios OpenSSH, luego abra un command promptcon admin permissions. Entonces corre: C:\OpenSSH-Win32>c:\OpenSSH-Win32\sshd.exe -ddd

Nota: especifique la ruta completa al exe, de lo contrario se sshdqueja. Esto crea un escucha de conexión de un solo uso. El -dddes el nivel 3 detallado.

Después de realizar una conexión, el escaneo de los registros reveló:

debug1: trying public key file __PROGRAMDATA__/ssh/administrators_authorized_keys
debug3: Failed to open file:C:/ProgramData/ssh/administrators_authorized_keys error:2
debug1: Could not open authorized keys '__PROGRAMDATA__/ssh/administrators_authorized_keys':
        No such file or directory

Tuve que crear el archivo: C:\ProgramData\ssh\administrators_authorized_keys Y copiar el public keytexto en él, por ejemplo: ssh-rsa AAAA................MmpfXUCj rsa-key-20190505 Y luego guardar el archivo. Guardé el archivo como UTF-8con el BOM. No probé ANSI.

Luego, ejecutando la línea de comando de una sola vez nuevamente, en los registros se muestra:

debug1: trying public key file __PROGRAMDATA__/ssh/administrators_authorized_keys
debug3: Bad permissions. Try removing permissions for user: S-1-5-11 on file C:/ProgramData/ssh/administrators_authorized_keys.
        Authentication refused.

S-1-5-11es el nombre que se le da al System.

Para arreglar el Bad permissions, haga clic derecho en el administrators_authorized_keysarchivo, vaya al Security Tab, haga clic en el Advancedbotón y elimine los permisos heredados. Luego elimine todo Group or user names:excepto el nombre de usuario de inicio de sesión de Windows, por ejemplo: YourMachineName\username Los permisos para eso usernamedeberían ser Read Allow, Write Denytodo lo demás está desmarcado. El propietario del archivo también debe serYourMachineName\username

Esto solucionó el problema.

Otros enlaces útiles:

Descargue OpenSSH-Win32.zip desde: https://github.com/PowerShell/Win32-OpenSSH/releases

Ejemplo de C # de cómo utilizar WinSCPnet.dll para establecer una conexión con el servidor OpenSSH: https://winscp.net/eng/docs/library#csharp

Aquí está el fragmento de código para hacer una conexión usando WinSCPnet.dll:

static void WinSCPTest() {
    SessionOptions ops = new SessionOptions {
        Protocol = Protocol.Sftp, 
        PortNumber = 22,
        HostName = "192.168.1.188", 
        UserName = "user123",
        //Password = "Password1",
        SshHostKeyFingerprint = @"ssh-rsa 2048 qu0f........................ddowUUXA="
    };

    ops.SshPrivateKeyPath = @"C:\temp\rsa-key-20190505.ppk";

    using (Session session = new Session()) {
        session.Open(ops);
        MessageBox.Show("success");
    }
}

Reemplazar SshHostKeyFingerprinty SshPrivateKeyPathcon sus propios valores.

Editar: captura de pantalla agregada de los permisos de archivo administrator_authorized_keys:

Cuando OpenSSH SSH Serverse ejecuta como un servicio, solo Systemdebe tener permiso. Sin embargo, si se ejecuta sshd.exedesde el símbolo del sistema, el usuario actual debe ser el único en la lista (leer permitir, escribir denegar).

Estoy agregando esta respuesta para ayudar a cualquiera, como yo, que pasó horas navegando por Internet sin éxito.

SU CARPETA DE INICIO PODRÍA ESTAR CIFRADA.

O, para el caso, cualquier carpeta en la que esté anidado el archivo "authorized_keys". Hombre, eso me habría ahorrado mucho tiempo. Para comprobarlo, ve a realizar

ls -A

en el directorio cuyo estado de cifrado le gustaría determinar. Si la carpeta contiene una carpeta llamada ".encryptfs", la respuesta es sí, esa carpeta está encriptada. Esto impedirá su capacidad para acceder al archivo de "claves_autorizadas" que contiene la clave ssh pública necesaria para la verificación.

Para solucionar este problema, coloque el archivo "clave_autorizada" en un árbol de directorio que no contenga cifrado.

La solución simple que encontré fue alejar el authorized_keysarchivo del directorio .ssh oculto y colocarlo en el directorio ssh del sistema:

/etc/ssh/keys/authorized_keys

Tan pronto como hice esto, funcionó sin problemas.

teniendo el mismo problema en Windows Server 2008 R2 y exploré mucho para resolver, finalmente lo hice siguiendo:

abra C: \ Archivos de programa (x86) \ OpenSSH \ etc \ sshd_config con textpad o cualquier otro editor de texto

elimine el comentario de las siguientes líneas, después de eliminarlo, debería verse como sigue:

RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile  .ssh/authorized_keys

guárdelo e intente iniciar sesión con una clave privada ahora. que te diviertas.

Gracias a nrathaus y la /var/log/auth.loginvestigación a nivel de depuración viene lo siguiente.

Otra razón es que su directorio personal puede tener permisos diferentes a 755.

Encontré este problema hoy y mi problema fue que al copiar la clave pública del archivo, también se incluyen caracteres de nueva línea. Puede usar ": set list" en vim para ver todas las líneas nuevas ocultas y asegurarse de eliminar todas las líneas nuevas excepto la última. Además, mi clave faltaba "ssh-rsa" al principio. Asegúrate de tener eso también.

Para aquellos que reciben este error de Windows Server, recibí este mismo error y fue un problema de cuenta de usuario. En muchas organizaciones, es posible que la política de grupo para administradores no permita configurar el servidor SSH y las conexiones. Con ese tipo de configuración, esto debe hacerse desde la cuenta de administrador local. Valdría la pena investigarlo si ha confirmado que no hay errores tipográficos en la clave pública.

En mi caso, tuve que deshabilitar SELinux en Centos6.6 para que funcionara :)

Edite / etc / selinux / config y configure lo siguiente y luego reinicie el host.

selinux=disabled

Por cierto ... olvidé mencionar que tenía que configurar LogLevel = DEBUG3 para identificar el problema.

Tuve el mismo error en solaris pero encontré en /var/adm/splunk-auth.log lo siguiente:

sshd: [auth.debug] debug1: PAM conv function returns PAM_SUCCESS
sshd: [auth.notice] Excessive (3) login failures for weblogic: locking account.
sshd: [auth.debug] ldap pam_sm_authenticate(sshd-kbdint weblogic), flags = 1
sshd: [auth.info] Keyboard-interactive (PAM) userauth failed[9] while authenticating: Authentication failed

En / etc / shadow la cuenta estaba bloqueada:

weblogic:*LK*UP:16447::::::3

Se eliminó la parte "* LK *":

weblogic:UP:16447::::::3

y podría usar ssh con allowed_keys como de costumbre.

En mi caso fue causado por ( /etc/ssh/sshd_config):

PermitRootLogin no

Cambió a yes, reinició el servicio y entró con normalidad.

He resuelto este problema, puttygen es un software de terceros, la clave ssh que generó no se usó directamente, por lo que debe realizar algunos cambios. Por ejemplo, se ve así

---- BEGIN SSH2 PUBLIC KEY ----
Comment: "rsa-key-20170502"
AAAAB3NzaC1yc2EAAAABJQAAAQEAr4Ffd3LD1pa7KVSBDU+lq0M7vNvLp6TewkP7
*******C4eq1cdJACBPyjqUCoz00r+LqkGA6sIFGooeVuUXTOxbYULuNQ==
---- END SSH2 PUBLIC KEY ---- 

Omití algunos de los alfabetos en el medio, reemplazados por *, si no, StackOverflow me dijo que el formato del código es incorrecto, no me dejes publicar。

esta es mi clave ssh generada por puttygen, debes cambiar a esto

ssh-rsa AAAAB3NzaC1yc2EAAAABJQAAAQEAr4Ffd3LD1pa7KVSBDU+lq0M7vNvLp6TewkP7wfvKGWWR7wxA8GEXJsM01FQw5hYWbNF0CDI7nCMXDUEDOzO1xKtNoaidlLA0qGl67bHaF5t+0mE+dZBGqK7jG9L8/KU/b66/tuZnqFqBjLkT+lS8MDo1okJOScuLSilk9oT5ZiqxsD24sdEcUE62S8Qwu7roVEAWU3hHNpnMK+1szlPBCVpbjcQTdiv1MjsOHJXY2PWx6DAIBii+/N+IdGzoFdhq+Yo/RGWdr1Zw/LSwqKDq1SmrpToW9uWVdAxeC4eq1cdJACBPyjqUCoz00r+LqkGA6sIFGooeVuUXTOxbYULuNQ== yourname@hostname

En mi caso, he eliminado algunos comentarios, como

---- BEGIN SSH2 PUBLIC KEY ----
Comment: "rsa-key-20170502"
---- END SSH2 PUBLIC KEY ----

y agregue ssh-rsaal principio, agregue yourname@hostnameal final. nota : no elimine ==en el último y debe cambiar "su nombre" y "nombre de host" por usted. En mi caso, su uaskh@mycomputernombre es el que desea iniciar sesión en su vps. Cuando todas estas cosas hayan hecho, podría cargar público tecla a la casa de uaskh ~/.ssh/authorized_keyspor cat public-key >> ~/.ssh/authorized_keysentonces sudo chmod 700 ~/.ssh sudo chmod 600 ~/.ssh/authorized_keysentonces debe modificar / etc / ssh / sshd_config, RSAAuthentication yes PubkeyAuthentication yes AuthorizedKeysFile .ssh/authorized_keysmi sistema operativo es CentOS 7, esta es la primera vez que anwser pregunta, voy a tratar mis esfuerzos para hacer, gracias!

Dios mío, pasé días tratando de arreglar esto. Así que esto es lo que funcionó para mí. Volví al pliegue raíz así: cd / root / mkdir .ssh cd .ssh chmod 700 .ssh nano -w allowed_keys service ssh restart Así que usé root para iniciar sesión a través de Putty y funcionó. así que intente hacer lo mismo con el usuario que desea usar en masilla.

Estoy usando un archivo PUTTYgen con psftp y encontré este problema en mi servidor de Windows cuando se nos pidió que creáramos nuevas claves para un cliente. El private_key_name archivo .PKK y el archivo open_ssh.txt deben estar en el mismo directorio para la conexión con el trabajo.

En mi caso, la casa en nfs era 777, necesitaba 750. Eso solucionó el problema.

Tengo este problema donde sshd solo lee authorized_keys2 .

Copiar o cambiar el nombre del archivo solucionó el problema.

cd  ~/.ssh
sudo cat authorized_keys >> authorized_keys2

PD: Estoy usando Putty de Windows y usé PuTTyKeygen para la generación de pares de claves.

Me enfrentaba a un problema similar al intentar iniciar sesión a través de Mobaxterm. La clave privada se generó a través de puttygen. Regenerar la clave ayudó en mi caso.

Al usar Cpanel, puede verificar si la clave está autorizada en

Acceso SSH >> Claves públicas >> Administrar >> Autorizar o desautorizar.

si obtiene este error en /var/log/secure

error: key_read: key_from_blob AA
AAB3NzaC1yc2EAAAABJQAAAQEAoo3PFwX04NFG + rKz93l7em1BsUBzjHPMsswD

significa que su clave tiene espacio, si generó la clave a través de puttgen cuando ve el .ppkarchivo, se verá así:

AAAAB3NzaC1yc2EAAAABJQAAAQEAoo3PFwX04NFG+rKz93l7em1BsUBzjHPMsswD
al74MLaJyhQD0pE23NS1izahbo1sJGnSJu2VJ//zxidSsba6xa6OvmeiKTwCz0E5
GMefdGVdpdbTlv99qjBl1+Nw1tDnHIC0+v9XmeZERQfCds9Kp1UivfReoYImntBC
gLtNyqRYrSu8csJCt7E1oY8QK6WP1vfYgAQ2taGyS9+g7FHyyf5VY2vH3oWzzbqz
xjsSLAv3zEQSm1LzSw9Pvc8iwasFyUMBOPj31CKQYTXyX8KpJTr0Zb7oqMauBE5L
VwxZhlcJHbj0FsMbF/+GRjvgexymCi3bHmwGQ6FEADNd0RkhdQ==

y cuando intente pegarlo, obtendrá un error al leer la clave, así que intente editar la clave y convertirla en una línea e intentarlo

esto debería verse como algo

ssh-rsa AAAAB3NzaC1yc2EAAAABJQAAAQEAoo3PFwX04NFG+rKz93l7em1BsUBzjHPMsswDal74MLaJyhQD0pE23NS1izahbo1sJGnSJu2VJ//zxidSsba6xa6OvmeiKTwCz0E5GMefdGVdpdbTlv99qjBl1+Nw1tDnHIC0+v9XmeZERQfCds9Kp1UivfReoYImntBCgLtNyqRYrSu8csJCt7E1oY8QK6WP1vfYgAQ2taGyS9+g7FHyyf5VY2vH3oWzzbqzxjsSLAv3zEQSm1LzSw9Pvc8iwasFyUMBOPj31CKQYTXyX8KpJTr0Zb7oqMauBE5LVwxZhlcJHbj0FsMbF/+GRjvgexymCi3bHmwGQ6FEADNd0RkhdQ== username@domainname

Lo que me funciona es que:

• Detuvo la instancia ec2
• quitar el volumen
• adjuntar el volumen con la instancia anterior usando la misma clave y fue capaz de SSH
• montar el volumen en alguna carpeta temporal
• comprobó el archivo en el directorio punto_montaje / home / ec2-user / .ssh / allowed_keys
  • Idealmente, este archivo debe tener nuestra información clave, pero para mí este archivo estaba vacío
• copió el archivo de claves autorizadas de la instancia anterior en el volumen recién montado
• desmontar el dispositivo
• volver a adjuntar a la instancia ec2 original
• inícielo y déjelo pasar los controles de salud

Esta vez me funciona. Pero no sé por qué no tiene la información de mi archivo clave al principio cuando se lanzó la instancia. Consulte también este enlace https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/TroubleshootingInstancesConnecting.html#TroubleshootingInstancesConnectingMindTerm

En mi caso, el problema fue así, durante la generación de claves ssh cambié intencionalmente los directorios predeterminados de las claves. Entonces, en lugar de usar la ubicación ~ / .ssh / allowed_keys que elegí usar ~/home/user/folder1/.ssh/authorized_keys, para que estos cambios funcionen, se suponía que debía hacer los mismos cambios sobre la nueva ubicación en este archivo /etc/ssh/sshd_config. Pero hasta que me di cuenta de esto, ya había probado varias soluciones sugeridas por otras personas aquí, incluida la configuración del permiso de la carpeta de inicio 700y el directorio .ssh 600.

Pasos para arreglar el montaje raíz (que seguí cuando cambié el permiso con la carpeta ec2-user y el archivo de clave de autorización) Este proceso será similar a desconectar y adjuntar un pen-drive

A continuación se muestran algunos otros escenarios que puede encontrar:

1. Estás usando una clave privada SSH, pero la clave pública correspondiente no está en el archivo Authorized_keys.
2. No tienes permisos para tu archivo Authorized_keys.
3. No tienes permisos para la carpeta .ssh.
4. Su archivo autorizado_keys o carpeta .ssh no tiene el nombre correcto.
5. Se eliminó su archivo autorizado_keys o carpeta .ssh.

Pasos para solucionarlos

• Detenga la instancia Ec2 problemática
• Desconecte el volumen raíz (/ dev / sda1)
• Cree una instancia ec2 o use una en ejecución
• Monte el volumen separado (/ dev / sdvf) en la nueva instancia ec2

Ahora, después de iniciar sesión en el nuevo ec2, ejecute los siguientes pasos

• Comando lsblk: enumera todos los montajes disponibles
• Elija el valor de montaje que desmonta de la instancia problemática
• Como usuario ec2, ejecute "sudo mount / dev / mapper / rootvg-home / mnt" sudo mount /dev/mapper/rootvg-home /mnt
• Luego cambie el directorio a / mnt
• Realice todos los cambios necesarios

Ahora hemos solucionado nuestro volumen con el problema que enfrentamos. En su mayoría, podría ser un problema de permiso del usuario - Desmontar / mnt para desmontarlo - Ahora vaya a la consola y señale el volumen adjunto a la nueva instancia y desconéctelo - Después de desconectarlo, adjúntelo a su nuevo volumen como / dev / sda1

Dicho esto, debería poder iniciar sesión correctamente

Según mi experiencia, sugiero que debe generar claves desde putty, no debe generar desde el lado de Linux. Porque la clave será el antiguo formato PEM. De todos modos, solo mi sugerencia. Hice los pasos a continuación y trabajé bien conmigo y con mi equipo.

1. Genere un par de claves con PuTTYGen.exe en su local (tipo: RSA, longitud: 2048 bits).

2. Guarde la clave privada / pública como archivos " id_rsa.ppk / id_rsa.pub " en su archivo local.

3. Crear archivo "authorized_keys" en su local, a continuación, introduzca la clave pública " id_rsa.pub " a " authorized_keys ". Recuerde que el contenido debe comenzar con " ssh-rsa " y solo una línea .

4. Utilice WinScp (o el comando putty) para copiar " claves_autorizadas & id_rsa.pub " de su local a su casa de usuario de linux " /home/$USER/.ssh/ ".

5. Ejecute estos comandos:

   chmod 700 .ssh

   chmod 600 .ssh / claves_autorizadas

   chown $ USER: $ USER .ssh -R

6. Pruebe su configuración de conexión cargando la clave privada " id_rsa.ppk " en el perfil de PuTTY.exe, luego haga clic en abrir (ponga su contraseña si tiene).

verifique su clave, esta debería ser una clave rsa (id_rsa.pub) hoy y ya no una clave dss (id_dsa.pub), use puttygen 0.70 y elija RSA en el tipo de clave para generar, reemplace la clave pública en el host ~ /. ssh / claves_autorizadas

Después de agregar la clave, inicie sesión como ec2-usersi estuviera usando una máquina Amazon Linux

Otra razón podría ser UTF-8 BOM en el authorized_keysarchivo.