Comment ajouter définitivement une clé privée avec ssh-add sur Ubuntu? [fermé]

474

J'ai une clé privée protégée par un mot de passe pour accéder à un serveur via SSH.

J'ai 2 machines Linux (Ubuntu 10.04) et le comportement de la commande ssh-add est différent dans les deux.

Dans une machine, une fois que j'ai utilisé "ssh-add .ssh / identity" et que j'ai entré mon mot de passe, la clé a été ajoutée de façon permanente, c'est-à-dire qu'à chaque fois que j'arrête l'ordinateur et me reconnecte, la clé est déjà ajoutée.

Dans l'autre, je dois ajouter la clé à chaque connexion.

Pour autant que je m'en souvienne, j'ai fait la même chose sur les deux. La seule différence est que la clé a été créée sur celle qui est ajoutée en permanence.

Est-ce que quelqu'un sait aussi l'ajouter de façon permanente à l'autre machine?

duduklein
la source
1
l'agent ne doit être que temporaire; mais il est possible que vous ayez la commande ssh-add quelque part dans ~ / .bashrc ou ainsi de suite sur l'une des deux machines
mirek

Réponses:

632

Une solution serait de forcer la conservation permanente des fichiers clés, en les ajoutant dans votre ~/.ssh/configfichier:

IdentityFile ~/.ssh/gitHubKey
IdentityFile ~/.ssh/id_rsa_buhlServer

Si vous n'avez pas de fichier 'config' dans le répertoire ~ / .ssh, vous devez en créer un. Il n'a pas besoin de droits root, donc simplement:

nano ~/.ssh/config

... et entrez les lignes ci-dessus selon vos besoins.

Pour que cela fonctionne, le fichier doit avoir chmod 600. Vous pouvez utiliser la commande chmod 600 ~/.ssh/config.

Si vous souhaitez que tous les utilisateurs de l'ordinateur utilisent la clé, mettez ces lignes dans /etc/ssh/ssh_configet la clé dans un dossier accessible à tous.

De plus, si vous souhaitez définir la clé spécifique à un hôte, vous pouvez effectuer les opérations suivantes dans votre ~ / .ssh / config:

Host github.com
    User git
    IdentityFile ~/.ssh/githubKey

Cela a l'avantage lorsque vous avez de nombreuses identités qu'un serveur ne vous rejette pas parce que vous avez d'abord essayé les mauvaises identités. Seule l'identité spécifique sera tentée.

daminetreg
la source
82
Les autorisations sur le fichier de configuration doivent être de 600.chmod 600 config
generalopinion
6
Je dois mettre mon mot de passe pour chaque push, fetch ou clone avec ceci, comment éviter cela?
Asaf
9
Utilisez-le à la place ssh-add ~/.ssh/gitHubKey, il se souviendra de votre phrase secrète. La solution que j'ai proposée était de la définir de façon permanente lors des redémarrages.
daminetreg
28
Cette réponse est si bonne que ssh-add ne devrait pas exister. Qui veut avoir une commande qui résout "temporairement" un problème et s'arrête de façon inattendue lorsque vous pouvez simplement modifier un fichier de configuration de façon permanente.
RussellStewart
2
Le problème est avec ce type de configuration, si vous ne le faites pas dans .ssh / config pour un hôte spécifique, vous obtiendrez toutes les clés contre tous les serveurs à chaque fois.
daminetreg
118

Cela n'a pas répondu au même problème pour moi sous Mac OS X Lion. J'ai fini par ajouter:

ssh-add ~/.ssh/id_rsa &>/dev/null

Pour mon .zshrc (mais .profile serait bien aussi), ce qui semble l'avoir corrigé.

(Comme suggéré ici: http://geek.michaelgrace.org/2011/09/permanently-add-ssh-key-ssh-add/ )

Aaron
la source
6
Je pense que c'est mieux que la solution que j'ai proposée, car ssh-add utilise un agent d'authentification qui peut se souvenir de la phrase secrète d'une clé privée protégée, de sorte que vous n'avez pas besoin de la taper à chaque fois que vous essayez de vous authentifier. Un autre avantage de la solution que vous proposez est que si vous avez beaucoup de clés, le client ssh ne proposera pas de clés non pertinentes pour le serveur auquel vous essayez de vous connecter, en effet il ne fournira que les clés qui sont pour ce serveur, et gagnera '' t conduire le serveur à refuser la connexion car MaxAuthTries est atteint, tout en essayant toutes les clés répertoriées dans ssh / config.
daminetreg
1
Merci @daminetreg. Mon problème particulier était d'avoir besoin d'accéder à Gitosis sur une machine de développement sans y transférer ma clé privée. Cette solution (en plus de l'ajouter ForwardAgent yesà la mienne .ssh/config) a résolu ce problème de manière fantastique. Il s'avère que cela pourrait être simplement ssh-add &>/dev/nullcomme le comportement par défaut de ssh-addsemble être d'ajouter les clés qu'il trouve dans votre .sshdossier.
Aaron
1
Ma compréhension est qu'il existe un commutateur -K dans Mac OS: stackoverflow.com/questions/1909651/…
Nicu Tofan
3
@TNick -Kajoute des clés au trousseau d'OS X, que les interfaces graphiques d'OS X utilisent pour s'authentifier auprès de serveurs étrangers. L'affiche dans laquelle Q se connecte via un tunnel SSH, mais se connecte toujours à un serveur distant. A - [Tunnel SSH] -> B Dans le cas où je suis, je suis sur un serveur distant mais je veux que l'authentification soit contre les informations d'identification sur mon système domestique. A <- [Auth] - B - [Connect] -> C Donc -Kça n'aide pas vraiment, mais c'est une excellente solution pour l'autre Q.
Aaron
112

J'ai résolu ce problème sur Mac OSX (10.10) en utilisant l'option -K pour ssh-add:

ssh-add -K ~/.ssh/your_private_key

Pour macOS 10.12 et versions ultérieures, vous devez également modifier votre configuration ssh comme décrit ici: https://github.com/jirsbek/SSH-keys-in-macOS-Sierra-keychain

totas
la source
3
c'est une meilleure réponse pour les gens qui veulent le définir de façon permanente
punkrockpolly
12
D'où ce bit: "sur Mac OSX (10.10)" ...
Andrew K.
1
C'est bien et fonctionne sur Mac OSX, mais ne fonctionne pas sur Ubuntu (14.04 sur mes tests).
haxpor
5
Cela n'a pas fonctionné pour moi (sur OSX 10.12.4)
guptron
2
Selon man ssh-addsur macOS High Sierra, ssh-add -Kenregistrera la phrase secrète dans le trousseau, et après le redémarrage, utilisez simplement ssh-add -A, qui n'a pas besoin de vous pour entrer votre phrase secrète.
DawnSong
36

Ajoutez simplement le trousseau, comme référencé dans les conseils rapides d'Ubuntu https://help.ubuntu.com/community/QuickTips

Quoi

Au lieu de démarrer constamment ssh-agent et ssh-add, il est possible d'utiliser le trousseau pour gérer vos clés ssh. Pour installer le trousseau, vous pouvez simplement cliquer ici, ou utiliser Synaptic pour faire le travail ou apt-get depuis la ligne de commande.

Ligne de commande

Une autre façon d'installer le fichier est d'ouvrir le terminal (Application-> Accessoires-> Terminal) et de taper:

sudo apt-get install keychain

Modifier le fichier

Vous devez ensuite ajouter les lignes suivantes à votre $ {HOME} /. Bashrc ou /etc/bash.bashrc:

keychain id_rsa id_dsa
. ~/.keychain/`uname -n`-sh
Christian Saiki
la source
Que fait exactement la deuxième commande, par curiosité? cela ouvre simplement les autorisations à l'utilisateur actuel?
Vincent Buscarello
1
Ceci .est un alias poursource
Brad Solomon
18

J'ai essayé la solution de @ Aaron et cela ne fonctionnait pas tout à fait pour moi, car elle ajoutait mes clés à chaque fois que j'ouvrais un nouvel onglet dans mon terminal. Je l'ai donc un peu modifié (notez que la plupart de mes clés sont également protégées par mot de passe, donc je ne peux pas simplement envoyer la sortie vers / dev / null):

added_keys=`ssh-add -l`

if [ ! $(echo $added_keys | grep -o -e my_key) ]; then
    ssh-add "$HOME/.ssh/my_key"
fi

Cela signifie qu'il vérifie la sortie de ssh-add -l(qui répertorie toutes les clés qui ont été ajoutées) pour une clé spécifique et s'il ne la trouve pas, il l'ajoute avec ssh-add.

Maintenant, la première fois que j'ouvre mon terminal, on me demande les mots de passe de mes clés privées et on ne me le redemande qu'au redémarrage (ou à la déconnexion - je n'ai pas vérifié) mon ordinateur.

Étant donné que j'ai un tas de clés, je stocke la sortie de ssh-add -ldans une variable pour améliorer les performances (au moins, je suppose que cela améliore les performances :))

PS: je suis sur linux et ce code est allé dans mon ~/.bashrcfichier - si vous êtes sur Mac OS X, je suppose que vous devez l'ajouter .zshrcou.profile

EDIT: Comme souligné par @Aaron dans les commentaires, le .zshrcfichier est utilisé à partir du zshshell - donc si vous n'utilisez pas cela (si vous n'êtes pas sûr, alors très probablement, vous utilisez à la bashplace), ce code devrait allez dans votre .bashrcdossier.

Nikola Ivanov Nikolov
la source
3
.zshrcest pour le zshshell, que j'utilise à la place bash. Si vous utilisez bashsur Mac OS X (par défaut), il serait également .bashrclà.
Aaron
1
Après le ssh-add -lcode retour echo $?peut être utilisé pour décider d'ajouter ou non une clé. Im ma machine Linux avec bash, le ssh-add -lne produira pas le nom de fichier clé. Le code retour fonctionne toujours.
Bharat G du
12

Dans mon cas, la solution était:

Les autorisations sur le fichier de configuration doivent être de 600. chmod 600 config

Comme mentionné dans les commentaires ci-dessus par generalopinion

Pas besoin de toucher le contenu du fichier de configuration.

erezmta
la source
Ce n'était pas suffisant pour moi sur Linux Mint 17.1.
Bénarès
Je ne pense pas que 600 soit logique. man ssh nous indique que le ~/.ssh/configfichier est en lecture / écriture pour l'utilisateur et non accessible en écriture pour les autres.
DawnSong
600 est en lecture et en écriture uniquement pour l'utilisateur
Enthusiasmus
6

J'ai eu le même problème sur Ubuntu 16.04: certaines clés ont été ajoutées en permanence, pour d'autres j'ai dû les exécuter ssh-addà chaque session. J'ai découvert que les clés ajoutées en permanence contenaient des clés privées et publiques ~/.sshet que les clés oubliées à chaque session n'avaient que des clés privées en ~/.sshdir. Donc , la solution est simple: vous devez copier à la fois la clé privée et publique ~/.sshavant d' exécuter ssh-add.

PS: D'après ce que je comprends du wiki Gnome, ma méthode fonctionne grâce à l'outil gnome-keyring qui fait partie de l'environnement de bureau Gnome. Par conséquent, ma méthode ne devrait probablement fonctionner que si vous utilisez Gnome ou DE basé sur Gnome.

NShiny
la source
1
Réponse sous-estimée. Cela a résolu mon problème sans avoir besoin de scripts ou de packages supplémentaires après une recherche de deux heures.
etagenklo
Flarkin fabuleux! Excellent travail de détective. Je ne pense pas que j'aurais compris cela.
nicorellius
4

L'ajout des lignes suivantes dans "~ / .bashrc" a résolu le problème pour moi. J'utilise le bureau Ubuntu 14.04.

eval `gnome-keyring-daemon --start`
USERNAME="reynold"
export SSH_AUTH_SOCK="$(ls /run/user/$(id -u $USERNAME)/keyring*/ssh|head -1)"
export SSH_AGENT_PID="$(pgrep gnome-keyring)"
reynoldpj
la source
3

Sur Ubuntu 14.04 (peut-être plus tôt, peut-être encore), vous n'avez même pas besoin de la console:

  • démarrer seahorseou lancer cette chose que vous trouvez en recherchant "clé"
  • créer une clé SSH là-bas (ou en importer une)
    • pas besoin de laisser la phrase secrète vide
    • il vous est même proposé de pousser la clé publique vers un serveur (ou plus)
  • vous vous retrouverez avec un ssh-agent en cours d'exécution et cette clé chargée, mais verrouillée
  • l'utilisation sshrécupérera l'identité (c'est-à-dire la clé) via l'agent
  • lors de la première utilisation pendant la session, la phrase secrète sera vérifiée
    • et vous avez la possibilité de déverrouiller automatiquement la clé lors de la connexion
    • cela signifie que l'authentification de connexion sera utilisée pour encapsuler la phrase secrète de la clé
  • Remarque: si vous souhaitez transmettre votre identité (c'est-à-dire le transfert d'agent), invoquez votre sshavec -Aou faites-en la valeur par défaut.
    • sinon vous ne pouvez pas vous authentifier avec cette clé sur une machine à laquelle vous vous connectez ultérieurement à une troisième machine
Robert Siemer
la source
3

J'exécute Ubuntu en utilisant deux clés id_rsa. (un personnel pour le travail). ssh-add se souviendrait d'une clé (personnelle) et oublierait l'entreprise à chaque fois.

En vérifiant la différence entre les deux, j'ai vu que ma clé personnelle avait 400 droits tandis que celle de l'entreprise avait 600 droits. (eu u + w). La suppression de l'écriture utilisateur directement à partir de la clé d'entreprise (uw ou définie sur 400) a résolu mon problème. ssh-add se souvient maintenant des deux clés.

Fholst
la source
2

Cela a fonctionné pour moi.

ssh-agent /bin/sh
ssh-add /path/to/your/key
Jaseem Abbas
la source
1

très simple ^ _ ^ deux étapes

1. yum installer le trousseau

2. ajoutez le code ci-dessous à .bash_profile

/usr/bin/keychain $HOME/.ssh/id_dsa
source $HOME/.keychain/$HOSTNAME-sh
LawrenceLi
la source
12
Ubuntu n'a pas miam idiot;)
Adam F
1

Pour ceux qui utilisent Fish shell, vous pouvez utiliser la fonction suivante puis l'appeler dans ~/.config/fish/config.fishou dans un fichier de configuration distinct dans ~/.config/fish/conf.d/loadsshkeys.fish. Il chargera toutes les clés commençant par id_rsa dans le ssh-agent.

# Load all ssh keys that start with "id_rsa"
function loadsshkeys
  set added_keys (ssh-add -l)
   for key in (find ~/.ssh/ -not -name "*.pub" -a -iname "id_rsa*")
    if test ! (echo $added_keys | grep -o -e $key)
      ssh-add "$key"
    end
  end
end

# Call the function to run it.
loadsshkeys

Si vous souhaitez ssh-agentdémarrer automatiquement lorsque vous ouvrez un terminal, vous pouvez utiliser tuvistavie / fish-ssh-agent pour ce faire.

frederickjh
la source