SSH: permiso denegado (publickey, gssapi-with-mic, contraseña)

17

================================================== ==================

ACTUALIZACIÓN: Resultó que la configuración de sshd host2no permitirá el inicio de sesión con contraseña. Gracias a la gente respondió esto.

================================================== ==================

Escenario: trabajar con una empresa para mi proyecto universitario. Necesito usar PuTTy para SSH en host1primer lugar, y desde allí SSH en host2(ver más abajo). Me dieron un nombre de usuario y contraseña en host2.

No tengo acceso a host2 en absoluto, por lo que no tengo conocimiento de él sshd_config.

Esto es lo que sucedió cuando intentaba ingresar a SSH host2desde host1:

ff@host1:~$ ssh -v host2
OpenSSH_5.1p1 Debian-5, OpenSSL 0.9.8g 19 Oct 2007
debug1: Reading configuration data /home/ff/.ssh/config
debug1: Applying options for *
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to host2 [192.*.*.*] port 22.
debug1: Connection established.
debug1: identity file /home/ff/.ssh/identity type -1
debug1: identity file /home/ff/.ssh/id_rsa type -1
debug1: identity file /home/ff/.ssh/id_dsa type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_4.3
debug1: match: OpenSSH_4.3 pat OpenSSH_4*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.1p1 Debian-5
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'sd01' is known and matches the RSA host key.
debug1: Found key in /home/ff/.ssh/known_hosts:1
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
debug1: Next authentication method: gssapi-with-mic
debug1: Unspecified GSS failure.  Minor code may provide more information
No credentials cache found

debug1: Unspecified GSS failure.  Minor code may provide more information
No credentials cache found

debug1: Unspecified GSS failure.  Minor code may provide more information


debug1: Next authentication method: publickey
debug1: Trying private key: /home/ff/.ssh/identity
debug1: Trying private key: /home/ff/.ssh/id_rsa
debug1: Trying private key: /home/ff/.ssh/id_dsa
debug1: Next authentication method: password
ff@sd01's password:
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
Permission denied, please try again.
ff@sd01's password:
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
Permission denied, please try again.
ff@sd01's password:
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
debug1: No more authentication methods to try.
Permission denied (publickey,gssapi-with-mic,password).

y mi /home/ff/.ssh/config:

Host *
#   ForwardAgent no
#   ForwardX11 no
#   ForwardX11Trusted yes
#   RhostsRSAAuthentication no
#   RSAAuthentication yes
#   HostbasedAuthentication no
    BatchMode no
#   CheckHostIP yes
#   AddressFamily any
#   ConnectTimeout 0
#   StrictHostKeyChecking ask
#   IdentityFile ~/.ssh/identity
#   IdentityFile ~/.ssh/id_rsa
#   IdentityFile ~/.ssh/id_dsa
#   Port 22
#   Protocol 2,1
#   AuthorizedKeysFile .ssh/authorized_keys
#   Cipher 3des
#   Ciphers aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc
#   EscapeChar ~
#   Tunnel no
#   TunnelDevice any:any
#   PermitLocalCommand no
    SendEnv LANG LC_*
    HashKnownHosts yes
    GSSAPIAuthentication yes
    GSSAPIDelegateCredentials no

Me pregunto si hay algo que pueda hacer antes de ir a la empresa.

ssh  ssh-agent 
— pepinillo
fuente
¿Es correcto el nombre de usuario "ff" en el host 2?
— etagenklo
@etagenklo sí, eso es lo que me dieron.
— pepinillo
Debe preguntar al administrador de host2.
— jornane
Tuve el mismo problema. Creo que la causa es que tenía algo mal configurado en la carpeta $ HOME / .ssh del usuario. Después de mv $ HOME / .ssh $ HOME / .ssh.hide podría iniciar sesión con la contraseña de ssh
— JackBauer35

Respuestas:

8

El host no acepta el nombre de usuario y la contraseña que está intentando. Eso significa que se está conectando al servidor incorrecto o que el nombre de usuario o la contraseña son incorrectos. Debería pedirle al administrador que verifique los registros host2, eso debería decirle cuál de los tres es el caso.

— kasperd
fuente
2
Es como si pudieras ser más estúpido, ofc Tengo las contraseñas correctas. Y luego recuerdas diferentes diseños de teclado. Gracias por hacerme volver a visitar :)
— skyw00lker
@ skyw00lker Esa es la razón por la que personalmente uso contraseñas alfanuméricas.
— kasperd
2

En mi caso, fue causado por el cifrado del directorio de inicio. Cambié la ubicación de las claves ssh y resolvió el problema: (Copia de archivo web) http://tweaktheserver.com/ssh-cant-connect-authentifications-that-can-continue-publickeygssapi-keyexgssapi-with-micpassword/

— usuario173141
fuente
2
Agregue la esencia de la solución a su respuesta. Las respuestas de solo enlace son susceptibles a la descomposición del enlace.
— Deer Hunter
Si bien esto puede responder teóricamente la pregunta, sería preferible incluir aquí las partes esenciales de la respuesta y proporcionar el enlace para referencia.
— Mark Henderson
gracias por tus sugerencias Entiendo que un enlace de trabajo puede ser un 'error 404' en el futuro y es importante mencionar los puntos en la respuesta misma. También he editado mi respuesta.
— user173141
@DeerHunter fue profético: enlace podrido
— Riet
@Riet: edición sugerida. No todo está perdido. Mientras tanto, puede visitar la copia capturada de la página .
— Deer Hunter
1

La autenticación GSSAPI parece estar habilitada en el cliente, pero falla y recurre a la autenticación de contraseña. Si no puede iniciar sesión con el nombre de usuario y la contraseña suministrados, lo único sensato es ponerse en contacto con alguien responsable de administrar el servidor (la "empresa").

— phoops
fuente
1

Tuve el mismo problema, pero el problema para mí fue que la configuración predeterminada del sistema operativo (CentOS 7) era cifrar el directorio del usuario, de modo que el authorized_keysarchivo colocado ~/.ssh/no funcionara. La solución vino de aquí pero básicamente:

  1. en /etc/ssh/sshd_configestablecer la propiedad AuthorizedKeysFile en algo fuera del directorio del usuario ( /etc/ssh/authorized_keys)
  2. reiniciar el servicio sshd
— Anatoly Geyfman
fuente
-1

Necesitaba dar /home/ec2-userpermisos 700:

chmod -R 700 /home/ec2-user/
— duhaime
fuente
¿Por qué el voto para eliminar?
— duhaime
-1

Permítame agregar que debe asegurarse de que la clave pertenece a su usuario.

Escriba ls -lapara ver a qué usuario pertenece su clave.

Puedes cambiar la propiedad:

sudo chown ubuntu:root myKey  //If you are using ubuntu.

También asegúrese de:

  • Está utilizando la .pemclave correcta si utiliza Linux (la masilla es diferente)
  • Ha establecido los permisos de clave correctos: sudo chmod 400 mykey.pem
  • Estás utilizando el nombre de usuario correcto: ssh -i mykey user@instanceip
— JPaulino
fuente
-2

Puedes probar

ssh server -l user -o "PubkeyAuthentication=no"

O en / etc / ssh / sshd_config, agregue / modifique la propiedad

PermitRootLogin yes
— Adriano
fuente
ssh server -l user -o "PubkeyAuthentication=no" igual ssh user@server -o "PubkeyAuthentication=no"
— Adriano
-2

$ ssh Vagrant@192.168.33.11 -i .vagrant / machines / default / virtualbox / private_key

Esto funciono para mi

— karthik br
fuente
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.