Errore SSH: autorizzazione negata, riprovare


23

Ho una configurazione del server Ubuntu che utilizza l'istanza di amazon ec2. Devo collegare il mio desktop (che è anche una macchina Ubuntu) al server Ubuntu usando SSH.

Ho installato open-ssh nel server Ubuntu. Ho bisogno di tutti i sistemi della mia rete per connettere il server Ubuntu tramite SSH (non è necessario connettersi tramite chiavi pem o pub).

Quindi ho aperto la porta SSH 22 per il mio IP statico nei gruppi di sicurezza (AWS).

Il mio file 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

Tramite webmin (Command shell), ho creato un nuovo utente chiamato "senthil" e ho aggiunto questo nuovo utente al gruppo "sudo".

sudo adduser -y senthil
sudo adduser senthil sudo

Ho provato ad accedere usando questo nuovo utente "senthil" in "webmin". Sono stato in grado di accedere con successo.

Quando ho provato a connettere il server Ubuntu dal mio terminale tramite SSH,

ssh senthil@SERVER_IP

Mi ha chiesto di inserire la password. Dopo l'immissione della password, è visualizzato:

Permission denied, please try again.

In alcune ricerche mi sono reso conto che per questo ho bisogno di monitorare il registro di autenticazione del mio server. Ho ricevuto il seguente errore nel mio registro di autenticazione (/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 ho provato a eseguire il debug utilizzando:

ssh -v senthil@SERVER_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
senthil@SERVER_IP's password: 
debug1: Authentications that can continue: password
Permission denied, please try again.
senthil@SERVER_IP's password: 

Per la password, ho inserito lo stesso valore che utilizzo normalmente per l'utente 'ubuntu'.

Qualcuno può guidarmi dove si trova il problema e suggerire qualche soluzione per questo problema?


Hai impostato la password per l' ubuntuutente? E sei sicuro di averlo digitato correttamente? Includi anche l'output di id ubunturun dal tuo server nella tua domanda. Forse hai bloccato l'account? Valuta di includere l'output di grep ^ubuntu /etc/passwd /etc/shadow(e modifica la password crittografata solo al centro della stringa).
gertvdijk,

In realtà non ho creato alcun utente separato per SSH. Ho usato l'utente che normalmente utilizzo per l'accesso al server. L'output di grep ^ ubuntu / etc / passwd / etc / shadow è: / etc / passwd: ubuntu: x: 1000: 1000: Ubuntu: / home / ubuntu: / bin / bash / etc / shadow: ubuntu:! $ 6 $ rWDSGDSGhv $ WDFDASGFDAG.Pz0ob54 / epaDSGDSGQKnKqQMFG..OieFiLUndF6KnSDGHDSGHmTMjAGHDSH214I7FHSi1: 15347: 0: 99999: 7 :::
Senthil Kumaran

Grazie ancora per la tua chiara risposta. Se ho bisogno di creare un utente separato per SSH e aggiungerlo a qualche configurazione SSH, puoi per favore darmi alcuni passaggi per questo.
Senthil Kumaran,

Risposte:


11

Hai bloccato l'account.

Dalla manpage di usermod(8):

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

Ora guarda la tua shadowlinea:

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

Sbloccalo:

usermod -U ubuntu

Nota importante! Se questo utente è preinstallato sul sistema, potrebbe essere bloccato per un motivo (motivi di sicurezza), ma non posso decidere che per te poiché questa non è una normale installazione di Ubuntu apparentemente.


Se quanto sopra ti mette a disagio, potresti creare un utente separato:

sudo adduser username

e rispondi alle domande. Dovresti essere in grado di accedere correttamente. Renderlo anche in grado di diventare root (uso sudo) aggiungendolo al sudogruppo:

sudo adduser username sudo

Nel caso in cui sia necessario passare ubuntuall'utente dalla riga di comando, è necessario utilizzare i privilegi elevati, poiché non è possibile fornire credenziali per lo stesso motivo per cui non è possibile accedere tramite SSH. Ora, accedi usando SSH come usernameed eseguilo per diventare ubuntu:

sudo su -l ubuntu

Per motivi di sicurezza, non consiglierei di utilizzare rootper accedere direttamente.


Sento che l'utente 'Ubuntu' è bloccato per motivi di sicurezza. O per evitare questa confusione, ho anche provato ad accedere utilizzando il mio account utente root. Sto ancora ricevendo lo stesso errore nel file terminal e nel file auth.log.
Senthil Kumaran,

Intendi l' rootaccount? Quell'account non ha una password ed è bloccato per impostazione predefinita. L'hai abilitato?
Alaa Ali,

@Kamal Ho aggiornato la mia risposta per includere come farlo.
gertvdijk,

Grazie Gertvdijk. Ci proverò adesso. Ho anche modificato la mia domanda e aggiornato l'output di ssh -v ubuntu @ SERVER_IP
Senthil Kumaran,

@Alaa: No .. Non l'ho abilitato. Ho appena provato ad accedere usando il root .. Attualmente sto usando l'utente: 'ubuntu' per il login (in webmin)
Senthil Kumaran,

7

Ho lo stesso problema e mi ci vogliono molte ore.

Tuttavia, noto che è una password errata a causa della differenza tra il layout della tastiera del server snd client:

In Server, ho pensato di impostare la password: WEwd@ds E, noto che @è "nel layout della tastiera del server.

Quindi la password giusta è: WEwd"ds


Pertanto, è necessario verificare:

Layout tastiera server [vs] Layout tastiera workstation


1
Era questo. Il mio sistema Raspbian ritorna alla tastiera GB ad ogni riavvio e devo andare in Preferenze-> Tastiera e mouse per ripristinarlo negli Stati Uniti. Grazie per avere questa risposta in attesa che ne avessi bisogno a gennaio 2018.
SDsolar,

Ho avuto il problema opposto: Windows ha cambiato il layout della mia tastiera per qualche motivo, e quindi stavo dando la password sbagliata attraverso il mio client SSH.
mwfearnley,

5

Questa non è la risposta esatta a questa domanda. Ma nel mio caso, c'erano linee ridondanti. (c'erano due volte la stessa linea)

PermitRootLogin yes

e anche

AllowUsers otheruser

È necessario aggiungere l'utente "root" a questa riga o commentare questa riga.

E riavvia ssh service sshd restart


ha funzionato per me
VJ Ranga,

2

Ho trovato dove si trova il problema e risolto.

Ho creato un nuovo utente (chiamato: senthil) e l'ho appena usato per SSH. In Ubuntu, sento che quando creiamo un nuovo utente, per impostazione predefinita la password dell'utente root verrà assegnata al nuovo utente. Anche in questo caso, reimpostare e assegnare una nuova password agli utenti appena creati.

Dopo aver reimpostato la password utente e apportato le seguenti modifiche in sshd_config, ora sono in grado di connettere tutti i miei sistemi (dalla mia rete) al server remoto.

Nota: ho disattivato tutte le autenticazioni SSH (come RSAAuthentication, PubkeyAuthentication e KerberosAuthentication) .. Ho attivato solo PasswordAuthentication.

Grazie.


"Ritengo che quando creiamo un nuovo utente, per impostazione predefinita la password dell'utente root verrà assegnata al nuovo utente." <- No, viene richiesto di impostare una password utilizzando adduser. Hai usato useraddinvece?
gertvdijk,

Ho usato i seguenti due comandi: "sudo adduser -y senthil" e "sudo adduser senthil sudo". Potrebbe essere come ho creato utenti usando la riga di comando webmin, non mi ha chiesto di inserire la password durante la creazione dell'utente
Senthil Kumaran,

gertvdijk, considera che sto avendo accesso solo webmin per un server. Nella riga di comando webmin, il prompt della GUI o l'installazione passo-passo non sono possibili. Quindi sento che nella riga di comando webmin, non mi ha chiesto di inserire la password. In questi casi cosa posso fare? Esiste un altro comando, oltre a "sudo adduser -y senthil", tale che in UN COMANDO creerò e assegnerò password agli utenti? scusa per la lunga domanda.
Senthil Kumaran,

Ma hai accesso alla console su un EC2, giusto? Naturalmente, l'esecuzione di questi comandi tramite Webmin è MOLTO limitata. Mi dispiace non essere stato esplicito nell'esecuzione di questo nella console piuttosto che in Webmin (questo limita davvero le tue opzioni / capacità).
gertvdijk,

Volevi dire che, hai appena cambiato la password di quell'utente e tutto ok? Ho lo stesso problema. Nel mio caso tutti gli utenti includono root ottenere quell'errore ?!
shgnInc,

2

Ho una soluzione per te Nel tuo file sshd_config aggiungi questa seguente riga alla fine del file:

AllowUsers senthil

Questa linea consentirà al tuo server di connettersi al nome dell'utente: senthil. Un altro utente verrà negato. Dopodiché vai sul tuo terminale sul tuo server digita questo comando:

ssh senthil@yourhostname

Fatto! Buona fortuna a te Ulteriori informazioni puoi venire qui e vedere. http://www.htpcbeginner.com/install-ssh-server-on-ubuntu-1204/


1

Nel mio caso, questo ha risolto il problema: nel server che esegue openssh-server ho cambiato la password utente (myserverusername) e root (root) con quella che stavo usando in precedenza:

sudo passwd myserverusername

e

sudo passwd root

Quindi riavviare il demone del server SSH:

sudo service ssh restart

È strano perché non ricordo di aver cambiato password


0

Per i disperati, ricontrolla il tuo /etc/hostsfile per assicurarti di non indurre il tuo computer a pensare che un determinato nome host abbia un IP diverso da quello reale. >. <


0

Controlla sshdl'elenco di accesso per utenti consentiti (file di configurazione)

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

non dovrebbe essere impostato, dovrebbe essere commentato #come mostrato nell'esempio di seguito.

# 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

0

Ho visto molte risposte a queste domande. Anch'io ho affrontato il problema. Il mio caso era che la mia connessione SSH funzionava prima di allora, sono passato a Windows 10 aggiornato automaticamente. Non ha funzionato a lungo su Ubuntu sul mio desktop.

Non sono sicuro di quale fosse il problema. Ho controllato il file \ etc \ hosts, il file sshd_config sembrava tutto a posto. Poi ho deciso di controllare le mie impostazioni antivirus: il bingo è questo il problema!

L'applicazione di stucco era nell'elenco negato. Quindi abilitarlo ... quindi accedere correttamente. Un grande urlo!


0

controlla #cat / etc / ssh / sshd_config se hai trovato la riga che inizia con "AllowUsers aggiungi il tuo utente in esso come: AllowUsers scom omar ahmed root

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.