Errore SSH: authorization negata, riprova

Ho una configurazione del server Ubuntu usando l’istanza di Amazon ec2. Ho bisogno di colbind il mio desktop (che è anche una macchina Ubuntu) al server Ubuntu usando SSH.

Ho installato open-ssh nel server di Ubuntu. Ho bisogno di tutti i sistemi della mia rete per connettere il server ubuntu usando SSH (non c’è bisogno di connettermi tramite le chiavi PEM o PUB).

Quindi ha 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 

Attraverso 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 utilizzando 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 [email protected]_IP 

Mi ha chiesto di inserire la password. Dopo l’immissione della password, viene visualizzato:

 Permission denied, please try again. 

In alcune ricerche ho capito che, per questo devo 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 [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: 

Per la password, ho inserito lo stesso valore che uso normalmente per l’utente ‘ubuntu’.

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

Hai bloccato l’account.

Dalla pagina di manuale 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 linea d’ shadow :

 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 ciò per te dato che questa non è una normale installazione di Ubuntu a quanto pare.


Se quanto sopra ti fa sentire a disagio, puoi creare un utente separato:

 sudo adduser username 

e rispondi alle domande. Dovresti essere in grado di accedere bene. Inoltre rendilo in grado di diventare root (usa sudo ) aggiungendolo al gruppo sudo :

 sudo adduser username sudo 

Nel caso in cui sia necessario passare all’utente ubuntu sulla riga di comando, sarà necessario utilizzare i privilegi elevati, poiché non è ansible fornire credenziali per lo stesso motivo del motivo per cui non è ansible accedere utilizzando SSH. Ora, accedi usando SSH come username ed esegui questo per diventare ubuntu :

 sudo su -l ubuntu 

Per motivi di sicurezza non consiglierei di usare root per accedere direttamente.

Ho lo stesso problema e mi ci vogliono molte ore.

Tuttavia, noto che si tratta di una password errata a causa della diffrenza tra il layout della tastiera del client snd del server:

In Server, ho pensato di impostare la password: [email protected] E, noto che @ è " nel layout della tastiera del server.

Quindi la password corretta è: WEwd"ds


Pertanto, è necessario controllare:

Layout della tastiera del server [vs] Layout della tastiera della workstation

Questa non è la risposta esatta per questa domanda. Ma nel mio caso, c’erano linee ridondanti. (c’erano due volte la stessa riga)

 PermitRootLogin yes 

e anche

 AllowUsers otheruser 

È necessario aggiungere l’utente “root” a questa riga o commentare questa riga.

E riavviare il service sshd restart ssh service sshd restart

Ho trovato dove è risolto il problema.

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, resettare e assegnare una nuova password agli utenti appena creati.

Una volta dopo la reimpostazione della password utente e apportando le seguenti modifiche in sshd_config, ora sono in grado di connettere tutti i miei sistemi (dalla mia rete) al server remoto.

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

Grazie.

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

 AllowUsers senthil 

Questa linea consentirà al tuo server di connettersi al nome dell’utente: senthil. Un altro utente verrà negato. Dopo di che vai al tuo terminale sul tuo tipo di questo comando:

 ssh [email protected] 

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

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

Controlla l’accesso sshd Elenco utenti consentiti (file di configurazione)

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

non dovrebbe essere impostato, dovrebbe essere commentato # come mostrato nell’esempio sotto.

 # 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 

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, ho cambiato a Windows 10 aggiornato automaticamente. Non ha funzionato a lungo su Ubuntu sul mio desktop.

Non sono sicuro di quale sia stato 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 nella lista negata. Quindi abilitato … quindi accedi correttamente. Un grande urlo!