web-dev-qa-db-fra.com

Comment puis-je me connecter en tant que root à une instance de cloud?

Je peux me connecter avec succès à mon instance de cloud en tant qu'utilisateur 'ubuntu' via SSH mais je ne peux pas me connecter en tant qu'utilisateur 'root'. Il y a plusieurs publications qui traitent de la modification de la configuration ssh afin de permettre l'accès à la racine, même si aucune n'a fonctionné de ma part. Par exemple, j'ai apporté les modifications habituelles au fichier/etc/ssh/sshd_config, à savoir:

#Authentication
PermitRootLogin yes

Cela n'a eu aucun effet.

Maintenant, le message que je reçois lorsque j'essaie de me connecter en tant que "root" est le suivant:

Veuillez vous connecter en tant qu'utilisateur "Ubuntu" plutôt qu'en tant qu'utilisateur "root".

En cherchant "Veuillez vous connecter", j'ai trouvé dans le fichier '/usr/lib/python3/dist-packages/cloudinit/config/cc_ssh.py' (de tous les endroits), les lignes suivantes:

DISABLE_ROOT_OPTS = (
"no-port-forwarding,no-agent-forwarding,"
"no-X11-forwarding,command=\"echo \'Please login as the user \\\"$USER\\\""
" rather than the user \\\"root\\\".\';echo;sleep 10\"")

Je ne peux pas en tirer grand chose. Je suppose que ce script Python a été exécuté lors de la création de l'instance et qu'il est responsable de certains paramètres SSH supplémentaires quelque part qui m'empêchent de me connecter en tant que "racine".

Il me semble que les directives de configuration ssh incriminées sont 'no-X11-forwarding' et les deux autres. Je suis arrivé à cette conclusion car ils semblent être associés au message incriminé.

J'imagine que la directive command demande au démon ssh d'afficher ce message lorsque les directives associées sont violées. Suis-je sur la bonne voie?

Une chose que je devrais ajouter à cela est que je suis au courant des arguments contre la connexion en tant qu'utilisateur root. Cependant, il s'agit d'une instance privée et je serai le seul utilisateur. J'ai besoin d'un accès ssh en tant que 'root' car mes scripts de déploiement doivent être exécutés en tant que root afin d'éviter toute complication.

Mise à jour: Le script python mentionné ci-dessous fait partie du paquet Ubuntu CloudInit .

Nouvelle mise à jour: Voici le contenu du fichier /etc/pam.d/sshd ...

# PAM configuration for the Secure Shell service

# Standard Un*x authentication.
@include common-auth

# Disallow non-root logins when /etc/nologin exists.
account    required     pam_nologin.so

# Uncomment and edit /etc/security/access.conf if you need to set complex
# access limits that are hard to express in sshd_config.
# account  required     pam_access.so

# Standard Un*x authorization.
@include common-account

# SELinux needs to be the first session rule.  This ensures that any
# lingering context has been cleared.  Without this it is possible that a
# module could execute code in the wrong domain.
session [success=ok ignore=ignore module_unknown=ignore default=bad]        pam_selinux.so close

# Set the loginuid process attribute.
session    required     pam_loginuid.so

# Create a new session keyring.
session    optional     pam_keyinit.so force revoke

# Standard Un*x session setup and teardown.
@include common-session

# Print the message of the day upon successful login.
# This includes a dynamically generated part from /run/motd.dynamic
# and a static (admin-editable) part from /etc/motd.
session    optional     pam_motd.so  motd=/run/motd.dynamic
session    optional     pam_motd.so noupdate

# Print the status of the user's mailbox upon successful login.
session    optional     pam_mail.so standard noenv # [1]

# Set up user limits from /etc/security/limits.conf.
session    required     pam_limits.so

# Read environment variables from /etc/environment and
# /etc/security/pam_env.conf.
session    required     pam_env.so # [1]
# In Debian 4.0 (etch), locale-related environment variables were moved to
# /etc/default/locale, so read that as well.
session    required     pam_env.so user_readenv=1 envfile=/etc/default/locale

# SELinux needs to intervene at login time to ensure that the process starts
# in the proper default security context.  Only sessions which are intended
# to run in the user's context should be run after this.
session [success=ok ignore=ignore module_unknown=ignore default=bad]        pam_selinux.so open

# Standard Un*x password updating.
@include common-password

... et le contenu du fichier/etc/ssh/sshd_config ...

# 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
HostKey /etc/ssh/ssh_Host_ed25519_key
#Privilege Separation is turned on for security
UsePrivilegeSeparation yes

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

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

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

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

...comme demandé.

sshconfigurationcloud
1
James Smith

Il est vivement recommandé de bloquer la connexion root à distance sur un serveur (raisons de sécurité).

La méthode recommandée consiste à vous connecter en tant qu'utilisateur régulier et à utiliser Sudo afin d'obtenir root.

La commande ultime Sudo qui vous fournit un accès complet à root pour chaque commande est la suivante:

Sudo bash

Pour une commande spécifique devant être exécutée sous la forme root, vous pouvez utiliser:

Sudo specific-command

Exemple pour une commande qui sera exécutée sous la forme root:

Sudo ls -lsa /root

Remarque: Si vous souhaitez modifier la stratégie Amazon et autoriser root login, vous utilisez les réponses de Amazon-ec2-root-login SO Q & A

Reportez-vous à ce qui suit pour définir le login root:

Sudo -s (to become root)
vi /root/.ssh/authorized_keys

Supprimez les lignes au début du fichier jusqu'à ce que vous obteniez les mots ssh-rsa.

vi /etc/ssh/sshd_config

Définissez la variable PermitRootLogin sur PermitRootLogin without-password (sans guillemets).

Sudo /etc/init.d/sshd restart
2
Yaron

Regardez le fichier /root/.ssh/authorized_keys. Très probablement, vous trouverez quelque chose comme ça:

root@instance-00:~# cat /root/.ssh/authorized_keys 
no-port-forwarding,no-agent-forwarding,no-X11-forwarding,command="echo 'Please login as the user \"ubuntu\" rather than the user \"root\".';echo;sleep 10" ssh-rsa AAAA...= user@Host

(Ceci a été pris à partir d'un fournisseur de cloud différent, mais la configuration semble être identique à celle d'Amazon).

Supprimez simplement tout ce qui se trouve devant ssh-rsa et vous devriez pouvoir vous connecter en tant que root à distance (bien entendu, tout ce que les autres utilisateurs vous ont déjà dit sur le fait que ce n'est pas une pratique exemplaire s'applique toujours!)

Si vous êtes vraiment paresseux, vous pouvez simplement écraser le fichier authorized_keys en utilisant celui de l'utilisateur ubuntu:

root@instance-00:~# cp /home/ubuntu/.ssh/authorized_keys /root/.ssh/authorized_keys

Et juste au cas où vous seriez curieux de savoir comment ce préfixe est arrivé là, le même code Python que vous avez déjà trouvé (/usr/lib/python3/dist-packages/cloudinit/config/cc_ssh.py) a la réponse dans apply_credentials. Notez comment cela définit le préfixe pour les clés autorisées:

if disable_root:
    if not user:
        user = "NONE"
    key_prefix = disable_root_opts.replace('$USER', user)
else:
    key_prefix = ''
2
Bogd