SSH senza password non funzionante con Mac OS X 10.9.5 Mavericks


3

Non riesco a far funzionare gli accessi senza password sulla mia macchina Mavericks per Mac OS X 10.9.5. Posso accedere a una casella Ubuntu remota dopo aver impostato authorized_keyscorrettamente il file. Tuttavia, non posso fare il contrario.

Quindi ho provato a risolvere i problemi di configurazione del Mac capendo se posso farlo senza una password:

ssh localhost

Farlo sulla mia casella Ubuntu funziona bene, ma il Mac continua a chiedere password. Sì, ho controllato sia il authorized_keysfile che il known_hostsfile e mi sono assicurato che la id_rsa.pubchiave fosse presente in entrambi per il mio Mac. Ma non posso SSH localhostsenza una password.

Ho letto gli altri post come questo .

E anche abilitato le seguenti due impostazioni (eliminando l'hashtag davanti a loro) nel sshd_configfile:

RSAAuthentication yes
PubKeyAuthentication yes

Viene ancora chiesta la password.

Mettere copie dei file authorized_keye known_hostsnella directory etc.

Viene ancora chiesta la password.


Qual è l'output della sessione ssh quando lo fai ssh -v localhost? Questo dovrebbe dirti su cosa potrebbe soffocare.
Jake Gould

forse prova a interrompere e ad avviare il servizio sshd se non l'hai già fatto
barlop

Risposte:


4

Ho fornito una risposta su Stack Overflow che spiega il processo passo-passo necessario per impostare l'accesso senza password tramite SSH. Ecco quelle istruzioni adattate per le tue esigenze specifiche.

Innanzitutto, imposta la connessione SSH in modalità dettagliata usando il -vflag in questo modo:

ssh -v localhost

Come spiegato nella sshpagina man; accessibile tramite man ssh:

 -v      Verbose mode.  Causes ssh to print debugging messages about its
         progress.  This is helpful in debugging connection, authentica-
         tion, and configuration problems.  Multiple -v options increase
         the verbosity.  The maximum is 3.

Questo mi ha risparmiato un sacco di mal di testa in passato mostrandomi esattamente come scorre il processo di accesso e cosa lo sta ostruendo esattamente. Ad esempio, ecco l'output di me che eseguo quel comando sul mio computer Mac OS X 10.9.5 locale:

ssh -v localhost

OpenSSH_6.2p2, OSSLShim 0.9.8r 8 Dec 2011
debug1: Reading configuration data /etc/ssh_config
debug1: /etc/ssh_config line 20: Applying options for *
debug1: /etc/ssh_config line 53: Applying options for *
debug1: Connecting to localhost [::1] port 22.
debug1: Connection established.
debug1: identity file /Users/JakeGould/.ssh/id_rsa type 1
debug1: identity file /Users/JakeGould/.ssh/id_rsa-cert type -1
debug1: identity file /Users/JakeGould/.ssh/id_dsa type -1
debug1: identity file /Users/JakeGould/.ssh/id_dsa-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.2
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.2
debug1: match: OpenSSH_6.2 pat OpenSSH*
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5-etm@openssh.com none
debug1: kex: client->server aes128-ctr hmac-md5-etm@openssh.com none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Server host key: RSA 01:aa:8e:8e:b9:e1:4b:e8:bd:c5:a2:20:a3:c7:f1:18
debug1: Host 'localhost' is known and matches the RSA host key.
debug1: Found key in /Users/JakeGould/.ssh/known_hosts:43
debug1: ssh_rsa_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: publickey,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /Users/JakeGould/.ssh/id_rsa
debug1: Authentications that can continue: publickey,keyboard-interactive
debug1: Trying private key: /Users/JakeGould/.ssh/id_dsa
debug1: Next authentication method: keyboard-interactive
Password:

Come puoi vedere, viene visualizzata la richiesta della password. Ma prima controlla chiaramente la mia chiave pubblica RSA. E poiché non ne ho uno, passa semplicemente al prossimo metodo di autenticazione. Presta attenzione all'output di ssh -vquando lo esegui sul tuo set per vedere dove le cose vengono soffocate.

Assicurarsi inoltre che i file SSH sul computer di destinazione dispongano di autorizzazioni corrispondenti a quanto segue e siano di proprietà dell'account che tenta di accedere come mostrato nell'esempio seguente:

-rw------- [username] [usergroup] authorized_keys
-rw------- [username] [usergroup] id_rsa
-rw-r--r-- [username] [usergroup] id_rsa.pub
-rw-r--r-- [username] [usergroup] known_hosts

Quindi esegui questo comando chmodnel authorized_keysfile:

sudo chmod 600 ~/.ssh/authorized_keys

Ed esegui questo comando chmodsul id_rsafile:

sudo chmod 600 ~/.ssh/id_rsa

1
Il 90% delle volte sono autorizzazioni.
Paolo

1
grazie per una risposta esaustiva, ma sono ancora confuso. il mio output ssh -v è uguale al tuo (tranne che per ovvie differenze come il nome della macchina e il tasto ssh). Anche se ho una coppia di chiavi pubbliche e private rsa e le ho inserite con successo in 'authorized_keys'. Ho anche fatto questo: <br> ssh-keygen -t dsa -P '' -f ~ / .ssh / id_dsa </br> <br> cat ~ / .ssh / id_dsa.pub >> ~ / .ssh / authorized_keys '</br> ma ricevo ancora la richiesta della password. dopo eliminerò semplicemente l'account e ricomincio.
aquagremlin,

Ho cancellato tutte le mie chiavi dalla cartella .ssh e ricominciato. STESSO PROBLEMA esiste.
aquagremlin,

Ho creato un nuovo account e ora funziona tutto. L'unica cosa che ho fatto diversamente è stata quella di utilizzare una password lunga durante la creazione dell'account (> 3 lettere. Inizialmente ho usato una password breve perché si trattava solo di un account "test")
aquagremlin,

Bene, ho provato di nuovo con un altro nuovo account usando una password più breve e ho ottenuto questo debug1: autenticazioni che possono continuare: publickey, debug interattivo da tastiera1: metodo di autenticazione successivo: publickey debug1: tentativo di chiave privata: /Users/nugget3/.ssh/id_rsa debug1: offrendo la chiave pubblica DSA: /Users/nugget3/.ssh/id_dsa debug1: il server accetta la chiave: pkalg ssh-dss blen 434 debug1: leggi la chiave privata PEM eseguita: tipo DSA Connessione chiusa da 127.0.0.1 CONNESSIONE CHIUSA?
aquagremlin,

3

Ho trovato il problema. L'host remoto registra l'origine di ogni chiave RSA o DSA. Questo viene visualizzato in testo normale alla fine di ogni riga nell'elenco delle chiavi autorizzate (che di solito non è possibile visualizzare perché nanonon esegue il wrapping del testo).

Prima stavo scrivendo all'host remoto, quindi copiando la chiave e fondendola con authorized_keys. Male.

Dal computer client, la chiave deve essere copiata sull'host remoto con quel comando di copia speciale scp, oppure ssh-copy-id(OS X non ha questo a meno che non sia installato con brewo port).

Quindi è authorized_keyspossibile eseguire l'unione in . Errore umano negligente da parte mia.


Ha subito anche un errore di copia / incolla. È stato in grado di aggirarlo utilizzando catlocalmente e nanosul server. L'upgrade perché a volte riprovare il banale è il modo migliore per risolvere un problema.
tresf

0

Per me, avevo una chiave secondaria per connettermi a un host. Per connetterti usando quello, devi aggiungerlo all'identità usando:

ssh-add yourPrivateKey
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.