Impossible de configurer la connexion ssh sans taper le mot de passe

8

Je configure automatiquement la connexion ssh sans taper de mot de passe sur un serveur en:

cd ~/.ssh

ssh-keygen

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

Cela fonctionne sur le serveur.

Plus tard, j'ai fait de même sur un autre serveur.

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

Immédiatement moi ssh tim@server2, mais cela nécessite toujours mon mot de passe. Ai-je fait quelque chose de mal? Quelles sont les raisons possibles pour lesquelles je n'ai pas réussi à configurer sur le deuxième serveur? (notez que le deuxième serveur exécute le système de fichiers kerberos et 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:

J'ai essayé la méthode d'Anthon d'utiliser les clés Diffie-Hellman, mais il me demande toujours mon mot de passe.

$ 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
la source
Votre répertoire personnel est-il monté après votre connexion?
muru
Après chaque connexion dans le passé, ma maison était toujours montée.
Tim
Oui, une fois connecté, vous obtenez votre répertoire personnel - mais qu'en est-il avant que la connexion ne soit terminée? (Considérez les répertoires personnels chiffrés, ou un répertoire personnel du réseau, etc.)
muru
J'ai entendu dire qu'il server2utilise le système de fichiers Andrew. Cela signifie-t-il que ma maison n'est pas montée avant la fin de la connexion? Comment le trouver pour votre question?
Tim
Je ne sais pas comment fonctionne le système de fichiers Andrew, mais si vous avez une autre connexion sur le même serveur, utilisez-la et voyez si vous pouvez voir le contenu du timrépertoire personnel de.
muru

Réponses:

10

Vous mentionnez que le deuxième serveur utilise le système de fichiers Andrew (AFS).

Je n'ai pas travaillé avec cela, mais d'après ce que je comprends, AFS est un système de fichiers sécurisé par Kerberos qui nécessite un ticket Kerberos pour fonctionner. Cela signifie que vous devez être connecté au domaine Kerberos de votre site pour pouvoir accéder à votre répertoire personnel.

Si vous vous connectez avec un mot de passe, server2est probablement configuré de sorte qu'il vous connecte à votre domaine Kerberos via PAM. Si vous utilisez des clés SSH, cependant, vous server2n'obtiendrez pas les informations nécessaires pour le faire et vous ne pourrez pas accéder à votre répertoire personnel.

Heureusement, à partir de la ssh -vsortie de votre question, nous pouvons déduire que votre serveur a GSSAPIactivé l'authentification. Cela devrait vous permettre d'effectuer une connexion sans mot de passe, à condition que vous ayez un ticket Kerberos valide pour votre domaine. Procédez comme suit:

  • Connectez-vous à server2et exécutez le klistprogramme. Cela renverra quelque chose comme suit:

    Ticket cache: FILE:/tmp/krb5cc_2000
Default principal: [email protected]

Valid starting     Expires            Service principal
28-05-15 15:01:31  29-05-15 01:01:31  krbtgt/[email protected]
    renew until 29-05-15 15:01:28
28-05-15 15:02:04  29-05-15 01:01:31  IMAP/[email protected]
    renew until 29-05-15 15:01:28

    recherchez la ligne qui commence par Default principal:. Il vous indique quel est votre principal kerberos (dans l'exemple ci-dessus, c'est [email protected]). Notez ceci. Notez qu'il ne s'agit pas d'une adresse e-mail et qu'elle est sensible à la casse; c'est-à-dire que le principal se termine par EXAMPLE.ORGnon example.org.

  • Sur votre ordinateur client, exécutez kinitavec le nom de votre principal (c'est-à-dire, dans l'exemple ci-dessus, ce serait kinit [email protected]). Si tout se passe bien, lorsque vous exécutez à klistnouveau maintenant, vous verrez que vous avez un cache de tickets sur votre machine locale.
  • Si vous exécutez maintenant ssh -K server2, vous devriez pouvoir vous connecter et le système ne doit pas demander de mot de passe.

Veuillez noter qu'en raison du fonctionnement de Kerberos, le cache des tickets a une validité limitée. Il n'est pas possible de demander un cache de tickets avec une validité plus longue que ce que l'administrateur du domaine a configuré (ce qui correspond généralement à environ 10 heures). Une fois votre ticket arrivé à expiration, vous devrez kinitrecommencer et saisir à nouveau votre mot de passe.

Wouter Verhelst
la source
Merci. "Sur votre machine client, exécutez kinit", voulez-vous dire que je dois installer Kerberos sur mon Ubuntu local?
Tim
Une partie des outils Kerberos, oui. Vous trouverez les outils nécessaires dans le krb5-userpackage.
Wouter Verhelst
Dois-je utiliser rsa ou dsa lors de la création des clés publiques et de leur copie sur le serveur? (J'ai suivi la suggestion d'Anthon d'utiliser dsa en ce moment)
Tim
En raison de l'AFS sur le serveur, vous ne pouvez pas utiliser de clés publiques SSH, vous devez utiliser des kerberos à la place. Donc peu importe ;-)
Wouter Verhelst
GSSAPI, dsa et rsa sont-ils tous des méthodes d'authentification?
Tim
5

Vous devez essayer de vous connecter à server2 avec:

ssh -v tim@server2

et comparer cela avec le même, la connexion à server1cela vous dira exactement où les deux serveurs diffèrent.

Il y a très probablement une différence entre /etc/ssh/sshd_configles deux machines. où server2ou votre ~/.ssha des problèmes d'accessibilité (pas assez restreint).

À partir de la -vsortie, vous pouvez voir que vous proposez une clé privée RSA pour vérifier (en /home/tim/.ssh/id_rsa), mais il semble que server2ne supporte que Diffie-Hellman (et essaie /home/tim/.ssh/id_dsace qui n'est probablement même pas là).

Anthon
la source
merci, j'ai mis à jour avec la sortie de l'exécution de votre commande. Je ne sais pas ce que cela signifie
Tim
@Tim a mis à jour ma réponse, vous devriez vérifier auprès de l'administrateur de server2 pourquoi il ne semble pas prendre en charge les clés privées / publiques RSA.
Anthon
En plus de demander à l'administrateur (ce qui, selon moi, est impossible de faire des changements en fonction de mes expériences), existe-t-il un moyen de travailler avec ce que le serveur attend?
Tim
@Tim, assurez-vous d'abord que ~/.sshle serveur a bien vos clés autorisées installées ( ~/.ssh/authorized_keys). Ensuite, ce que vous pourriez essayer de faire est de ssh-keygengénérer une paire de clés diffie-hellman en utilisant ssh-keygen -t dsaet de la copier.
Anthon
(1) Il y a un fichier ~/.ssh/authorized_keyssur le serveur. Est-ce à dire que les clés autorisées sont installées? (2) comment copier la paire de clés diffie-hellman générée sur le serveur? par scp ~/.ssh/id_dsa.pub tim@server2:~/.ssh/authorized_keys? cela écrasera-t-il ~/.ssh/authorized_keyssur le serveur?
Tim
4

Ajoutez l'entrée suivante dans la machine cliente à partir de laquelle vous essayez de ssh.

fichier de configuration: /etc/ssh/ssh_config

GSSAPIAuthentication no

Après cela, vous pourrez accéder à la machine.

Si vous ne disposez pas des autorisations de modification pour ce fichier, vous pouvez également ajouter

Host *
  GSSAPIAuthentication no

à ~/.ssh/config(créer ce fichier s'il n'existe pas)

sudhams reddy
la source