Putty: Ottenere il server ha rifiutato la nostra chiave Errore


86

Ho creato una coppia di chiavi utilizzando puttygen.exe(il client è Windows 8). Sul server (Ubuntu 12.04.3 LTS), ho inserito la mia chiave pubblica ~/.ssh/authorized_keys. La chiave pubblica è questa:

ssh-rsa AAAAB3NzaC1yc2EAAAABJQAAAQEAopfM6RHOgnuc4Aftn3t4k5UIAT3StCAbn/vg/IMbphbXadshC+79sIlRq3P4zGzMjFTP4hKnzu6ehLV5lmj/qorq3SKT+bPO5Qrac3VbIlrGvuBFDDjP82I2Hwg3HzlsFTstqk++KToapaTYZ7jENEYyPl2wnzITJnt//+4U1o6juoXTKgdNE02hHnRZyHOV/bnkZyJJCEwJv5U0eXSThQnhmXtUxGT8U0HQNFiXfqIIVllhWiCnyrhhIaKz/CIJNAd2VmzyJzQtJtTQX8aWSNVrZju6Sv2/RncTNvsACdNgjjh/FH8PQXaep00jlJ3MOdsC8vz6VSPFbh6iKy1oLQ== rsa-key-20131231

Quindi è corretto (una riga, nessun commento, inizia con ssh-rsa, ecc.)

.ssh il livello di autorizzazione di dir è 700, il permesso di file authorized_keys è 600. Sia la directory che il file di proprietà dell'utente effettivo a cui provo ad accedere.

Quando provo a connettermi, ricevo 'server refused our key'e il server chiede la password. È tutto. Non viene registrato nulla /var/log/auth.logquando si tenta di accedere con la chiave.

Ho cercato ovunque e tutti gli articoli ei suggerimenti menzionano l'impostazione di chmod 600 e 700 per il file / directory e la formattazione corretta della chiave. Ho fatto tutto questo ottenendo ancora l'errore "rifiutato la nostra chiave" e sono a corto di idee.


2
Hai detto a Putty di usare la stessa chiave? stai effettuando il login con lo stesso utente? è un'installazione SSH predefinita o hai modificato sshd_config?
Noam Rathaus

Puttygen genera 3 chiavi: privata, pubblica e la sua versione della chiave privata con estensione .ppk. Ovviamente sto usando .ppk con putty.exe e la chiave pubblica incollata in .ssh / authorized_keys sul server. È l'installazione / configurazione SSH predefinita, non ho modificato sshd_config.
PawelRoman

A proposito, ho dovuto creare la directory .ssh e auhtorized_keys, perché è una nuova installazione di Ubuntu e non c'era. Forse questo ha qualcosa a che fare con il problema?
PawelRoman

3
Assicurati che sshd_config sia configurato per utilizzare le chiavi pubbliche, potrebbe non essere
Noam Rathaus

2
Vedi qualcosa in /var/log/auth.log? aumentare LogLevel dei log di SSH a DEBUGe vedere se riesci a vedere eventuali problemi registrati, se ancora non mostra che stai accedendo stai cercando nel file di log sbagliato
Noam Rathaus

Risposte:


61

OK, c'era un piccolo errore di battitura nella mia chiave. Apparentemente quando si incolla nel file, la prima lettera è stata tagliata e iniziava con sh-rsa invece di ssh-rsa.

nrathathaus - la tua risposta è stata molto utile, grazie mille, questa risposta ti è stata attribuita :) Ho fatto come hai detto e l'ho impostato in sshd_conf:

LogLevel DEBUG3

Guardando i log mi sono reso conto che sshd legge correttamente la chiave ma la rifiuta a causa dell'identificatore errato.


Quali registri hai controllato e dove sono? Qual è l'identificatore di cui parli?
user1046647

3
@ user1046647 LogLevelè definito in /etc/ssh/sshd_config. Il registro predefinito è /var/log/auth.logse non diversamente definito in sshd_config.
Axel Kemper

Deve esserci qualcosa con il generatore di chiavi perché ho avuto lo stesso identico problema!
Kevin

3
Se apri authorized_key in vim e provi immediatamente a incollare la prima 's' da 'ssh_rsa "viene trattato come un comando vim dopodiché vim passerà alla modalità di inserimento e il testo rimanente viene incollato. Se entri in modalità di inserimento prima incollare (ad esempio utilizzando i) la "s" iniziale non verrà tagliata.
Pawel

1
! sudo service ssh restartaffinché le modifiche abbiano effetto. Altrimenti non c'era niente nel mio file di log di autenticazione.
hogan

30

L'aggiunta di alcuni pensieri come altre risposte ha aiutato, ma non erano esattamente adatte.

Prima di tutto, come menzionato nella risposta accettata, modifica

/etc/ssh/sshd_config

e imposta il livello di registro:

LogLevel DEBUG3

Quindi prova ad autenticarti e, quando fallisce, cerca il file di registro:

/var/log/secure

Avrà gli errori che stai cercando.


/var/log/esiste, ma securenon esiste. Come faccio a scoprire in quale registro si sta scrivendo?
aliteralmind

11
L'impostazione predefinita è /var/log/auth.log, almeno nel mio Ubuntu 14.04.1.
Axel Kemper

SÌ! grazie! scopre che il mio file chiave pub aveva un \ n invisibile alla fine
alextsil

1
Linux / Ubuntu è così frustrante. Ho trascorso 20 minuti buoni cercando di capire perché non c'era alcun securefile prima di leggere i commenti di @axel qui.
JYelton

17

Nel mio caso ho dovuto modificare anche i permessi di / home / user da 0755 a 0700.


1
questa era la causa e la soluzione per me
pstanton

4
e per me la cartella 700 e authorized_keys 600 hanno risolto il problema
David Soussan

1
Per me lo stesso, chmod 700 sulla cartella .ssh e chmod 600 su authorized_keys hanno risolto il problema
Iwo Kucharski

La cartella .ssh 700 e le chiavi autorizzate 600 hanno risolto il problema.
Deep-B

13

Nel mio caso, è un problema di autorizzazione.

Ho cambiato il livello di log in DEBUG3e /var/log/securevedo questa riga:

Authentication refused: bad ownership or modes for directory

Ho cercato su Google e ho trovato questo post:

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

Fondamentalmente, mi dice di:

  • sbarazzarsi dei wpermessi di gruppo della directory home dell'utente
  • modifica autorizzazione a 700della .sshdir
  • modificare l'autorizzazione a 600del authorized_keysfile.

E funziona.

Un'altra cosa è che anche se ho abilitato il login di root, non riesco roota lavorare. Meglio usare un altro utente.


Questa risposta è stata sottovalutata. Le autorizzazioni trascurate della directory home potrebbero costarti un'intera giornata per la risoluzione dei problemi.
chingNotCHing

Grazie per aver votato per me. Condivido solo quello che ho.
WesternGun

6

Eseguendo Windows 8.1 mi sono imbattuto nel server refused our keyproblema.

Seguendo la guida: https://winscp.net/eng/docs/guide_windows_openssh_server È stato facile stabilire una connessione utilizzando il login di Windows usernamee password. Tuttavia, l'autenticazione con usernamein combinazione con a private key, la risposta è stata server refused our key.

Farlo funzionare con una chiave pubblica dipendeva dalle autorizzazioni sul file: C:\ProgramData\ssh\administrators_authorized_keys

Questa è una pagina utile: https://github.com/PowerShell/Win32-OpenSSH/wiki/Troubleshooting-Steps

Arresta i due servizi OpenSSH, quindi apri un command promptcon admin permissions. Quindi esegui: C:\OpenSSH-Win32>c:\OpenSSH-Win32\sshd.exe -ddd

Nota: specificare il percorso completo dell'exe altrimenti si sshdlamenta. Questo crea un listener di connessione monouso. Il -dddlivello 3 è dettagliato.

Dopo aver effettuato una connessione, la scansione dei registri ha rivelato:

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

Ho dovuto creare il file: C:\ProgramData\ssh\administrators_authorized_keys E copiare il public keytesto in esso, ad esempio: ssh-rsa AAAA................MmpfXUCj rsa-key-20190505 E poi salvare il file. Ho salvato il file come UTF-8con l'estensione BOM. Non testato ANSI.

Quindi, eseguendo nuovamente la riga di comando una tantum, nei log è stato mostrato:

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-11è il nome dato al System.

Per risolvere il problema Bad permissions, fai clic con il pulsante destro del mouse sul administrators_authorized_keysfile, vai a Security Tab, fai clic sul Advancedpulsante e rimuovi le autorizzazioni ereditate. Quindi elimina tutto Group or user names:tranne il nome utente di accesso di Windows, ad esempio: YourMachineName\username Le autorizzazioni per quello usernamedovrebbero essere Read Allow, Write Denytutto il resto è deselezionato. Anche il proprietario del file dovrebbe essereYourMachineName\username

Questo ha risolto il problema.

Altri link utili:

Scarica OpenSSH-Win32.zip da: https://github.com/PowerShell/Win32-OpenSSH/releases

Esempio C # di come utilizzare WinSCPnet.dll per stabilire una connessione al server OpenSSH: https://winscp.net/eng/docs/library#csharp

Di seguito è riportato lo snippet di codice per effettuare una connessione utilizzando 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");
    }
}

Sostituisci SshHostKeyFingerprinte SshPrivateKeyPathcon i tuoi valori.

Modifica: aggiunto screenshot dei permessi del file administrators_authorized_keys: inserisci qui la descrizione dell'immagine

Quando OpenSSH SSH Serverè in esecuzione come servizio, solo allora Systemdovrebbe avere il permesso. Tuttavia, se si esegue sshd.exedal prompt dei comandi, l'utente corrente dovrebbe essere l'unico elencato (lettura consentita, negazione scrittura).


3
Hai fatto molte cose qui che hanno aiutato. Prima esecuzione di sshd con flag di debug sulla riga di comando. I registri del sistema di servizio di Windows mostravano molto poco ed era totalmente inutile eseguire il debug. Secondo, il fatto principale che come amministratore esiste un bug che guarda solo nel file administrators_authorized_keys e non nella cartella Users .ssh prevista per authorized_keys (il punto di dolore di tutti che eseguono sshd su Windows). Infine la cartella "ssh" in ProgramData! Mi chiedevo dove stessero mettendo i certificati del server, ecc. Quindi solo le tue informazioni qui mi hanno aiutato dopo aver grattato la testa per un giorno o giù di lì. Grazie!
Master James

questa risposta è stata l'unica che ha funzionato per me su un nuovo livello gratuito di Windows 2019 dell'istanza di ec2.
yolob 21

3

Aggiungo questa risposta per aiutare chiunque, come me, abbia passato ore a setacciare Internet senza successo.

LA TUA CARTELLA CASA POTREBBE ESSERE CRITTOGRAFATA.

O per quella materia qualsiasi cartella in cui è annidato il file "authorized_keys". Amico, questo mi avrebbe fatto risparmiare un sacco di tempo. Per controllare, vai ad esibirti

ls -A

nella directory di cui si desidera determinare lo stato di crittografia. Se la cartella contiene una cartella denominata ".encryptfs", la risposta è sì, quella cartella è crittografata. Ciò impedirà la tua capacità di accedere al file "authorized_keys" contenente la chiave ssh pubblica necessaria per la verifica.

Per risolvere questo problema, posizionare il file "authorized_key" in una struttura di directory che non contiene crittografia.


3

La soluzione semplice che ho trovato è stata spostare il authorized_keysfile dalla directory nascosta .ssh e metterlo nella directory ssh di sistema:

/etc/ssh/keys/authorized_keys

Non appena l'ho fatto, ha funzionato senza problemi.


3

avendo lo stesso problema in Windows Server 2008 r2 e ho esplorato molto da risolvere, alla fine l'ho fatto seguendo:

apri C: \ Program Files (x86) \ OpenSSH \ etc \ sshd_config con textpad o qualsiasi altro editor di testo

rimuovi il commento dalle righe seguenti, dopo averlo rimosso dovrebbero apparire come segue:

RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile  .ssh/authorized_keys

salvalo e prova ad accedere con la chiave privata ora. divertiti.


ssh a volte viene installato con la riga authorizedkeysfile commentata in modo che non sappia dove cercare il file delle chiavi autorizzate :-(
kenyee

Quali sono le autorizzazioni necessarie per il file authorized_keys? E deve essere nella directory dell'utente o nella directory di OpenSSH?
GarfieldKlon

Dovrebbe essere nella directory OpenSSH o dove hai installato OpenSSH. dovresti riuscire a trovarlo
Ravi Anand

Assicurati di configurarlo utilizzando l'account amministratore.
Ravi Anand

2

Grazie a nrathaus e alle /var/log/auth.logindagini a livello di debug arriva quanto segue.

Un altro motivo è che la tua directory home potrebbe avere permessi diversi da 755.


La tua home directory dovrebbe essere 700, che è l'impostazione predefinita su CentOS.
karatedog

2

Ho riscontrato questo problema oggi e il mio problema era che durante la copia della chiave pubblica dal file, vengono inclusi anche i caratteri di nuova riga. Puoi usare ": set list" in vim per vedere tutte le nuove righe nascoste e assicurarti di eliminare tutte le nuove righe tranne l'ultima. Inoltre, all'inizio della mia chiave mancava "ssh-rsa". Assicurati di avere anche quello.


1
Simile qui: durante la copia da PuttyGen, avevo nuove righe dopo "ssh-rsa" e dopo la chiave. Dopo averli rimossi, ha funzionato.
Lucian P.

1

Per coloro che ricevono questo errore da Windows Server, ho ricevuto lo stesso errore ed era un problema di account utente. Con molte organizzazioni, i criteri di gruppo per gli amministratori potrebbero non consentire la configurazione del server SSH e delle connessioni. Con quel tipo di configurazione, questa operazione deve essere eseguita dall'account amministratore locale. Potrebbe valere la pena esaminare se hai confermato che non ci sono errori di battitura nella chiave pubblica.


1

Nel mio caso, ho dovuto disabilitare SELinux su Centos6.6 per farlo funzionare :)

Modificare / etc / selinux / config e impostare quanto segue, quindi riavviare l'host.

selinux=disabled

BTW ... ho dimenticato di dire che ho dovuto impostare LogLevel = DEBUG3 per identificare il problema.


1
Piuttosto che disabilitare SELinux, puoi cambiare il contesto di sicurezza nella cartella .ssh. chcon -R -t ssh_home_t .ssh
palehorse

1

Ho avuto lo stesso errore su solaris ma ho trovato in /var/adm/splunk-auth.log quanto segue:

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

In / etc / shadow l'account è stato bloccato:

weblogic:*LK*UP:16447::::::3

Rimossa la parte "* LK *":

weblogic:UP:16447::::::3

e potrei usare ssh con authorized_keys come al solito.


1

Nel mio caso è stato causato da ( /etc/ssh/sshd_config):

PermitRootLogin no

Cambiato in yes, riavviato il servizio e ricevuto normalmente.


1

Ho risolto questo problema, puttygen è un software di terze parti, la chiave ssh generata da esso non è stata utilizzata direttamente, quindi è necessario apportare alcune modifiche. Ad esempio, assomiglia a questo

---- BEGIN SSH2 PUBLIC KEY ----
Comment: "rsa-key-20170502"
AAAAB3NzaC1yc2EAAAABJQAAAQEAr4Ffd3LD1pa7KVSBDU+lq0M7vNvLp6TewkP7
*******C4eq1cdJACBPyjqUCoz00r+LqkGA6sIFGooeVuUXTOxbYULuNQ==
---- END SSH2 PUBLIC KEY ---- 

Ometto alcuni degli alfabeti nel mezzo, sostituiti da *, in caso contrario, StackOverflow mi ha detto che il formato del codice è sbagliato, non lasciarmi pubblicare。

questa è la mia chiave ssh generata da puttygen, devi cambiarla

ssh-rsa AAAAB3NzaC1yc2EAAAABJQAAAQEAr4Ffd3LD1pa7KVSBDU+lq0M7vNvLp6TewkP7wfvKGWWR7wxA8GEXJsM01FQw5hYWbNF0CDI7nCMXDUEDOzO1xKtNoaidlLA0qGl67bHaF5t+0mE+dZBGqK7jG9L8/KU/b66/tuZnqFqBjLkT+lS8MDo1okJOScuLSilk9oT5ZiqxsD24sdEcUE62S8Qwu7roVEAWU3hHNpnMK+1szlPBCVpbjcQTdiv1MjsOHJXY2PWx6DAIBii+/N+IdGzoFdhq+Yo/RGWdr1Zw/LSwqKDq1SmrpToW9uWVdAxeC4eq1cdJACBPyjqUCoz00r+LqkGA6sIFGooeVuUXTOxbYULuNQ== yourname@hostname

Nel mio caso, ho cancellato alcuni commenti, come

---- BEGIN SSH2 PUBLIC KEY ----
Comment: "rsa-key-20170502"
---- END SSH2 PUBLIC KEY ----

e aggiungi ssh-rsaall'inizio, aggiungi yourname@hostnamealla fine. nota : non eliminare ==nell'ultimo e devi cambiare "tuonome" e "hostname" per te, nel mio caso, è uaskh@mycomputer, tuo nome è che vuoi accedere al tuo vps. quando tutte queste cose hanno fatto, puoi caricare -chiave per la casa di uaskh ~/.ssh/authorized_keysa cat public-key >> ~/.ssh/authorized_keysquel punto sudo chmod 700 ~/.ssh sudo chmod 600 ~/.ssh/authorized_keysdevi modificare / etc / ssh / sshd_config, il RSAAuthentication yes PubkeyAuthentication yes AuthorizedKeysFile .ssh/authorized_keysmio sistema operativo è CentOS 7, questa è la prima volta che rispondo a una domanda, proverò a fare i miei sforzi, grazie!


1
@ Ronak Bhatt, Grazie per il mio impegno, ho cercato di rendere i codici più chiari, per tutto questo codice ho usato ctrl + K, ma StackOverflow mi ha detto "il tuo appello di risposta contiene codici, per favore usa il formato corretto" e non so perché è diverso tra scritto e inviato, non posso inviare la mia risposta, il che mi porta a dover aggiungere codici in 'codice' riga per riga. Imparerò il formato markdown, pensa.
nucleare

Nella versione corrente PuttyGen mostrerà la chiave pubblica nel formato corretto per il copia e incolla. Quindi non è più necessario convertire manualmente la chiave putty pub nel formato corretto.
Erik Kalkoken

1

Oh mio Dio ho passato giorni a cercare di risolvere questo problema. Quindi ecco cosa ha funzionato per me. Sono tornato alla cartella principale in questo modo: cd / root / mkdir .ssh cd .ssh chmod 700 .ssh nano -w authorized_keys service ssh restart Quindi ho usato root per accedere tramite Putty e ha funzionato. quindi prova a fare lo stesso con l'utente che vuoi usare nello stucco.


1

Nel mio caso era un utente sbagliato: attribuzione di gruppo. Ho risolto l'impostazione dell'utente e del gruppo corretti:

sudo chown [user]:[group] -R /home/[user]

0

Sto usando un file PUTTYgen con psftp e ho riscontrato questo problema sul mio Windows Server quando ci è stato richiesto di creare nuove chiavi per un client. Il file private_key_name .ppk e il file open_ssh.txt devono trovarsi nella stessa directory affinché la connessione funzioni.


0

Nel mio caso la casa su nfs era 777, doveva essere 750. Questo ha risolto il problema.


0

Ho questo problema in cui sshd legge solo da authorized_keys2.

Copiare o rinominare il file ha risolto il problema per me.

cd  ~/.ssh
sudo cat authorized_keys >> authorized_keys2

PS Sto usando Putty da Windows e ho usato PuTTyKeygen per la generazione di coppie di chiavi.


0

Stavo affrontando un problema simile durante il tentativo di accesso tramite Mobaxterm. La chiave privata è stata generata tramite puttygen. Rigenerare la chiave ha aiutato nel mio caso.


0

Quando si utilizza Cpanel è possibile verificare se la chiave è autorizzata in

Accesso SSH >> Chiavi pubbliche >> Gestisci >> Autorizza o rimuovi autorizzazione.


0

se ricevi questo errore in /var/log/secure

errore: key_read: key_from_blob AA
AAB3NzaC1yc2EAAAABJQAAAQEAoo3PFwX04NFG + rKz93l7em1BsUBzjHPMsswD

significa che la tua chiave ha spazio, se hai generato la chiave tramite puttgen quando visualizzi il .ppkfile, sarà simile a questo:

AAAAB3NzaC1yc2EAAAABJQAAAQEAoo3PFwX04NFG+rKz93l7em1BsUBzjHPMsswD
al74MLaJyhQD0pE23NS1izahbo1sJGnSJu2VJ//zxidSsba6xa6OvmeiKTwCz0E5
GMefdGVdpdbTlv99qjBl1+Nw1tDnHIC0+v9XmeZERQfCds9Kp1UivfReoYImntBC
gLtNyqRYrSu8csJCt7E1oY8QK6WP1vfYgAQ2taGyS9+g7FHyyf5VY2vH3oWzzbqz
xjsSLAv3zEQSm1LzSw9Pvc8iwasFyUMBOPj31CKQYTXyX8KpJTr0Zb7oqMauBE5L
VwxZhlcJHbj0FsMbF/+GRjvgexymCi3bHmwGQ6FEADNd0RkhdQ==

e quando provi a incollarlo otterrai un errore nella lettura della chiave, quindi prova a modificare la chiave e crea una riga e prova

questo dovrebbe assomigliare a qualcosa

ssh-rsa AAAAB3NzaC1yc2EAAAABJQAAAQEAoo3PFwX04NFG+rKz93l7em1BsUBzjHPMsswDal74MLaJyhQD0pE23NS1izahbo1sJGnSJu2VJ//zxidSsba6xa6OvmeiKTwCz0E5GMefdGVdpdbTlv99qjBl1+Nw1tDnHIC0+v9XmeZERQfCds9Kp1UivfReoYImntBCgLtNyqRYrSu8csJCt7E1oY8QK6WP1vfYgAQ2taGyS9+g7FHyyf5VY2vH3oWzzbqzxjsSLAv3zEQSm1LzSw9Pvc8iwasFyUMBOPj31CKQYTXyX8KpJTr0Zb7oqMauBE5LVwxZhlcJHbj0FsMbF/+GRjvgexymCi3bHmwGQ6FEADNd0RkhdQ== username@domainname


0

Quello che funziona per me è che:

  • Arrestato l'istanza ec2
  • staccare il volume
  • collegare il volume con la vecchia istanza utilizzando la stessa chiave ed è stato in grado di eseguire SSH
  • montare il volume in una cartella temporanea
  • controllato il file nella directory mount_point / home / ec2-user / .ssh / authorized_keys
    • Idealmente, questo file deve contenere le nostre informazioni chiave, ma per me questo file era vuoto
  • ha copiato il vecchio file authorized_keys dell'istanza nel volume appena montato
  • smontare il dispositivo
  • ricollegarsi all'istanza ec2 originale
  • avviarlo e lasciarlo passare i controlli sanitari

Questa volta funziona per me. Ma non so perché all'inizio non dispone delle informazioni sul file chiave quando è stata avviata l'istanza. Controlla anche questo link https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Tro troubleshootingInstancesConnecting.html # Tro troubleshootingInstancesConnectingMindTerm


0

Nel mio caso il problema era così, durante la generazione delle chiavi ssh ho intenzionalmente cambiato le directory di default delle chiavi. Quindi, invece di utilizzare la posizione ~ / .ssh / authorized_keys che ho scelto di usare ~/home/user/folder1/.ssh/authorized_keys, perché queste modifiche funzionassero avrei dovuto apportare le stesse modifiche della nuova posizione su questo file /etc/ssh/sshd_config. Ma fino a quando non me ne sono reso conto avevo già provato diverse soluzioni suggerite da altre persone qui, inclusa l'impostazione dell'autorizzazione della cartella home su 700e della directory .ssh su 600.


0

Passaggi per riparare il root mount (che ho seguito quando ho cambiato l'autorizzazione con la cartella ec2-user e il file della chiave di autorizzazione) Questo processo sarà simile a scollegare e collegare una pen-drive

Di seguito sono riportati alcuni altri scenari che potresti incontrare:

  1. Stai utilizzando una chiave privata SSH ma la chiave pubblica corrispondente non è nel file authorized_keys.
  2. Non disponi delle autorizzazioni per il tuo file authorized_keys.
  3. Non disponi delle autorizzazioni per la cartella .ssh.
  4. Il tuo file authorized_keys o la cartella .ssh non è denominato correttamente.
  5. Il tuo file authorized_keys o la cartella .ssh è stato eliminato.

Passaggi per risolverli

  • Arresta l'istanza problematica di Ec2
  • Scollega il volume di root (/ dev / sda1)
  • Crea un'istanza ec2 o usane una in esecuzione
  • Monta il volume scollegato (/ dev / sdvf) sulla nuova istanza ec2

Ora dopo aver effettuato l'accesso al nuovo ec2, esegui i passaggi seguenti

  • Comando Lsblk - elenca tutti i mount disponibili
  • Scegli il valore di montaggio che smonti dall'istanza problematica
  • Come utente ec2 esegui "sudo mount / dev / mapper / rootvg-home / mnt" sudo mount /dev/mapper/rootvg-home /mnt
  • Quindi cambia la directory in / mnt
  • Apporta tutte le modifiche necessarie

Ora abbiamo risolto il nostro volume con il problema che abbiamo dovuto affrontare. Principalmente potrebbe essere un problema di autorizzazione dell'utente - Smonta / mnt per smontarlo - Ora vai alla console e punta al volume collegato alla nuova istanza e scollegalo - Dopo averlo scollegato, attaccalo al tuo nuovo volume come / dev / sda1

Detto questo dovresti essere in grado di accedere con successo


0

Secondo la mia esperienza, ti suggerisco di generare chiavi da putty, non di generare da lato Linux. Perché la chiave sarà il vecchio formato PEM. Comunque, solo un mio suggerimento. Ho seguito i passaggi seguenti e ho lavorato bene con me e con il mio team.

  1. Genera una coppia di chiavi con PuTTYGen.exe sul tuo locale (tipo: RSA, lunghezza: 2048 bit).

  2. Salva la chiave pubblica / privata come file " id_rsa.ppk / id_rsa.pub " sul tuo locale.

  3. Crea il file "authorized_keys" sul tuo locale, quindi inserisci la chiave pubblica in " id_rsa.pub " in " authorized_keys ". Ricorda che il contenuto deve iniziare con " ssh-rsa " e una sola riga .

inserisci qui la descrizione dell'immagine

  1. Usa WinScp (o il comando putty) per copiare " authorized_keys & id_rsa.pub " dal tuo locale alla tua home-utente linux " /home/$USER/.ssh/ ".

inserisci qui la descrizione dell'immagine

  1. Esegui questi comandi:

    chmod 700 .ssh

    chmod 600 .ssh / authorized_keys

    chown $ USER: $ USER .ssh -R

  2. Verifica le impostazioni di connessione caricando la chiave privata " id_rsa.ppk " nel profilo PuTTY.exe, quindi fai clic su Apri (inserisci la tua passphrase, se presente).

inserisci qui la descrizione dell'immagine

inserisci qui la descrizione dell'immagine


0

controlla la tua chiave, questa dovrebbe essere una chiave rsa (id_rsa.pub) oggi e non più una chiave dss (id_dsa.pub), usa puttygen 0.70 e scegli RSA sul tipo di chiave da generare, sostituisci la chiave pubblica sull'host ~ /. ssh / authorized_keys


0

Dopo aver aggiunto la chiave, accedi come ec2-userse stessi utilizzando una macchina Amazon Linux


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.