Impossibile impostare il login ssh senza digitare la password

8

Ho impostato automaticamente l'accesso ssh senza digitare la password su un server da:

cd ~/.ssh

ssh-keygen

ssh-copy-id -i ~/.ssh/id_rsa.pub tim@server1

Funziona sul server.

Più tardi ho fatto lo stesso su un altro server.

ssh-copy-id -i ~/.ssh/id_rsa.pub tim@server2

Immediatamente io ssh tim@server2, ma richiede ancora la mia password. Ho fatto qualcosa di sbagliato? Quali sono alcuni dei possibili motivi che non ho impostato correttamente sul secondo server? (nota che il secondo server esegue kerberos e il file system Andrew)

$ ssh -v tim@server2
OpenSSH_6.6.1, OpenSSL 1.0.1f 6 Jan 2014
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to server2 [...] port 22.
debug1: Connection established.
debug1: identity file /home/tim/.ssh/id_rsa type 1
debug1: identity file /home/tim/.ssh/id_rsa-cert type -1
debug1: identity file /home/tim/.ssh/id_dsa type -1
debug1: identity file /home/tim/.ssh/id_dsa-cert type -1
debug1: identity file /home/tim/.ssh/id_ecdsa type -1
debug1: identity file /home/tim/.ssh/id_ecdsa-cert type -1
debug1: identity file /home/tim/.ssh/id_ed25519 type -1
debug1: identity file /home/tim/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.6.1p1 Ubuntu-2ubuntu2
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.3
debug1: match: OpenSSH_5.3 pat OpenSSH_5* compat 0x0c000000
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: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<3072<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 xxx
debug1: Host 'server2' is known and matches the RSA host key.
debug1: Found key in /home/tim/.ssh/known_hosts:70
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,gssapi-keyex,gssapi-with-mic,password,keyboard-interactive
debug1: Next authentication method: gssapi-keyex
debug1: No valid Key exchange context
debug1: Next authentication method: gssapi-with-mic
debug1: Unspecified GSS failure.  Minor code may provide more information
No Kerberos credentials available

debug1: Unspecified GSS failure.  Minor code may provide more information
No Kerberos credentials available

debug1: Unspecified GSS failure.  Minor code may provide more information


debug1: Unspecified GSS failure.  Minor code may provide more information
No Kerberos credentials available

debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/tim/.ssh/id_rsa
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password,keyboard-interactive
debug1: Trying private key: /home/tim/.ssh/id_dsa
debug1: Trying private key: /home/tim/.ssh/id_ecdsa
debug1: Trying private key: /home/tim/.ssh/id_ed25519
debug1: Next authentication method: keyboard-interactive
Password:

Ho provato il metodo di Anthon di usare le chiavi Diffie-Hellman, ma mi chiede ancora la mia password.

$ cd ~/.ssh
$ ssh-keygen -t dsa
$ ssh-copy-id -i ~/.ssh/id_dsa.pub tim@server2
$ ssh -v tim@server2
OpenSSH_6.6.1, OpenSSL 1.0.1f 6 Jan 2014
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to server2 [...] port 22.
debug1: Connection established.
debug1: identity file /home/tim/.ssh/id_rsa type 1
debug1: identity file /home/tim/.ssh/id_rsa-cert type -1
debug1: identity file /home/tim/.ssh/id_dsa type 2
debug1: identity file /home/tim/.ssh/id_dsa-cert type -1
debug1: identity file /home/tim/.ssh/id_ecdsa type -1
debug1: identity file /home/tim/.ssh/id_ecdsa-cert type -1
debug1: identity file /home/tim/.ssh/id_ed25519 type -1
debug1: identity file /home/tim/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.6.1p1 Ubuntu-2ubuntu2
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.3
debug1: match: OpenSSH_5.3 pat OpenSSH_5* compat 0x0c000000
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: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<3072<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 ...
debug1: Host 'server2' is known and matches the RSA host key.
debug1: Found key in /home/tim/.ssh/known_hosts:70
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,gssapi-keyex,gssapi-with-mic,password,keyboard-interactive
debug1: Next authentication method: gssapi-keyex
debug1: No valid Key exchange context
debug1: Next authentication method: gssapi-with-mic
debug1: Unspecified GSS failure.  Minor code may provide more information
No Kerberos credentials available

debug1: Unspecified GSS failure.  Minor code may provide more information
No Kerberos credentials available

debug1: Unspecified GSS failure.  Minor code may provide more information


debug1: Unspecified GSS failure.  Minor code may provide more information
No Kerberos credentials available

debug1: Next authentication method: publickey
debug1: Offering DSA public key: /home/tim/.ssh/id_dsa
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password,keyboard-interactive
debug1: Offering RSA public key: /home/tim/.ssh/id_rsa
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password,keyboard-interactive
debug1: Trying private key: /home/tim/.ssh/id_ecdsa
debug1: Trying private key: /home/tim/.ssh/id_ed25519
debug1: Next authentication method: keyboard-interactive
Password:
ssh 
— Tim
fonte
La tua home directory è montata dopo il login?
— Muru,
Dopo ogni accesso in passato, la mia casa era sempre montata.
— Tim
Sì, una volta effettuato l'accesso, ottieni la tua home directory - ma che dire prima che l'accesso sia completo? (Considera le home directory crittografate o una home directory di rete, ecc.)
— muru,
Ho sentito che server2usa il file system Andrew. Significa che la mia casa non è montata prima che il login sia completo? Come posso scoprirlo per la tua domanda?
— Tim
Non sono sicuro di come funzioni il filesystem Andrew, ma se hai un altro login sullo stesso server, usalo e vedi se riesci a vedere il contenuto della timhome directory.
— muru,

Risposte:

10

Lei afferma che il secondo server sta utilizzando Andrew File System (AFS).

Non ci ho lavorato, ma da quello che ho capito, AFS è un filesystem protetto da Kerberos che richiede un ticket Kerberos per funzionare. Ciò significa che devi poter accedere al regno Kerberos del tuo sito per poter accedere alla tua home directory.

Se si accede con la password, server2è probabile che sia configurato in modo tale che acceda al proprio regno Kerberos tramite PAM. Se stai usando le chiavi SSH, tuttavia, server2non otterrai le informazioni necessarie per farlo e non sarai in grado di accedere alla tua home directory.

Fortunatamente, ssh -vdall'output nella tua domanda, possiamo dedurre che il tuo server ha l' GSSAPIautenticazione abilitata. Ciò dovrebbe consentire di eseguire un accesso senza password, a condizione che si disponga di un ticket Kerberos valido per il proprio regno. Fare quanto segue:

  • Accedere a server2, ed eseguire il klistprogramma. Questo restituirà qualcosa lungo le seguenti linee:

    Ticket cache: FILE:/tmp/krb5cc_2000
Default principal: wouter@EXAMPLE.ORG

Valid starting     Expires            Service principal
28-05-15 15:01:31  29-05-15 01:01:31  krbtgt/EXAMPLE.ORG@EXAMPLE.ORG
    renew until 29-05-15 15:01:28
28-05-15 15:02:04  29-05-15 01:01:31  IMAP/example.org@EXAMPLE.ORG
    renew until 29-05-15 15:01:28

    cerca la linea che inizia con Default principal:. Ti dice qual è il tuo kerberos principal (nell'esempio sopra, è wouter@EXAMPLE.ORG). Annota questo. Nota che non è un indirizzo email e che fa distinzione tra maiuscole e minuscole; cioè, il principale termina con EXAMPLE.ORG, no example.org.

  • Sul tuo computer client, esegui kinitcon il nome dell'entità (ovvero, nell'esempio precedente, sarebbe kinit wouter@EXAMPLE.ORG). Se tutto va bene, quando klisteseguirai di nuovo ora, vedrai che hai una cache dei biglietti sul tuo computer locale.
  • Se ora esegui ssh -K server2, dovresti essere in grado di accedere e il sistema non dovrebbe chiedere una password.

Si noti che a causa del funzionamento di Kerberos, una cache dei ticket ha una validità limitata. Non è possibile richiedere una cache dei ticket con validità più lunga di quella configurata dall'amministratore del regno (che di solito è qualcosa come 10 ore o giù di lì). Una volta scaduto il biglietto, dovrai correre di kinitnuovo e inserire di nuovo la password.

— Wouter Verhelst
fonte
Grazie. "Sul tuo computer client, esegui kinit", vuoi dire che devo installare Kerberos sul mio Ubuntu locale?
— Tim
Parte degli strumenti Kerberos, sì. Troverai gli strumenti richiesti nel krb5-userpacchetto.
— Wouter Verhelst,
Dovrei usare rsa o dsa quando creo le chiavi pubbliche e le copio sul server? (Ho seguito il suggerimento di Anthon di usare subito la dsa)
— Tim
A causa di AFS sul server, non è possibile utilizzare le chiavi pubbliche SSH, è invece necessario utilizzare Kerberos. Quindi non importa ;-)
— Wouter Verhelst,
GSSAPI, dsa e rsa sono tutti metodi di autenticazione?
— Tim
5

Dovresti provare a connetterti a server2 con:

ssh -v tim@server2

e confrontalo con lo stesso, collegarti a server1questo ti dirà esattamente dove differiscono i due server.

Molto probabilmente c'è una differenza in /etc/ssh/sshd_configentrambe le macchine. dove server2o il tuo ~/.sshha problemi di accessibilità (non abbastanza limitati).

Dalla -vuscita si può vedere che si offrono una chiave privata RSA per verificare contro la (in /home/tim/.ssh/id_rsa), ma sembra che server2solo supporta Diffie-Hellman (e cerca /home/tim/.ssh/id_dsa, che probabilmente non è nemmeno lì).

— Anthon
fonte
grazie, ho aggiornato con l'output di eseguire il tuo comando. Non sono sicuro di cosa significhi
— Tim
@Tim ha aggiornato la mia risposta, è necessario verificare con l'amministratore server2 perché non sembra supportare le chiavi private / pubbliche RSA.
— Anthon,
Oltre a chiedere all'amministratore (che ritengo impossibile apportare modifiche in base alle mie esperienze), c'è un modo per lavorare con ciò che il server si aspetta?
— Tim
@Tim, per prima cosa assicurati che ~/.sshsul server siano effettivamente installate le tue chiavi autorizzate ( ~/.ssh/authorized_keys). Quindi quello che potresti provare a fare è ssh-keygengenerare una coppia di chiavi diffie-hellman usando ssh-keygen -t dsae copiarlo.
— Anthon,
(1) C'è un file ~/.ssh/authorized_keyssul server. Ciò significa che ha le chiavi autorizzate installate? (2) come devo copiare la coppia di chiavi diffie-hellman generata sul server? di scp ~/.ssh/id_dsa.pub tim@server2:~/.ssh/authorized_keys? sovrascriverà ~/.ssh/authorized_keyssul server?
— Tim
4

Aggiungi la seguente voce nel computer client da cui stai provando a ssh.

file di configurazione: /etc/ssh/ssh_config

GSSAPIAuthentication no

Dopodiché sarai in grado di inviare ssh alla macchina.

Se non disponi delle autorizzazioni di modifica per quel file, puoi anche aggiungere

Host *
  GSSAPIAuthentication no

a ~/.ssh/config(creare questo file se non esiste)

— sudham rosso
fonte
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.