Comment forcer SSH à n'autoriser que les utilisateurs possédant une clé à se connecter?


73

J'ai essayé de suivre les instructions ici: http://lani78.wordpress.com/2008/08/08/generate-a-ssh-key-and-disable-password-authentication-on-ubuntu-server/

d'autoriser uniquement les utilisateurs possédant une clé publique sur le serveur à s'authentifier, mais SSH ne peut pas empêcher la connexion avec uniquement un nom d'utilisateur / mot de passe.

Voici mon fichier sshd_config - quelque chose me manque-t-il? J'ai déjà essayé de redémarrer SSH et l'ordinateur lui-même.

# Package generated configuration file
# See the sshd_config(5) manpage for details


# What ports, IPs and protocols we listen for
Port 22
# Use these options to restrict which interfaces/protocols sshd will bind to
#ListenAddress ::
#ListenAddress 0.0.0.0
Protocol 2
# HostKeys for protocol version 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
HostKey /etc/ssh/ssh_host_ecdsa_key
#Privilege Separation is turned on for security
UsePrivilegeSeparation yes


# Lifetime and size of ephemeral version 1 server key
KeyRegenerationInterval 3600
ServerKeyBits 768


# Logging
SyslogFacility AUTH
LogLevel INFO


# Authentication:
LoginGraceTime 120
PermitRootLogin yes
StrictModes yes


RSAAuthentication yes
PubkeyAuthentication yes
#AuthorizedKeysFile        %h/.ssh/authorized_keys


# Don't read the user's ~/.rhosts and ~/.shosts files
IgnoreRhosts yes
# For this to work you will also need host keys in /etc/ssh_known_hosts
RhostsRSAAuthentication no
# similar for protocol version 2
HostbasedAuthentication no
# Uncomment if you don't trust ~/.ssh/known_hosts for RhostsRSAAuthentication
#IgnoreUserKnownHosts yes


# To enable empty passwords, change to yes (NOT RECOMMENDED)
PermitEmptyPasswords no


# Change to yes to enable challenge-response passwords (beware issues with
# some PAM modules and threads)
ChallengeResponseAuthentication no


# Change to no to disable tunnelled clear text passwords
#PasswordAuthentication no


# Kerberos options
#KerberosAuthentication no
#KerberosGetAFSToken no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes


# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes


X11Forwarding yes
X11DisplayOffset 10
PrintMotd no
PrintLastLog yes
TCPKeepAlive yes
#UseLogin no


#MaxStartups 10:30:60
#Banner /etc/issue.net


# Allow client to pass locale environment variables
AcceptEnv LANG LC_*


Subsystem sftp /usr/lib/openssh/sftp-server


# Set this to 'yes' to enable PAM authentication, account processing,
# and session processing. If this is enabled, PAM authentication will
# be allowed through the ChallengeResponseAuthentication and
# PasswordAuthentication.  Depending on your PAM configuration,
# PAM authentication via ChallengeResponseAuthentication may bypass
# the setting of "PermitRootLogin without-password".
# If you just want the PAM account and session checks to run without
# PAM authentication, then enable this but set PasswordAuthentication
# and ChallengeResponseAuthentication to 'no'.
UsePAM no

1
FYI: En fait, le redémarrage de sshd n’est pas vraiment nécessaire. La commande /etc/inid.d/ssh reload devrait suffire.
Oliv

N'oubliez pas de retirer le commentaire de #AuthorizedKeysFile et de copier la clé publique dans ~ / .ssh / allowed_keys (et redémarrez). Sans cela, ça ne marchera pas.
ivanleoncz le

Si ce n'était pas le cas en 2016, c'est en 2019 qu'un redémarrage s'impose. le rechargement n'est pas suffisant.
KDN

Réponses:


98

Par défaut, la valeur PasswordAuthenticationest Oui , même si vous la commentez dans /etc/ssh/sshd_config.

Vous devez définir explicitement de manière PasswordAuthentication noà autoriser uniquement l'authentification par clé publique.

# To disable tunneled clear text passwords, change to no here!
PasswordAuthentication no

NOTE (man sshd_config): PasswordAuthentication spécifie si l'authentification par mot de passe est autorisée. La valeur par défaut est oui.

Et redémarrez sshd service ssh restart(migration pré-systemd) ou systemctl restart sshd.service.


6
Nous devrions aussi avoirUsePAM no
Konstantinos

@pidosaurus pourquoi? À quoi ça sert?
jan-glx

1
@YAK J'aime garder les choses simples et je préfère ne pas utiliser PAM. Mais quelqu'un peut utiliser une authentification PAM correctement configurée. Je pense que ce lien est éclairant: arlimus.github.io/articles/usepam
Konstantinos

1
Envisagez également de désactiver ChallengeResponseAuthentication, voir superuser.com/a/374234/2879 .
Cic

13

Selon cette page wiki sur les clés SSH et cette réponse , vous devez modifier ces deux lignes dans votre sshd_config:

PasswordAuthentication no
ChallengeResponseAuthentication no

1
Quelle différence la deuxième ligne à propos de la réponse au défi fait-elle?
Ryan Burnette

1
"Il ne fournit pas une" sécurité supplémentaire "en soi. Le terme" ChallengeResponseAuthentication "est simplement un mot clé de configuration OpenSSH; il fait référence à la méthode utilisateur" clavier-interactif "dans le protocole SSH - Richard Silverman (fixunix.com)
pzkpfw

4

En /etc/ssh/sshd_configdessous, les réglages ont fonctionné pour moi:

PasswordAuthentication no
UsePAM no

Enfin, redémarrez le sshddémon.


3

La ligne souhaitée est commentée de manière anormale par défaut dans le fichier sshd_config.

# Change to no to disable tunnelled clear text passwords
--->#PasswordAuthentication yes

Pour désactiver les mots de passe, remplacez-le yespar noet supprimez le commentaire :

# Change to no to disable tunnelled clear text passwords
PasswordAuthentication no

1

sur https://www.ssh.com/ssh/copy-id#sec-How-ssh-copy-id-works : en général, le répertoire de base de l'utilisateur ou tout fichier ou répertoire contenant des fichiers clés ne doit pas être inscriptible par quelqu'un d'autre . Sinon, quelqu'un d'autre pourrait ajouter de nouvelles clés autorisées pour l'utilisateur et y accéder. Les fichiers de clé privée ne doivent être lisibles par personne d’autre.

Essayez de sudo chmod go-rwx /home/username/remplacer usernamesi nécessaire.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.