Comment puis-je configurer SSH pour ne pas avoir à taper mon mot de passe ?

Générez une clé SSH (si vous n'en avez pas)

Si vous utilisez GNOME, l'application seahorse (“Mots de passe et clés de chiffrement”) peut le faire pour vous : Fichier -> Nouveau -> Clé shell sécurisée.

Si vous préférez le terminal, exécutez ssh-keygen -t <type> pour générer une paire de clés. Les types de paires de clés valides sont :

• rsa : la valeur par défaut
• dsa : plus ou moins l'équivalent, sauf qu'il est limité aux clés de 1024 bits
• ecdsa : même sécurité avec des clés plus petites, mais relativement nouveau et quelque peu rare dans les logiciels SSH.
• ed25519 : haute sécurité (plus résistante aux attaques par canal latéral et aux faibles générateurs de nombres aléatoires). Génération de signature très rapide. Très nouveau. Disponible uniquement dans OpenSSH >= 6.5 .

Le programme vous demandera une passphrase et un emplacement où enregistrer la nouvelle clé. Il est recommandé d'utiliser le chemin par défaut suggéré car tous les autres outils le chercheront à cet endroit.

Téléchargez la clé publique sur le serveur distant

Encore une fois, seahorse peut souvent le faire pour vous - dans My Personal Keys, faites un clic droit sur votre clé SSH et choisissez Configure key for secure shell.

Ou, ssh-copy-id -i ~/.ssh/id_rsa.pub remote-user@remote-host dans le terminal.

Ou, complètement manuellement, étape par étape :

1. Créez un répertoire (s'il n'existe pas déjà) nommé .ssh dans le répertoire personnel de l'utilisateur distant sur l'hôte distant.
2. Dans ce répertoire, créez un fichier nommé authorized_keys (s'il n'existe pas déjà).
3. Au cas où votre umask distant est plus libéral que d'habitude, rendez le fichier non inscriptible dans un groupe : chmod go-w ~/.ssh ~/.ssh/authorized_keys.
4. Enfin, copiez (ajoutez) le contenu de votre clé publique locale (~/.ssh/id_rsa.pub) dans le fichier distant ~/.ssh/authorized_keys.

Chargez la clé dans l'agent ssh

Si vous chargez votre clé privée dans un agent ssh, celui-ci gardera la clé décryptée en mémoire. Nous voulons ainsi éviter de ressaisir le mot de passe chaque fois que nous nous connectons à un serveur.

Il faut d'abord lancer l'agent ou charger le chemin d'une socket de communication lancée dans une variable. L'exécution de ssh-agent sur un terminal générera des commandes pour l'attribution et le paramétrage des variables de l'agent. Ces commandes peuvent être enregistrées dans un fichier pour être utilisées dans un autre terminal. On peut aussi exécuter ces commandes et oublier de réutiliser le même agent dans un autre terminal. ex : eval $(ssh-agent).

Le chargement de la clé consiste simplement à exécuter ssh-add et à lui donner la phrase de passe.

Si vous utilisez GNOME, gnome-keyring-daemon fournit généralement la même fonctionnalité d'agent SSH que ssh-agent, vous ne devriez donc pas avoir besoin de démarrer quoi que ce soit. GNOME chargera et déverrouillera automatiquement la clé lors de la connexion, également.

Shell dans le serveur distant sans mot de passe

Si tout a été fait correctement, l'utilisation de ssh user@server ne vous demandera pas de mot de passe. Si quelque chose ne va pas avec l'agent et non avec la clé, il vous sera demandé de taper la phrase de passe pour la clé, et non le mot de passe du compte utilisateur.

Tout ce qui utilise ssh pour la communication fonctionnera sans entrer le mot de passe du compte utilisateur lorsque la bonne clé est chargée dans l'agent. Des programmes tels que scp , sftp et rsync utilisent cette fonction.

Notes :

• Vous n'avez besoin que d'une clé SSHv2, car SSHv1 est très peu sécurisé et n'est pas utilisé.
• Vous n'avez également besoin que d'un seul type de clé - RSA ou DSA suffit. (ed25519 et ECDSA sont tous deux récents et ne sont donc pas supportés partout).
• Toutes ces étapes sont les mêmes pour les clés RSA et DSA. Si vous utilisez DSA, utilisez id_dsa au lieu de id_rsa, et ECDSA aura id_ecdsa.
  
• Les serveurs OpenSSH plus anciens que 3.0 utilisaient authorized_keys2 - mais il est vraiment peu probable que vous trouviez quelque chose de plus ancien que 5.0 en service.
• Ces instructions ne s'appliquent qu'aux versions 3.0 et plus récentes d'OpenSSH. lsh, ssh.com, et les autres serveurs SSH (Unix et non) ne sont pas inclus dans ce tutoriel.

Exemples :

Vous n'avez pas précisé sur quel Unix vous êtes, à quel Unix vous vous connectez, quel shell vous utilisez, quelle variante SSH vous utilisez, etc. Donc une partie de cela pourrait avoir besoin d'être légèrement ajustée ; ceci est basé sur des versions raisonnablement récentes d'OpenSSH, qui est utilisé sur beaucoup de variantes d'Unix.

Tout cela provient de votre système de bureau local.

ssh-keygen

Assurez-vous d'utiliser la valeur par défaut pour le nom de clé. Je vous suggère de faire une phrase de passe sur cette clé, sinon c'est un problème de sécurité. “-t rsa” ne serait pas une mauvaise idée, mais ce n'est probablement pas nécessaire.

ssh-copy-id username@server

Cela vous demandera le mot de passe que vous utiliserez pour vous connecter, et vous permettra de configurer les clés autorisées. (pas besoin de le faire à la main)

Ensuite, ceci :

`ssh-agent`

ou peut-être ça :

exec ssh-agent sh

ou :

exec ssh-agent bash

Cela lancera un agent SSH qui pourra détenir votre clé. Sur de nombreuses variantes modernes d'Unix, si vous êtes connecté graphiquement, cela aura déjà eu lieu. La première variante (avec les backticks) met un agent ssh en arrière-plan et configure les variables d'environnement pour lui parler. Les deux autres font en sorte que l'agent exécute un shell pour vous, de sorte que lorsque vous quittez le shell, l'agent sort.

De nombreuses variantes modernes d'Unix ont déjà un agent qui fonctionne pour vous, surtout si vous vous êtes connecté graphiquement. Vous pouvez essayer “ps aux | grep ssh-agent” ou “ps -ef | grep ssh-agent” ; si quelque chose fonctionne déjà, utilisez-le.

Puis, enfin :

ssh-add

Il vous demandera une phrase de passe ; donnez-lui celle que vous avez donnée à ssh-keygen. Il est également possible de la faire demander graphiquement. Et vous pouvez mettre le ssh-agent et le ssh-add dans vos scripts de connexion (la configuration est différente selon le shell que vous utilisez) pour automatiser cela, mais certaines variantes d'Unix (Ubuntu Linux actuel, par exemple) font la plupart de cela automatiquement, de sorte que tout ce que vous avez vraiment besoin de faire est de créer une clé et d'utiliser ssh-copy-id pour la configurer sur l'hôte distant.

Maintenant, “ssh username@server” devrait fonctionner sans demander aucune authentification. En coulisses, il s'agit d'utiliser une clé que l'agent ssh tient en main, et de lui demander de faire les tours de magie de la signature pour elle.

Il est possible de le faire en PuTTY sur Windows également.

Une fois que vous avez configuré la paire de clés publiques/privées (comme le montrent les autres réponses), lancez PuttyGen, dans lequel vous pouvez charger la clé privée existante que vous avez déjà configurée, puis l'enregistrer en tant que clé privée PuTTY (ppk).

Puis dans PuTTY, cliquez simplement sur la session sauvegardée à laquelle vous voulez vous connecter automatiquement et cliquez sur Charger. De là, allez dans Connexion -> Données dans le panneau de gauche, et dans “Auto-login username” tapez le nom d'utilisateur de ce serveur distant :

Après cela, allez dans Connexion -> SSH -> Auth, et recherchez le ppk que vous avez fait dans PuttyGen :

Puis retournez à la page de session et sauvegardez la session que vous avez chargée précédemment.

D'après une question très similaire sur ServerFault , je vous recommande d'utiliser ssh-copy-id , qui effectue toutes les étapes de la mise en place des clés d'authentification pour vous :

ssh-copy-id est un script qui utilise ssh pour se connecter à une machine distante (probablement en utilisant un mot de passe de connexion, donc l'authentification par mot de passe devrait être activée, sauf si vous avez fait une utilisation intelligente de plusieurs identités)

Il modifie également les autorisations du domicile de l'utilisateur distant, ~/. ssh, et ~/.ssh/authorized_keys to remove group writability (qui autrement vous empêcherait de vous connecter, si le sshd distant a des StrictModes définis dans sa configuration).

Si l'option -i est donnée, alors le fichier d'identité (par défaut ~/.ssh/identity.pub) est utilisé, qu'il y ait ou non des clés dans votre ssh-agent.

Tout ce que vous avez à faire est simplement ceci :

ssh-copy-id user@host

Tapez votre mot de passe une fois, et vous pouvez y aller !

En dehors de tout ce qui a déjà été dit sur la façon de définir les clés ssh, je recommande Keychain comme frontal de console ssh-agent qui vous permet de gérer une seule clé par processus système au lieu de par connexion.

Je sais qu'il existe déjà des outils GNOME et KDE qui font la même chose mais si vous êtes du type console junkie c'est génial (et peut être utilisé sur la plupart des systèmes Unix).

Pour l'utiliser, il suffit d'ajouter ce qui suit à votre ~/.bashrc (similaire pour les autres shells) :

if type keychain >/dev/null 2>/dev/null; then
  keychain --nogui -q <all your SSH/PGP keys>
  [-f ~/.keychain/${HOSTNAME}-sh] && . ~/.keychain/${HOSTNAME}-sh
  [-f ~/.keychain/${HOSTNAME}-sh-gpg] && . ~/.keychain/${HOSTNAME}-sh-gpg
fi

J'ai écrit ce très très court tutoriel après avoir été VRAIMENT frustré par des tutoriels VRAIMENT longs car c'est vraiment très simple :)

test -f ~/.ssh/id_rsa.pub || ssh-keygen -t rsa #press enter twice if given prompts, then "ssh-add"

scp ~/.ssh/id_rsa.pub destID@destMachine:/tmp/ #type password

ssh destID@destMachine #type password

cat /tmp/id_rsa.pub >> ~/.ssh/authorized_keys

rm /tmp/id_rsa.pub

http://linuxproblem.org/art_9.html

Votre objectif

Vous voulez utiliser Linux et OpenSSH pour automatiser vos tâches. Vous avez donc besoin d'une connexion automatique de l'hôte A / utilisateur a à l'hôte B / utilisateur b. Vous ne voulez pas entrer de mots de passe, car vous voulez appeler ssh depuis a dans un script shell.

Putty a une option -pw qui vous permet de créer un raccourci sur le bureau comme ceci :

"C:\Program Files\PuTTY\putty.exe" -ssh user@192.168.2.2 -pw your_password

1. Sur l'hôte de connexion, exécutez ssh-keygen. (S'il vous dit que vous devez spécifier un type, faites ssh-keygen -t rsa.) Quand il vous demande un emplacement de fichier, prenez la valeur par défaut. Lorsqu'il vous demande une phrase de passe, appuyez sur la touche Entrée pour ne pas avoir de phrase de passe.
2. cat ~/.ssh/id_rsa.pub (ou quel que soit l'emplacement par défaut du fichier dans ssh-keygen, bien qu'il faille installer un vraiment ancien ssh pour qu'il soit différent) ; copiez la sortie dans votre presse-papiers.
3. Connectez-vous normalement à l'hôte de destination en tant que compte auquel vous voulez vous connecter. Editez le fichier ~/.ssh/authorized_keys (si ~/.ssh n'existe pas, slogin à un endroit quelconque ; c'est la façon simple et facile de le faire créer avec les bonnes permissions). Collez votre presse-papiers (contenant les id_rsa.pub de l'autre hôte) dans ce fichier.

Si vous voulez tout faire dans le terminal sous Linux :

Sur l'hôte

cd ~/.ssh/

ssh-keygen -t {rsa|dsa} -b {1024|2048|4096} -C “du texte de commentaire si vous voulez” -f id_ArbitraryName

Les éléments dans les {} sont des options, utilisez rsa ou dsa et choisissez la taille du bit (plus grand est plus sûr)

Ensuite, vous devez ajouter les permissions aux fichiers authorized_keys et authorized_keys2.

cat id_ArbitraryName.pub >> authorized_keys

cat id_AribtraryName.pub >> authorized_keys2

Ensuite, téléchargez le fichier id_AribtraryName sur la boîte à partir de laquelle vous voulez ssh. Si la boîte de connexion est basée sur unix, un fichier de configuration peut être nécessaire (en mastic, quelqu'un au-dessus a couvert cela).

Sur la boîte de connexion

Dans votre fichier de configuration - vim ~/.ssh/config

Host example.host.com # ou le nom de votre ordinateur

User username

IdentityFile ~/.ssh/id_ArbitraryName

Le fichier de configuration nécessite des autorisations de 600. Le dossier SSh a besoin de 700.

J'espère que cela vous aidera si vous rencontrez le problème de configuration qui est souvent omis.