Avec les versions récentes de Fedora et RHEL 6, vous pouvez utiliser RequiredAuthentications2 pubkey, password pour exiger l'authentification par mot de passe pubkey et . Habituellement, cela nécessite une clé pub et un jeton d'authentification à 2 facteurs, pas le mot de passe de l'utilisateur.

Mise à jour: maintenant sur RHEL / CentOS 7, et tout système avec une version récente d'OpenSSH, vous pouvez utiliser:

  AuthenticationMethods "publickey, password" "publickey, keyboard-interactive"  

Il est également possible d'utiliser la directive Match pour exclure les adresses IP ou Utilisateurs.

Vous pouvez avoir à la fois une authentification par clé publique et par mot de passe sur le même serveur. Si l'authentification par clé publique échoue, elle passera à l'authentification par mot de passe.

Quant à exiger les deux, cela semble idiot et contre-productif, et en vérifiant man sshd_config , il n'y a pas d'option pour faites ceci.

Votre clé privée ssh doit avoir une phrase secrète sécurisée. Donc, si un attaquant obtient votre clé privée, il ne peut toujours rien faire sans obtenir au préalable votre phrase de passe. S'ils ont compromis cette phrase de passe (très probablement avec un keylogger; ou en forçant brutalement une phrase de passe extrêmement faible), ils peuvent aussi saisir / forcer brutalement tout mot de passe mémorisé.

Si vous le souhaitez vraiment, vous pouvez éventuellement configurez quelque chose avec ForceCommand (par exemple, autorisez uniquement l'authentification par clé publique, puis dirigez l'utilisateur vers un shell qui demande un mot de passe). Je ne recommande pas cela.

Une meilleure alternative si vous voulez limiter l'exposition, est d'avoir une configuration de pare-feu pour limiter les adresses IP qui peuvent atteindre le port ssh; éventuellement avec un VPN supplémentaire fonctionnant sur un serveur quelque part si vous avez besoin de tunnel depuis un autre ordinateur à un moment donné. Vous pouvez également utiliser quelque chose comme knockd pour ouvrir un trou dans un pare-feu après un modèle de frappe de port particulier, tout en reconnaissant que toute personne écoutant le trafic pourrait rejouer le modèle de frappe pour ouvrir un port.

(affichage croisé de réponse SO avec une solution mise à jour pour ces jours)

Si vous lisez la page de manuel de sshd_config (5) , là est l'option AuthenticationMethods , qui prend la liste des méthodes que vous devez passer avant de vous accorder l'accès. Votre configuration requise est:

  AuthenticationMethods publickey, mot de passe  

Cette méthode devrait fonctionner sur tous les systèmes Linux actuels avec des openshs récents (openssh-6, openssh-7 ).

Systèmes plus anciens

La seule exception que je connaisse est RHEL 6 (openssh-5.3), qui nécessite de définir une option différente avec les mêmes valeurs (comme décrit dans l'autre réponse):

  RequiredAuthentications2 publickey, mot de passe  

J'ai examiné cela un peu plus et j'ai trouvé ce qui suit.

Vous pouvez utiliser PAM pour l'authentification à deux facteurs, mais ce faisant, vous n'utiliserez pas de clés SSH, vous utiliserez un deux facteurs différents.

Par exemple, vous pouvez utiliser google avec leur authentification à deux facteurs et utiliser pam pour vous authentifier, comme décrit à

http: //www.techrepublic. com / blog / opensource / authentification-ssh-à deux-facteurs-via-google-secures-linux-logins / 2607

La seule solution qui a fonctionné pour moi est d'avoir ce qui suit dans le fichier / etc / ssh / sshd_config (testé avec un CentOS7):

  PubkeyAuthentication oui AuthenticationMethods publickey passwordAuthorizedKeysFile .ssh / allowed_keysPasswordAuthentication oui PermitEmptyPasswords noChallengeResponseAuthentication noUsePAM yes  

Ce qui signifie avoir PAM activé, avoir activé chaque ligne qui concerne la clé publik et, enfin, que AuthenticationMethods répertorie correctement les deux méthodes. a été écrit par Jakuje, vous ne devez pas ajouter de virgule entre publickey et password après AuthenticationMethods.