ssh - portable - putty sftp

Putty: Getting Server rechazó nuestra clave Error

Question

puttygen.exe par de claves usando puttygen.exe (el cliente es Windows 8). En el servidor (Ubuntu 12.04.3 LTS), he puesto mi clave pública en ~/.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 nivel de permiso dir .ssh es 700, el permiso del archivo authorized_keys es 600. Tanto el directorio como el archivo pertenecen al usuario real que intento iniciar sesión.

Cuando trato de conectar me aparece el ''server refused our key'' y el servidor solicita una contraseña. Eso es todo. No se registra nada en /var/log/auth.log cuando se intenta iniciar sesión con la clave.

He buscado en todas partes y todos los artículos y sugerencias mencionan configurar chmod 600 y 700 para el archivo / directorio y formatear la clave correctamente. He hecho todo esto aún obteniendo el error de ''rechazó nuestra clave'' y me he quedado sin ideas.

Answer 1

Agregar algunas ideas como otras respuestas ayudaron, pero no fueron exactamente las correctas.

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.

Answer 2

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

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

Answer 3

En mi caso, es un problema de permiso.

Cambié el nivel de registro a DEBUG3 , y en /var/log/secure veo 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:

• Deshazte del permiso de grupo w de tu directorio de inicio de usuario
• cambie el permiso a 700 del dir .ssh
• cambie el permiso a 600 del archivo authorized_keys .

Y eso funciona

Otra cosa es que incluso si habilité el inicio de sesión raíz, no puedo hacer que root funcione. Mejor usar otro usuario.

Answer 4

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

PermitRootLogin no

Cambió a yes , reinició el servicio y entró normalmente.

Answer 5

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

Answer 6

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

Answer 7

En mi caso, tuve que desactivar SELinux en Centos6.6 para que funcione :)

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

selinux=disabled

Por cierto ... olvidé mencionar que tuve que configurar el LogLevel = DEBUG3 para identificar el problema.

Answer 8

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

Answer 9

Estaba enfrentando 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.

Answer 10

Estoy agregando esta respuesta para ayudar a cualquier persona, como yo, que pasó horas buscando en Internet sin éxito.

SU CARPETA DOMÉSTICA PODRÍA SER CIFRADA.

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

ls -A

en el directorio cuyo estado de cifrado desea 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 "authorized_keys" que contiene la clave pública ssh necesaria para la verificación.

Para solucionar esto, coloque el archivo "authorized_key" en un árbol de directorio que no contenga cifrado.

Answer 11

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

Answer 12

Gracias a nrathaus y /var/log/auth.log investigación sobre el nivel de depuración viene lo siguiente.

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

Answer 13

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, parece que esto

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

Omito algunos de los alfabetos en el medio, reemplazados por *, si no, 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 esta

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-rsa al principio, agregue yourname@hostname como último. nota : no eliminar == en el último y debe cambiar "su nombre" y "nombre de host" por usted, en mi caso, es uaskh@mycomputer , su nombre es que desea iniciar sesión en su vps. cuando todo esto ha sucedido, puedes subir la clave pública a la casa de uaskh ~/.ssh/authorized_keys por cat public-key >> ~/.ssh/authorized_keys luego sudo chmod 700 ~/.ssh sudo chmod 600 ~/.ssh/authorized_keys entonces debes modifique / etc / ssh / sshd_config, RSAAuthentication yes PubkeyAuthentication yes AuthorizedKeysFile .ssh/authorized_keys mi sistema operativo es CentOS 7, esta es la primera vez que hago una pregunta, intentaré hacer todo lo posible, ¡gracias!

Answer 14

La solución simple que encontré fue mover el archivo authorized_keys lejos del directorio oculto .ssh y ponerlo en el directorio ssh del sistema:

/etc/ssh/keys/authorized_keys

Tan pronto como lo hice, funcionó sin problemas.

Answer 15

OK, había un pequeño error tipográfico en mi clave. Aparentemente al pegar para archivar, la primera letra fue cortada y comenzó con sh-rsa en lugar de ssh-rsa.

nrathathaus: tu respuesta fue muy útil, muchas gracias, esta respuesta te está acreditada :) Me gustó lo que dijiste y estableciste 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.

Answer 16

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

Answer 17

Para aquellos que reciben este error de Windows Server, recibí este mismo error y era un problema de cuenta de usuario. Con muchas organizaciones, la política de grupo para Administradores puede no permitir la configuración del servidor SSH y las conexiones. Con ese tipo de configuración, esto debe hacerse desde la cuenta de administrador local. Puede valer la pena investigar si ha confirmado que no hay errores tipográficos en la clave pública.

Answer 18

Tengo este problema donde sshd solo lee de authorized_keys2 .

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

cd  ~/.ssh
sudo cat authorized_keys >> authorized_keys2

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

Answer 19

Tuve el mismo error en los paneles solares 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 authorized_keys como de costumbre.

Answer 20

teniendo el mismo problema en windows server 2008 r2 y exploró mucho para resolver, finalmente lo hizo al seguir:

abra C: / Archivos de programa (x86) / OpenSSH / etc / sshd_config con el teclado de texto o cualquier otro editor de texto

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

RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile  .ssh/authorized_keys

guárdalo e intenta iniciar sesión con la clave privada ahora. que te diviertas.

Answer 21

¡Gracias!

Gracias por LogLevel DEBUG3 (en mi caso, CentOS 7 el registro está en /var/log/secure )

Resulta que mi modo .ssh/authorized_keys era 644 y no 600 , y sshd sentía que solo era un no-go, ¡que finalmente descubrí leyendo ese archivo de registro!