Putty: el servidor rechazó nuestra clave Error


86

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.


2
¿Le dijiste a Putty que usara la misma clave? ¿Está iniciando sesión con el mismo usuario? ¿Es esta una instalación SSH predeterminada o modificó sshd_config?
Noam Rathaus

Puttygen genera 3 claves: privada, pública y su propia versión de clave privada con extensión .ppk. Por supuesto, estoy usando .ppk con putty.exe y pegué la clave pública en .ssh / allowed_keys en el servidor. Es la instalación / configuración predeterminada de SSH, no he modificado sshd_config.
PawelRoman

Por cierto, tuve que crear el directorio .ssh y auhtorized_keys, porque es una instalación nueva de Ubuntu y no estaba allí. ¿Quizás esto tenga algo que ver con el problema?
PawelRoman

3
Asegúrese de que sshd_config esté configurado para usar claves públicas, puede que no sea así
Noam Rathaus

2
¿Ves algo en /var/log/auth.log? aumente el LogLevel de los registros de SSH DEBUGy vea si puede ver algún problema registrado, si aún no muestra que accede, está buscando en el archivo de registro incorrecto
Noam Rathaus

Respuestas:


61

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.


7
Exactamente el mismo número :)
Trefex

¿Qué registros revisaste y dónde están? ¿Qué es el identificador, estás hablando?
user1046647

3
@ user1046647 LogLevelestá definido en /etc/ssh/sshd_config. El registro predeterminado es a /var/log/auth.logmenos que se defina lo contrario en sshd_config.
Axel Kemper

3
Si abre la clave autorizada en vim e inmediatamente intenta pegar la primera 's' del comando 'ssh_rsa ", se tratará como un comando vim, después de lo cual vim cambiará al modo de inserción y el texto restante se pegará. Si ingresa al modo de inserción antes pegar (por ejemplo, usar i) las 's' iniciales no se cortará.
Pawel

1
! sudo service ssh restartpara que los cambios surtan efecto. De lo contrario, no había nada en mi archivo de registro de autenticación.
hogan

30

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.


/var/log/existe, pero secureno existe. ¿Cómo descubro en qué registro se está escribiendo?
aliteralmind

11
El valor predeterminado es /var/log/auth.log, al menos en mi Ubuntu 14.04.1.
Axel Kemper

¡SI! ¡gracias! resulta que mi archivo de clave de pub tenía un \ n invisible al final
alextsil

1
Linux / Ubuntu es tan frustrante. Pasé unos buenos 20 minutos tratando de averiguar por qué no había ningún securearchivo antes de leer los comentarios de @axel aquí.
JYelton

17

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


1
esta fue la causa y la solución para mí
pstanton

4
y para mí, la carpeta 700 y las claves autorizadas 600 resolvieron el problema
David Soussan

1
Para mí, lo mismo, chmod 700 en la carpeta .ssh y chmod 600 en allowed_keys resolvieron el problema
Iwo Kucharski

La carpeta .ssh 700 y las claves autorizadas 600 me lo arreglaron.
Deep-B

13

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.


Esta respuesta no fue votada. Los permisos pasados ​​por alto del directorio de inicio pueden costarle un día entero para solucionar problemas.
chingNotCHing

Gracias por votar por mí. Solo comparto lo que tengo.
WesternGun

6

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: ingrese la descripción de la imagen aquí

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).


3
Has hecho muchas cosas aquí que te ayudaron. Primero ejecutando sshd con el indicador de depuración en la línea de comandos. Los registros del sistema de servicio de Windows mostraban muy poco y era totalmente inútil depurarlos. En segundo lugar, el hecho principal de que, como administrador, existe un error que solo se ve en el archivo administrator_authorized_keys y no en la carpeta .ssh de los usuarios esperados para las claves autorizadas (el motivo de preocupación de todos al ejecutar sshd en Windows). Finalmente, la carpeta 'ssh' en ProgramData! Me preguntaba dónde estaba poniendo los certificados del servidor, etc. Así que solo su información aquí me ayudó después de rascarme la cabeza durante un día o dos. ¡Gracias!
Master James

esta respuesta fue la única que funcionó para mí en un nuevo nivel gratuito de Windows 2019 de instancia ec2.
yolob 21

3

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.


3

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.


3

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.


ssh a veces se instala con la línea de archivo de claves autorizadas comentada, por lo que no sabe dónde buscar el archivo de claves autorizadas :-(
kenyee

¿Cuáles son los permisos necesarios para el archivo Authorized_keys? ¿Y tiene que estar en el directorio de usuarios o en el directorio de OpenSSH?
GarfieldKlon

Debe estar en el directorio OpenSSH o donde instaló su OpenSSH. deberías poder encontrarlo
Ravi Anand

Asegúrese de que lo está configurando con la cuenta de administrador.
Ravi Anand

2

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.


Su directorio de inicio debe ser 700, que es el predeterminado en CentOS.
karatedog

2

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.


1
Similar aquí: al copiar de PuttyGen, tenía nuevas líneas después de "ssh-rsa" y después de la clave. Después de quitarlos, funcionó.
Lucian P.

1

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.


1

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.


1
En lugar de deshabilitar SELinux, puede cambiar el contexto de seguridad en la carpeta .ssh. chcon -R -t ssh_home_t .ssh
palehorse

1

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.


1

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

PermitRootLogin no

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


1

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!


1
@Ronak Bhatt, Gracias por mi esfuerzo, traté de aclarar los códigos, para todo este código usé ctrl + K, pero StackOverflow me dijo "su apelación de respuesta contiene códigos, use el formato correcto", y no sé por qué es diferente entre escrito y enviado, no puedo enviar mi respuesta, lo que me lleva a tener que agregar códigos en 'código' línea por línea. Aprenderé el formato de rebajas, piensa.
nuclear

En la versión actual, PuttyGen mostrará la clave pública en el formato correcto para copiar y pegar. Por lo tanto, ya no es necesario convertir manualmente la clave putty pub al formato correcto.
Erik Kalkoken

1

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.


0

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.


0

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


0

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.


0

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.


0

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

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


0

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


0

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


0

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.


0

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


0

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 .

ingrese la descripción de la imagen aquí

  1. 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/ ".

ingrese la descripción de la imagen aquí

  1. Ejecute estos comandos:

    chmod 700 .ssh

    chmod 600 .ssh / claves_autorizadas

    chown $ USER: $ USER .ssh -R

  2. 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).

ingrese la descripción de la imagen aquí

ingrese la descripción de la imagen aquí


0

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


0

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


Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.