Réponses:
Pour chaque utilisateur: ils doivent générer (sur leur ordinateur local) leur paire de clés à l’aide de ssh-keygen -t rsa(ils rsapeuvent être remplacés par dsaou rsa1aussi, bien que ces options ne soient pas recommandées). Ensuite, ils doivent placer le contenu de leur clé publique ( id_rsa.pub) ~/.ssh/authorized_keyssur le serveur en cours de connexion.
En fait, je préfère ssh-copy-id , un script trouvé par défaut sur * nix (qui peut également être placé sur Mac OS X assez facilement) et qui le fait automatiquement pour vous. De la page de manuel:
ssh-copy-id est un script qui utilise ssh pour se connecter à une machine distante (vraisemblablement en utilisant un mot de passe de connexion, l'authentification par mot de passe doit donc être activée, à moins que vous n'ayez utilisé intelligemment plusieurs identités).
Il modifie également les autorisations du domicile de l'utilisateur distant, ~ / .ssh et ~ / .ssh / allowed_keys pour supprimer l'aptitude du groupe à l'écriture (ce qui vous empêcherait de vous connecter si le sshd distant a StrictModes défini dans sa configuration).
Si l'option -i est donnée, le fichier d'identité (par défaut, ~ / .ssh / identity.pub) est utilisé, qu'il y ait ou non des clés dans votre agent ssh.
Hum, ne comprends pas. Créez simplement une clé et lancez-vous. :) HOWTO De plus, vous pouvez interdire la connexion avec un mot de passe. Par exemple, / etc / ssh / sshd_config:
PasswordAuthentication no
C'est assez simple à faire - il y a une procédure pas à pas qui se trouve ici .
Les points principaux sont:
ssh-keygensur votre machine. Cela générera des clés publiques et privées pour vous.~/.ssh/id_rsa.pub) sur ~/.ssh/authorized_keyssur la machine distante.Il est important de se rappeler que cela donnera à tous ceux qui ont accès à la clé privée de votre machine le même accès à la machine distante. Ainsi, lors de la génération de la paire de clés, vous pouvez choisir de saisir un mot de passe ici pour plus de sécurité.
Pour les utilisateurs de Windows à installer du mastic
Pour résumer ce que d'autres ont dit, la configuration de clés SSH est facile et inestimable.
Sur la machine que vous serez l' exécution de ssh de vous devez générer votre paire de clés:
claudius:~$ ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/home/dinomite/.ssh/id_rsa): <ENTER>
Enter passphrase (empty for no passphrase): <PASSPHRASE>
Enter same passphrase again: <PASSPHRASE>
Your identification has been saved in /home/dinomite/.ssh/id_rsa.
Your public key has been saved in /home/dinomite/.ssh/id_rsa.pub.
The key fingerprint is:
a3:93:8c:27:15:67:fa:9f:5d:42:3a:bb:9d:db:93:db dinomite@claudius
Appuyez simplement sur Entrée à l'endroit indiqué et saisissez une phrase secrète lorsque vous y êtes invité - idéalement, il diffère de votre mot de passe de connexion habituel sur l'hôte actuel et sur ceux pour lesquels vous effectuerez un SSHing.
Ensuite, vous devez copier la clé que vous venez de générer à l'hôte que vous voulez SSH à . La plupart des distributions Linux ont un outil ssh-copy-idpour cela:
claudius:~$ ssh-copy-id caligula.dinomite.net
Now try logging into the machine, with "ssh 'caligula.dinomite.net'", and check in:
.ssh/authorized_keys
to make sure we haven't added extra keys that you weren't expecting.
Si votre distribution n'en possède pas, vous devez alors copier la clé sur l'hôte de destination et l'ajouter au .ssh/authorized_keysfichier (éventuellement existant) :
claudius:~$ scp .ssh/id_dsa.pub caligula.dinomite.net:
id_dsa.pub 100% 1119 1.1KB/s 00:00
claudius:~$ ssh caligula.dinomite.net
Last login: Sat May 9 10:32:30 2009 from claudius.csh.rit.edu
Caligula:~$ cat id_dsa.pub >> .ssh/authorized_keys
Enfin, pour tirer le meilleur parti des clés SSH, vous devrez exécuter un agent SSH. Si vous utilisez un environnement de bureau (Gnome, KDE, etc.), il vous suffit de vous déconnecter puis de vous reconnecter pour démarrer un agent SSH. Sinon, vous pouvez ajouter ce qui suit à votre shell fichier RC ( .bashrc, .profile, etc.):
SSHAGENT=/usr/bin/ssh-agent
SSHAGENTARGS="-s"
if [ -z "$SSH_AUTH_SOCK" -a -x "$SSHAGENT" ]; then
eval `$SSHAGENT $SSHAGENTARGS`
trap "kill $SSH_AGENT_PID" 0
fi
Ceci est conçu comme une liste de contrôle. Si on le suit point par point, les pièges les plus courants pour les connexions sans mot de passe devraient être couverts. La plupart de ces points sont mentionnés ailleurs; c'est une agrégation.
Il doit exister un ~/.sshrépertoire chmod 700sur chaque machine sous le compte qui établira ou recevra les connexions.
La clé (privée) doit être générée sans phrase secrète. Vous pouvez également démarrer un agent contenant une version déchiffrée de la clé portant la phrase secrète à utiliser par les clients. Démarrer l'agent avec ssh-agent $SHELL. C'est la $SHELLpartie qui m'a pris un certain temps à trouver. Reportez-vous à la page de manuel car il existe de nombreux détails si vous souhaitez utiliser un agent.
N'oubliez pas que par défaut, les clés faibles (DSA <2048 bits) ne sont pas acceptées par les versions récentes de sshd.
Ce qui suit doit se faire sur la machine côté client pour origine une connexion.
Votre clé privée doit être placée dans ~/.ssh/id_rsaou ~/.ssh/id_dsaselon le cas. Vous pouvez utiliser un autre nom, mais il doit ensuite être inclus dans une option -i de la commande ssh sur la machine d'origine pour indiquer explicitement la clé privée.
Votre clé privée doit être chmod 600.
Vérifiez que votre dossier personnel est chmod 700.
Maintenant, pour permettre à une machine de recevoir une demande. Un modèle courant est celui où un administrateur vous donne accès à une machine que vous ne possédez pas (comme l'hébergement Web partagé). Par conséquent, l'idée de ssh est que vous offriez votre clé publique à quiconque vous donne le compte. C'est pourquoi vous ne mettez généralement pas de clés privées sur la machine qui reçoit les demandes. Mais, si vous voulez que cette machine effectue également la sortie SSH, vous devez la traiter comme une machine d'origine avec les étapes ci-dessus.
~/.ssh/authorized_keyssous le compte qui recevra les connexions. Vous pouvez également placer ici d'autres clés autorisées à se connecter via ce compte. Une chose particulièrement délicate si vous êtes dans vi et que vous collez la clé dans le fichier à partir du tampon de collage dans PuTTY est la suivante: la clé commence par un "ssh-". Si vous n'êtes pas en mode insertion, le premier "s" mettra vi en mode insertion et le reste de la touche aura l’air parfait. Mais vous manquerez un "s" au début de la clé. Cela a pris des jours pour que je trouve ça.chmod 600 ~/.ssh/authorized_keys. Il doit être au moins gw.Comme d'autres l'ont déjà dit, vos utilisateurs doivent créer leurs propres paires de clés sur leurs machines clientes avec ssh-keygen et ajouter leur clé publique à ~ / .ssh / allowed_keys sur la machine à laquelle ils souhaitent se connecter.
Pour des informations plus détaillées cependant, je recommande vivement SSH, Secure Shell .
Il y a un bon conseil ici, donc je ne le répéterai pas. Une fois qu'un serveur est configuré pour vous permettre de vous connecter avec des clés, vous pouvez en configurer d'autres pour qu'il en fasse de même avec cette seule ligne:
remote=server1 server2 server3 server4
for r in $remote; do echo connecting to $r; tar czf - ./.ssh/id*.pub ./.ssh/authorized_keys2 ./.ssh/config | ssh $r "tar zxf -; chmod 700 .ssh" ; done
Il suffit de vous connecter à votre répertoire personnel, de définir la variable remote comme un ou plusieurs noms de serveur et d’en faire plusieurs à la fois. Le mot de passe demandé sera votre mot de passe ssh pour le serveur distant. Vous pouvez bien sûr utiliser une version simplifiée sans la boucle for:
tar czf - ./.ssh/id*.pub ./.ssh/authorized_keys2 ./.ssh/config | ssh YOUR_SERVER_NAME_HERE "tar ztvf -; chmod 700 .ssh"
N'OUBLIEZ PAS: Copiez uniquement vos clés publiques. Vous ne voulez pas que vos clés privées restent sur un serveur sur lequel tout le monde avec sudo peut les copier et forcer votre phrase secrète.