Non è possibile utilizzare SSH anche con la chiave pubblica aggiunta a authorized_keys


15

Ho una gocciolina di Digital Ocean a cui sto provando a concedermi l'accesso SSH. Non sono sicuro di ciò che è stato fatto in precedenza. Ho provato ad aggiungere la mia chiave pubblica tramite l'interfaccia utente Digital Ocean. Non ha funzionato, ho continuato a ricevere permission denied (publickey).

Ho effettuato l'accesso al server tramite la console Digital Ocean e ho aggiunto manualmente la mia chiave pubblica a /root/.ssh/authorized_keys. Ho quindi provato a usare ssh ssh root@x.x.x.x. Non ha funzionato (permesso negato).

Quindi ho provato ad aggiungere un nuovo utente, ho creato la /home/me/.sshdirectory con le autorizzazioni 700sulla .sshdirectory stessa e 600sul authorized_keysfile. Poi ho provato ssh me@x.x.x.x. Neanche quello ha funzionato.

Il riavvio del demone ssh non cambia nulla.

Cosa mi sto perdendo?

Modificare:

Ecco un output ssh dettagliato.

https://gist.github.com/jaesung2061/a37cfd68308414cede8abf7f0137daa9

Modifica 2:

LogLevel DEBUG3 produzione:

inserisci qui la descrizione dell'immagine


Pubblica il registro dettagliato dalla connessione, il contenuto di sshd_config e possibili errori relativi a ssh nel registro del server.
Jakuje,

@Jakuje Ho aggiunto l'output ... Non ho notato il tuo commento prima.
Jeff,

La chiave è stata respinta. Controllare il registro del server per possibili problemi (possibilmente con LogLevel DEBUG3in sshd_config). Sospetto che si tratti di problemi di autorizzazione, ma potrebbero esserci diversi motivi per questo.
Jakuje,

Dice[date omitted] www sssh[15029]: Connection closed by x.x.x.x port 55519 [preauth]
Jeff,

Quali sono le autorizzazioni del file authorized_keys? ls -ld ~ ~/.ssh ~/.ssh/authorized_keys? Per il log dettagliato dal server modifica il file sopra menzionato, riavvia il servizio ssh, riconnettiti e pubblica il log (dovrebbe essere anche in auth.log.
Jakuje

Risposte:


19

Configurazione client

Impostare ~/.ssh/config

Configurare le voci host per sshè davvero semplice e ti farà risparmiare un sacco di problemi. Ecco un esempio:

Host digitaloceanbox
Hostname 111.111.111.111
User root
PubKeyAuthentication yes
IdentityFile /home/user/.ssh/digitalocean-rsa
ForwardX11 yes


Host github github.com
Hostname github.com
User git
PubKeyAuthentication yes
IdentityFile /home/user/.ssh/github-rsa
ForwardX11 no

In questo esempio, l'installazione si digitaloceanboxe githube github.comin modo che possiamo fare i seguenti comandi:

  1. ssh github
  2. ssh digitaloceanbox

Se vogliamo accedere come un utente diverso da quello specificato nel file di configurazione, mettiamo semplicemente user@all'inizio:

  • ssh user@digitaloceanbox

Generazione di sshchiavi

ssh-keygen -t rsa -b 4096 -C user@homemachine
Generating public/private rsa key pair.
Enter file in which to save the key (/home/user/.ssh/id_rsa):  /home/user/.ssh/digitalocean-rsa
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /home/user/.ssh/digitalocean-rsa
Your public key has been saved in /home/user/.ssh/digitalocean-rsa.pub.
The key fingerprint is:
SHA256:p9PYE/tveF2n//bLbp3ogYDtMtYEC5ziQiPxeob6fbo user@homemachine

Si noti che ho specificato il percorso completo della chiave privata che voglio generare quando richiesto ssh-keygen. Ho anche definito il commento ( -C) che mi permette di identificare facilmente le chiavi su macchine remote.

Questo creerà due file:

  1. .ssh/digitalocean-rsa
    • Chiave privata . Non condividere mai questo .
  2. .ssh/digitalocean-rsa.pub
    • Chiave pubblica. Questo è ciò che memorizzi sul server per l'autenticazione.

Quando fornisci la sshchiave, assicurati che sia la .pubversione !! Quando aggiungi al tuo ~/.ssh/config, assicurati di aggiungere la chiave privata corretta che corrisponde alla chiave pubblica che hai aggiunto al sistema.


Configurazione del server

La maggior parte delle installazioni avrà l'autenticazione con chiave pubblica abilitata. Se inizi a fare tutte le cose volenti o nolenti, potresti riscontrare alcuni problemi, tuttavia. Nel punto in cui si trova l'OP nel loro problema, consiglio all'OP di eliminare la /root/.ssh/directory per ricominciare.

Non è consigliabile utilizzare sshper accedere all'utente root sul sistema remoto. Si consiglia di sshaccedere a un altro utente, quindi eseguire l'escalation alla radice utilizzando la password ( sudo su -).

Aggiungi le chiavi all'host utilizzando ssh-copy-id

Indipendentemente dal fatto che si decida di creare un altro utente e utilizzarlo sshcome tale utente o come utente root, il seguente è il modo consigliato di posizionare le sshchiavi su un server:

  1. ssh-copy-id -i /home/user/.ssh/digitalocean-rsa.pub user@digitaloceanbox

Ciò consente sshddi creare la directory e i file necessari con le autorizzazioni necessarie. Ciò significa che non hai alcuna possibilità di incasinare le autorizzazioni o di dover ricordare i dettagli. Basta usare lo strumento per caricare le chiavi.

Disabilita autenticazione password

Detto questo, una volta effettuata la chiave e verificato di essere in grado di connettersi utilizzando le chiavi, si consiglia di disabilitare l'autenticazione password sshde riavviare il servizio:

  1. modificare /etc/ssh/sshd_config
  2. PasswordAuthentication no
  3. sudo systemctl restart sshd

E i nuovi utenti?

Se disabiliti l'autenticazione con password, come puoi digitare nuovi utenti? Un modo è quello di aggiungere i file modello alla /etc/skeldirectory. Dopo aver assegnato la chiave a un utente, procedi come segue:

  1. sudo cp -r .ssh/ /etc/skel/
  2. ls /etc/skel/.ssh
  3. Modifica tutti i file trovati in /etc/skel/.ssh/modo che siano vuoti, a meno che tu non voglia digitare automaticamente te stesso per ogni nuovo utente creato.

Quando crei nuovi utenti con sudo useradd -m newuser, quell'utente avrà il .ssh/authorized_keys, che puoi modificare e avrà le autorizzazioni appropriate.

Debug

Puoi guardare il sshdfile di registro per capire perché le connessioni falliscono o vengono rifiutate:

  1. sudo tail -f /var/log/auth.log

Durante l'esecuzione di questo comando, utilizzare un altro terminale per tentare un accesso. Molte volte i messaggi forniti sono abbastanza buoni da aiutare a individuare il problema o trovare una soluzione online.


1
Il passaggio di debug ha funzionato per me. La directory root aveva i permessi sbagliati (doveva essere 700)
naisanza il

12

Ssh è piuttosto esigente in termini di proprietà, autorizzazioni per file e directory con i tasti ssh.

~ / .ssh / dovrebbe essere di proprietà del proprietario e disporre di 700 autorizzazioni. ~ / .ssh / authorized_keys dovrebbe essere di proprietà del proprietario e avere 600 autorizzazioni.

Quindi, per root:

sudo chown root:root -R /root/.ssh/
sudo chmod 700 /root/.ssh/
sudo chmod 600 /root/.ssh/authorized_keys

Per l'utente:

sudo chown me:me -R /home/me/
sudo chmod 700 /home/me/.ssh/
sudo chmod 600 /home/me/.ssh/authorized_keys

E poi riprova.

Ovviamente dovresti anche controllare in / etc / ssh / sshd_config se root è autorizzato ad accedere o semplicemente con le chiavi ssh.

Se hai :

PasswordAuthentication no

quindi puoi impostare:

PermitRootLogin yes

E quindi riavviare sshd:

/etc/init.d/sshd restart

e riprova.

Nota che con ssh, il demone sshd può essere riavviato anche quando si utilizza una sessione ssh per questo. OpenSH è progettato per gestirlo.

Guardando i frammenti dei file di registro caricati, sembra che tu stia utilizzando MacOSX? Potresti creare una nuova chiave ssh lì?

Inoltre, in passato ho scoperto che quando ho più di una chiave ssh privata sul mio computer locale per il mio utente, ciò a volte rende impossibile accedere in remoto con ssh. Ha aiutato moltissimo a inserire voci nel computer locale nel file ~ / .ssh / config, per risolverlo. Per esempio :

Host my-vps
  HostName my-vps-ip-address-here
  IdentityFile ~/.ssh/id_rsa-my-private-key-location
  User my-username-here

Dopodiché prova dalla riga di comando sul tuo computer locale:

ssh -v my-vps

Quando si utilizzano chiavi ssh, oltre a nessuna chiave ssh per alcuni altri accessi, è possibile, oltre alle voci con chiavi ssh, definire anche un accesso ssh senza l'utilizzo della chiave ssh nel file ~ / ssh / config, ad esempio:

Host pi
  Hostname 192.168.1.111
  Port 22
  User pi
  PasswordAuthentication yes
  PreferredAuthentications password

Questo funziona bene per me. È anche possibile definire quale chiave utilizzare sulla riga di comando:

ssh -v root@10.111.111.254 -i .ssh/id_rsa

Ciò potrebbe semplificare il debug e sulla riga di comando dovrebbe sempre funzionare sul computer locale.


Oltre a questa soluzione, ho dovuto modificare anche i permessi per la mia cartella home, per far funzionare SSH:sudo chmod 700 /home/me/
Rg90

Sei un vero toccasana, @ albert-j! La IdentityFilefila mi ha fatto uscire da una carreggiata di un'ora.
martedì

4

Ricontrolla la configurazione del demone ssh (dovrebbe essere in /etc/ssh/sshd_config) e controlla:

PubkeyAuthentication yes
AuthorizedKeysFile %h/.ssh/authorized_keys

Controlla anche il file di configurazione per vedere se AllowUsers o AllowGroups è stato impostato, poiché fungono rispettivamente da liste bianche per utenti e gruppi.

Inoltre, ho notato che stai cercando di aggiungere una chiave all'utente root. Per impostazione predefinita, il login root dovrebbe essere disabilitato, ma è anche possibile modificarlo tramite il campo PermitRootLogin .


Nessuno di questi funziona: / Ricevo ancoraPermission denied (publickey)
Jeff

3

Secondo i log che hai collegato, penso che tu abbia problemi nel lato client nel non trovare il file della chiave privata .

  • Per prima cosa controlla che il file ~/.ssh/id_rsaesista sul tuo computer locale ed è quello corretto _ (se ne hai di più).

  • Controlla i .sshpermessi delle cartelle (dovrebbe essere drwx------, se non eseguito sudo chmod 700 ~/.ssh) e il suo contenuto (dovrebbe essere -rw-------, se non eseguito sudo chmod 600 ~/.ssh/*) . Applicare le stesse autorizzazioni anche per la macchina remota.

Inoltre, è possibile provare a forzare utilizzando la desiderata chiave privata , dando direttamente al sshcon il -iparametro.

  • Puoi eseguire qualcosa di simile ai seguenti:

    ssh -i /path/to/your/private-key root@X.X.X.X

    o

    ssh -i ~/.ssh/id_rsa myRemoteUser@X.X.X.X

Puoi ottenere maggiori informazioni sulla manpage di ssh (esegui man sshsul tuo terminale) .

Inoltre, tieni presente che se desideri accedere come rootutente, il tuo account di root deve essere abilitato prima del login, creando un passwd per esso con sudo passwd rooto il tuo strumento di amministrazione del server (Ubutntu ha l'account di root disabilitato per impostazione predefinita) . Puoi ottenere maggiori informazioni su Ubuntu Wiki .

Spero che sia d'aiuto.


3

Ho finito per reinstallare openssh-server che risolto il problema. Le soluzioni fornite sono tutte fantastiche, ma non hanno funzionato per me. Non ho idea di cosa stia causando il problema, ma penso che lo sviluppatore precedente potrebbe aver incasinato la configurazione e rovinato le cose piuttosto male.

Dubito che ci sarà qualcuno con un problema così specifico come il mio. Tuttavia, se si dispone di un droplet Digital Ocean, non è possibile ottenere l'accesso SSH e nessuna delle soluzioni fornite funziona, reinstallare il server SSH eseguendo questi comandi attraverso la console Digital Ocean. Attenzione, questo è un processo distruttivo e cancellerà i vecchi file di configurazione/etc/ssh/ (non la tua .sshdirectory).

apt-get purge openssh-server
apt-get autoremove
apt-get autoclean
apt-get install openssh-server

Supponendo che il tuo client ssh / le chiavi siano in ordine, dovresti essere in grado di SSH nel tuo server.


1

Questo problema è emerso per me usando l'immagine Debian su Digital Ocean. In qualche modo durante il breve processo di configurazione, probabilmente quando ho impostato la password di root, il proprietario è /rootstato modificato per l'utente debian. Ho visto quanto segue in /var/log/auth.log:

Jul 26 20:58:17 docker sshd[12576]: Authentication refused: bad ownership or modes for directory /root

Semplicemente in esecuzione chown root:root -R /root risolto il problema.

HTH


0

Ho appena avuto un problema molto simile. Questo ha funzionato per me - Aggiungi questa riga a / etc / ssh / sshd_config

AuthorizedKeysFile %h/.ssh/authorized_keys 

Quindi riavviare ssh nel solito modo.

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.