1 votes

SSH root sans mot de passe sur CentOS 6 avec clé publique

J'essaie de créer une configuration "sans mot de passe" afin que le serveur distant soit plus sûr sans mot de passe et que je puisse automatiser le processus de connexion.

J'ai créé une nouvelle clé ssh avec ssh-keygen, et copié le fichier public sur le serveur distant dans ./ssh/authorized_keys, mais je suis toujours invité à entrer le mot de passe.

Le serveur fonctionne sous CentOS 6.8.

Voici mes étapes

Sur ma machine locale (OS X)

ssh-keygen (et laisser une phrase de passe vide)

pbcopy < ~/.ssh/remote_server.pub (sur Mac, ceci copie le contenu du fichier public)

Sur le serveur distant (CentOS 6.8)

$ cd /root/.ssh

$ touch authorized_keys

$ nano authorized_keys (puis collé le contenu de la clé publique et enregistré le fichier)

$ chmod 600 authorized_keys

$ service sshd restart

Ensuite, lorsque j'essaie d'accéder via le service SSH (par exemple, ssh remove-server.com), j'obtiens toujours l'invite normale de mot de passe.

Y a-t-il un problème avec la propriété/les autorisations du fichier ?

Mise à jour

voici le contenu du fichier /etc/ssh/sshd_config du distant

#   $OpenBSD: sshd_config,v 1.80 2008/07/02 02:24:18 djm Exp $

# This is the sshd server system-wide configuration file.  See
# sshd_config(5) for more information.

# This sshd was compiled with PATH=/usr/local/bin:/bin:/usr/bin

# The strategy used for options in the default sshd_config shipped with
# OpenSSH is to specify options with their default value where
# possible, but leave them commented.  Uncommented options change a
# default value.

#Port 22
#AddressFamily any
#ListenAddress 0.0.0.0
#ListenAddress ::

# Disable legacy (protocol version 1) support in the server for new
# installations. In future the default will change to require explicit
# activation of protocol 1
Protocol 2

# HostKey for protocol version 1
#HostKey /etc/ssh/ssh_host_key
# HostKeys for protocol version 2
#HostKey /etc/ssh/ssh_host_rsa_key
#HostKey /etc/ssh/ssh_host_dsa_key

# Lifetime and size of ephemeral version 1 server key
#KeyRegenerationInterval 1h
#ServerKeyBits 1024

# Logging
# obsoletes QuietMode and FascistLogging
#SyslogFacility AUTH
SyslogFacility AUTHPRIV
#LogLevel INFO

# Authentication:

#LoginGraceTime 2m
#PermitRootLogin yes
#StrictModes yes
#MaxAuthTries 6
#MaxSessions 10

RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile  .ssh/authorized_keys
#AuthorizedKeysCommand none
#AuthorizedKeysCommandRunAs nobody

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

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

# Change to no to disable s/key passwords
#ChallengeResponseAuthentication yes
ChallengeResponseAuthentication no

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

# GSSAPI options
#GSSAPIAuthentication no
GSSAPIAuthentication yes
#GSSAPICleanupCredentials yes
GSSAPICleanupCredentials yes
#GSSAPIStrictAcceptorCheck yes
#GSSAPIKeyExchange no

# 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
UsePAM yes

# Accept locale-related environment variables
AcceptEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES
AcceptEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT
AcceptEnv LC_IDENTIFICATION LC_ALL LANGUAGE
AcceptEnv XMODIFIERS

#AllowAgentForwarding yes
#AllowTcpForwarding yes
#GatewayPorts no
#X11Forwarding no
X11Forwarding yes
#X11DisplayOffset 10
#X11UseLocalhost yes
#PrintMotd yes
#PrintLastLog yes
#TCPKeepAlive yes
#UseLogin no
#UsePrivilegeSeparation yes
#PermitUserEnvironment no
#Compression delayed
#ClientAliveInterval 0
#ClientAliveCountMax 3
#ShowPatchLevel no
#UseDNS yes
#PidFile /var/run/sshd.pid
#MaxStartups 10:30:100
#PermitTunnel no
#ChrootDirectory none

# no default banner path
#Banner none

# override default of no subsystems
Subsystem   sftp    /usr/libexec/openssh/sftp-server

# Example of overriding settings on a per-user basis
#Match User anoncvs
#   X11Forwarding no
#   AllowTcpForwarding no
#   ForceCommand cvs server

Sortie de ssh -v

...
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /Users/m/.ssh/id_rsa
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Offering RSA public key: /Users/m/.ssh/centos_server
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Trying private key: /Users/m/.ssh/id_dsa
debug1: Trying private key: /Users/m/.ssh/id_ecdsa
debug1: Trying private key: /Users/m/.ssh/id_ed25519
debug1: Next authentication method: password

De plus, j'ai défini des permissions pour corriger un bogue avec SELinux.

chmod 700 ~/.ssh && chmod 600 ~/.ssh/authorized_keys
restorecon -R -v /root/.ssh

Source :

3voto

Lolloz89 Points 133

Tout d'abord, vous ne devriez pas accéder à votre serveur distant en tant que root ! même avec une authentification par clé. La chose la plus sûre à faire est de créer un autre utilisateur normal et de l'ajouter aux sudoers (utilisez la commande visudo pour cela). Désactivez ensuite la connexion en tant que root en utilisant sudo passwd -l root

Ensuite, vous devez modifier votre /etc/ssh/sshd_config pour activer l'authentification par clé publique. Trouvez la ligne qui dit PasswordAuthentication et de le régler sur no (si vous voulez désactiver les défis de mot de passe pour tous les utilisateurs)

Assurez-vous que RSAAuthentication y PubkeyAuthentication sont réglés sur oui.

Désactivez également la connexion de l'utilisateur root en définissant PermitRootLogin no

Si dans le cas où PermitRootLogin ne fonctionne pas comme vous le souhaitez, essayez cette alternative en ajoutant

DenyUsers root

2voto

pamcevoy Points 101

Connectez-vous avec ssh -v user@host et vous aurez plus d'informations. Habituellement, les permissions du dossier .ssh et authorized_keys causent des problèmes dans ces paramètres.

J'utilise ssh-copy-id pour autoriser les clés dans les hôtes distants.

0voto

Scottie H Points 227

J'ai eu ce problème. Dans votre fichier sshd_config, changez :
#PermitRootLogin yes
à
PermitRootLogin without-password
Je suis d'accord que permettre à root de se connecter sans mot de passe est stupide, cependant
Nous avons un "nœud de confiance racine". Seule cette machine a la permission de se connecter en tant que root, sans mot de passe, sur tous nos serveurs. De cette façon, nous pouvons automatiser les tâches lorsque cela est nécessaire.

Pour ce faire, ajoutez cette phrase à la fin de votre ligne authorized_key :
root@mytrustednode (Remarquez l'espace avant la racine)
mytrustednode est le nom d'hôte de votre "nœud de confiance racine". De cette façon, seul l'utilisateur racine sur mytrustednode peut se connecter à la machine sans mot de passe.

-1voto

Bilbo Bongo Points 99

Typiquement, vous voulez que les permissions du répertoire .ssh soient de 700 (drwx------) et la clé publique (fichier .pub) à 644 (-rw-r--r--). Votre clé privée (id_rsa) doit être à 600 (-rw-------).

Entrez la description du lien ici

Source :

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X