Erro SSH: Permissão negada, por favor tente novamente

18

Eu tenho uma configuração do servidor Ubuntu usando a instância amazon ec2. Eu preciso conectar minha área de trabalho (que também é uma máquina Ubuntu) para o servidor Ubuntu usando SSH.

Instalei o open-ssh no servidor do Ubuntu. Eu preciso de todos os sistemas da minha rede para conectar o servidor Ubuntu usando o SSH (não precisa se conectar através de chaves pem ou pub).

Por isso, abri a porta SSH 22 para meu IP estático em grupos de segurança (AWS).

Meu arquivo SSHD-CONFIG é:

# Package generated configuration file
# See the sshd_config(5) manpage for details

# What ports, IPs and protocols we listen for
Port 22
# Use these options to restrict which interfaces/protocols sshd will bind to
#ListenAddress ::
#ListenAddress 0.0.0.0
Protocol 2
# HostKeys for protocol version 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
HostKey /etc/ssh/ssh_host_ecdsa_key
#Privilege Separation is turned on for security
UsePrivilegeSeparation yes

# Lifetime and size of ephemeral version 1 server key
KeyRegenerationInterval 3600
ServerKeyBits 768

# Logging
SyslogFacility AUTH
LogLevel INFO

# Authentication:
LoginGraceTime 120
PermitRootLogin yes
StrictModes yes

RSAAuthentication yes
PubkeyAuthentication yes
#AuthorizedKeysFile %h/.ssh/authorized_keys

# Don't read the user's ~/.rhosts and ~/.shosts files
IgnoreRhosts yes
# For this to work you will also need host keys in /etc/ssh_known_hosts
RhostsRSAAuthentication no
# similar for protocol version 2
HostbasedAuthentication no
# Uncomment if you don't trust ~/.ssh/known_hosts for RhostsRSAAuthentication
#IgnoreUserKnownHosts yes

# To enable empty passwords, change to yes (NOT RECOMMENDED)
PermitEmptyPasswords no

# Change to yes to enable challenge-response passwords (beware issues with
# some PAM modules and threads)
ChallengeResponseAuthentication no

# Change to no to disable tunnelled clear text passwords
#PasswordAuthentication yes

# Kerberos options
#KerberosAuthentication no
#KerberosGetAFSToken no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes

# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes

X11Forwarding yes
X11DisplayOffset 10
PrintMotd no
PrintLastLog yes
TCPKeepAlive yes
#UseLogin no

#MaxStartups 10:30:60
#Banner /etc/issue.net

# Allow client to pass locale environment variables
AcceptEnv LANG LC_*

Subsystem sftp /usr/lib/openssh/sftp-server

# Set this to 'yes' to enable PAM authentication, account processing,
# and session processing. If this is enabled, PAM authentication will
# be allowed through the ChallengeResponseAuthentication and
# PasswordAuthentication.  Depending on your PAM configuration,
# PAM authentication via ChallengeResponseAuthentication may bypass
# the setting of "PermitRootLogin without-password".
# If you just want the PAM account and session checks to run without
# PAM authentication, then enable this but set PasswordAuthentication
# and ChallengeResponseAuthentication to 'no'.
UsePAM yes

Por meio do webmin (shell de comando), criei um novo usuário chamado 'senthil' e adicionei esse novo usuário ao grupo 'sudo'.

sudo adduser -y senthil
sudo adduser senthil sudo

Eu tentei fazer o login usando este novo usuário 'senthil' em 'webmin'. Consegui fazer o login com sucesso.

Quando tentei conectar o servidor Ubuntu do meu terminal através do SSH,

ssh [email protected]_IP

Ele me pediu para digitar a senha. Após a entrada da senha, é exibido:

Permission denied, please try again.

Em algumas pesquisas, percebi que preciso monitorar o log de autenticação do meu servidor para isso. Eu recebi o seguinte erro no meu log de autenticação (/var/log/auth.log)

Jul  2 09:38:07 ip-192-xx-xx-xxx sshd[3037]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=MY_CLIENT_IP  user=senthil
Jul  2 09:38:09 ip-192-xx-xx-xxx sshd[3037]: Failed password for senthil from MY_CLIENT_IP port 39116 ssh2

Quando tentei depurar usando:

ssh -v [email protected]_IP


    OpenSSH_5.9p1 Debian-5ubuntu1, OpenSSL 1.0.1 14 Mar 2012
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to SERVER_IP [SERVER_IP] port 22.
debug1: Connection established.
debug1: identity file {MY-WORKSPACE}/.ssh/id_rsa type 1
debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048
debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048
debug1: identity file {MY-WORKSPACE}/.ssh/id_rsa-cert type -1
debug1: identity file {MY-WORKSPACE}/.ssh/id_dsa type -1
debug1: identity file {MY-WORKSPACE}/.ssh/id_dsa-cert type -1
debug1: identity file {MY-WORKSPACE}/.ssh/id_ecdsa type -1
debug1: identity file {MY-WORKSPACE}/.ssh/id_ecdsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.8p1 Debian-7ubuntu1
debug1: match: OpenSSH_5.8p1 Debian-7ubuntu1 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.9p1 Debian-5ubuntu1
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ECDSA {SERVER_HOST_KEY}
debug1: Host 'SERVER_IP' is known and matches the ECDSA host key.
debug1: Found key in {MY-WORKSPACE}/.ssh/known_hosts:1
debug1: ssh_ecdsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: password
debug1: Next authentication method: password
[email protected]_IP's password: 
debug1: Authentications that can continue: password
Permission denied, please try again.
[email protected]_IP's password: 

Para senha, eu digitei o mesmo valor que eu normalmente uso para o usuário 'ubuntu'.

Alguém por favor pode me orientar onde está o problema e sugerir alguma solução para esse problema?

    
por Senthil Kumaran 02.07.2013 / 13:14

8 respostas

2

Eu encontrei onde o problema é e fixo.

Eu criei um novo usuário (named: senthil) e o usei apenas para SSH. No Ubuntu, sinto que quando criamos um novo usuário, por padrão, a senha do usuário root será atribuída ao novo usuário. Mesmo assim, redefina e atribua uma nova senha aos usuários recém-criados.

Uma vez após a redefinição da senha do usuário e fazendo as seguintes alterações no sshd_config, agora posso conectar todos os meus sistemas (da minha rede) ao servidor remoto.

Por favor, observe: Eu desliguei todas as autenticações SSH (como RSAAuthentication, PubkeyAuthentication e KerberosAuthentication). Eu ativei somente o PasswordAuthentication.

Obrigado.

    
por Senthil Kumaran 03.07.2013 / 14:04
11

Você bloqueou a conta.

Na página de manual de usermod(8) :

-L, --lock
           Lock a user's password. This puts a '!' in front of the encrypted password,
           effectively disabling the password.

Agora olhe para sua linha shadow :

ubuntu:!$6$rWDSG...HSi1:15347:0:99999:7:::

Desbloqueie:

usermod -U ubuntu

Nota importante! Se este usuário estiver pré-instalado no sistema, ele pode estar bloqueado por um motivo (motivos de segurança), mas não posso decidir isso por você, já que essa não é uma instalação normal do Ubuntu, aparentemente.

Se o problema acima causar desconforto, você poderá criar um usuário separado:

sudo adduser username

e responda as perguntas. Você deve conseguir fazer o login bem. Também pode tornar-se root (use sudo ) adicionando-o ao grupo sudo :

sudo adduser username sudo

Caso você precise alternar para o usuário ubuntu na linha de comando, você terá que usar seus privilégios elevados, porque você não pode fornecer credenciais pelo mesmo motivo que você não pode fazer login usando SSH. Agora, faça o login usando o SSH como username e execute isso para se tornar ubuntu :

sudo su -l ubuntu

Por motivos de segurança, não aconselho usar root para fazer login diretamente.

    
por gertvdijk 02.07.2013 / 13:25
6

Eu tenho o mesmo problema e preciso de muitas horas.

No entanto, noto que é uma senha errada devido à diferença entre o layout do teclado do servidor e o cliente:

No servidor, eu pensei que eu definir senha: [email protected] E, note que @ é " no layout do teclado do servidor.

Portanto, a senha correta é: WEwd"ds

Assim, você precisa verificar:

Layout do teclado do servidor [vs] Layout do teclado da estação de trabalho

    
por Abdennour TOUMI 12.06.2014 / 16:48
4

Esta não é uma resposta exata para essa pergunta. Mas no meu caso, havia linhas redundantes. (havia mesma linha duas vezes)

PermitRootLogin yes

e também

AllowUsers otheruser

Você deve adicionar um usuário 'root' a esta linha ou comentar esta linha.

E reinicie o ssh service sshd restart

    
por Sadee 24.03.2017 / 16:25
1

Eu tenho uma solução para você No seu arquivo sshd_config você adiciona esta linha no final do arquivo:

AllowUsers senthil

Esta linha permitirá que seu servidor possa se conectar ao nome do usuário: senthil. Outro usuário será negado. Depois disso, vá para o seu terminal no seu sever digite este comando:

ssh [email protected]

Feito! Boa sorte para você Mais informações você pode vir aqui e ver. link

    
por Dang_Ho 15.09.2016 / 05:49
0

Para os desesperados, verifique seu arquivo /etc/hosts para ter certeza de que você não está enganando o seu computador para pensar que um certo nome de host tem um IP diferente do que realmente é. >. <

    
por Alexander Taylor 18.10.2014 / 08:24
0

Verifique a lista de acesso sshd para usuários permitidos (arquivo de configuração)

  1. cat /etc/ssh/sshd_config
  2. AllowUsers

não deve ser definido, deve ser comentado # como mostrado no exemplo abaixo.

# Example of overriding settings on a per-user basis
#Match User anoncvs
#       X11Forwarding no
#       AllowTcpForwarding no
#       ForceCommand cvs server
Ciphers aes128-ctr,aes192-ctr,aes256-ctr
ClientAliveInterval 432000
ClientAliveCountMax 0
#AllowUsers TestUser
    
por willer 03.06.2017 / 00:04
0

Eu tenho visto muitas respostas para essas perguntas. Eu também enfrentei o problema. Meu caso foi minha conexão ssh estavam trabalhando antes, então eu mudei para windows 10 auto atualizado. Não funcionou no Ubuntu no meu desktop por muito tempo.

Não tenho certeza qual foi o problema. Eu verifiquei o arquivo \ etc \ hosts, o arquivo sshd_config tudo parecia bem. Então eu decidi verificar minhas configurações de antivírus - bingo que é o problema!

O aplicativo putty estava na lista negada. Então, habilitado ... então faça o login com sucesso. Um grande grito!

    
por Niranjan Das 16.09.2018 / 20:15