J'essaie de passer d'un NAS à un serveur Web à l'aide d'une clé publique. NAS utilisateur est 'root' et utilisateur du serveur Web est 'sauvegarde'
J'ai toutes les autorisations définies correctement et lorsque je débogue la connexion SSH, je reçois: (dernier petit morceau du débogage)
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Next authentication method: publickey
debug1: Offering DSA public key: /root/.ssh/id_dsa.pub
debug1: Server accepts key: pkalg ssh-dss blen 433
debug1: key_parse_private_pem: PEM_read_PrivateKey failed
debug1: read PEM private key done: type <unknown>
Enter passphrase for key '/root/.ssh/id_dsa.pub':
J'utilise la commande:
ssh -v -i /root/.ssh/id_dsa.pub [email protected]
Le fait qu'il demande une phrase secrète est sûrement un bon signe, mais je ne veux pas que ce soit demandé ou un mot de passe (qui vient ensuite si j'appuie sur 'return' sur la phrase secrète)
Cela m'est arrivé lorsque la clé privée que j'avais n'était pas au format OpenSSH.
À l’origine, j’avais généré ma clé sous Windows à l’aide de PuttyGen et j’avais été renvoyé avec la même chose.
J'ai pu résoudre le problème en chargeant la clé dans PuttyGen et en cliquant sur "Conversions" pour le convertir au format OpenSSH.
Pour moi, puisque la clé elle-même était cryptée, j'ai suivi les étapes suivantes:
$ ssh-agent bash
$ ssh-add
$ ssh-add /location/of/key
Pour inspecter à tout moment la liste des clés actuellement chargées:
$ ssh-add -l
Il y a quelques choses.
Principalement, si la clé demande un mot de passe, la clé a été générée avec. Deuxièmement, si le système demande un mot de passe après, la clé ne s’authentifie pas. Cela signifie que vous devrez régénérer votre clé SSH (ou la modifier comme suggéré par @rbtux) et réparer les fichiers allowed_keys.
ssh-keygen -t {dsa | rsa} -b {1024 | 2048 | 4096} -C "commentaire facultatif" -f id_examplekey
Les éléments entre accolades sont les options, le type et la taille en bits (pour énoncer une évidence: dsa> rsa, 4096> 1024 - en termes de "sécurité").
Ensuite, vous devez ajouter la clé publique (.pub) aux fichiers authorized_keys
et authorized_keys2
(il est courant de penser que le .pub est destiné à une utilisation locale, mais il doit être comparé à), donc dans le dossier .ssh
du serveur.
$ cat id_examplekey.pub >> registered_keys {, 2}
Ensuite, vous devez vous assurer que les autorisations de clé sont chmod 600 id_example
et pour éviter de taper tout cela, vous pouvez configurer le fichier de configuration: ~/.ssh/config
sur votre boîte locale (c’est un squelette, vous pouvez le personnaliser un peu plus):
Host example.com
User WHATEVERNAME
IdentityFile ~/.ssh/id_examplekey
try https://wiki.gentoo.org/wiki/Keychain
C'est en quelque sorte un enveloppement sur ssh-agent
et ssh-add
Avantages: Pas besoin de saisir le mot de passe à plusieurs reprises tant que vous ne redémarrez pas. Peut être utilisé dans crontab
.
Ce pourrait être une aide.
C'est peut-être parce que vous utilisez une clé publique DSA qui est désactivée par défaut dans OpenSSH v7.
Si vous ne pouvez pas modifier la paire de clés, une solution possible consiste à indiquer à votre démon SSH de webserver.com d'accepter ces types de clé, en mettant à jour /etc/ssh/sshd_config
ou l'équivalent en ajoutant la ligne suivante.
PubkeyAcceptedKeyTypes=+ssh-dss
Et puis redémarrer le service
/etc/init.d/ssh restart # or equivalent
Sur Mac OSX, vous pouvez ajouter votre clé privée au trousseau à l’aide de la commande suivante:
ssh-add -K /path/to/private_key
Si votre clé privée est stockée dans ~/.ssh et s'appelle id_rsa:
ssh-add -K ~/.ssh/id_rsa
Vous serez alors invité à entrer votre mot de passe, qui sera stocké dans votre trousseau.