How can I log on as root to a cloud instance?

Question

I can log in successfully to my cloud instance as user 'ubuntu' via SSH but cannot log in as user 'root'. There are several posts extant concerned with altering the ssh config in order to allow root access although none have worked from me. For example, I have made the usual changes to the /etc/ssh/sshd_config file, namely:

#Authentication
PermitRootLogin yes

This had no effect.

Now, the message I get when I try to log in as 'root' is:

Please login as the user "ubuntu" rather than the user "root".

Grepping for "Please login", I found in the '/usr/lib/python3/dist-packages/cloudinit/config/cc_ssh.py' file (of all places), the following lines:

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\"")

I can't make much of this. I'm guessing that this Python script was run when the instance was first created and is responsible for some additional SSH settings somewhere that are blocking me from logging in as 'root'.

It seems to me that the offending ssh configuration directives are 'no-X11-forwarding' and the other two. I've come to this conclusion since they seem to be associated with the offending message.

I'm guessing that the command directive instructs the ssh daemon to show this message when the associated directives are violated. Am I on the right track?

One thing I should add to this is that I am aware of the arguments against logging in as root user. However, this is a private instance and I will be the only user. I need ssh access as 'root' because the deployment scripts I have need to run as root in order to avoid complications.

Update: The python script mentioned below is part of the Ubuntu CloudInit package.

Further update: Here are the contents of the /etc/pam.d/sshd file...

# 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

...and the contents of the /etc/ssh/sshd_config file...

# 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

...as requested.

Solution 1

Have a look at the /root/.ssh/authorized_keys file. Most likely you will find something like this:

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

(This was taken from a different cloud provider, but the configuration seems to be identical to Amazon's).

Just delete everything in front of ssh-rsa and you should be able to login as root remotely (of course, everything other people have already told you about this not being a best practice still applies!)

If you are really lazy, you can just overwrite the authorized_keys file using the one from the ubuntu user:

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

And just in case you are curious about how that prefix got there, the same Python code you have already found (/usr/lib/python3/dist-packages/cloudinit/config/cc_ssh.py) has the answer in apply_credentials. Note how it sets the prefix for the authorized keys:

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

Solution 2

It is highly recommended to block remote root login to a server (security reasons).

The recommended way is to login as regular user, and use sudo in order to gain root access.

The ultimate sudo command which will provides you full root access for every command is:

sudo bash

For a specific command which should be executed as root you can use:

sudo specific-command

Example for a command which will be executed as root:

sudo ls -lsa /root

---

Note: If you want to change amazon policy and permit root login, you use the answers from amazon-ec2-root-login SO Q&A

Refer to the following to set root login:

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

Delete the lines at the begining of the file until you get to the words ssh-rsa.

vi /etc/ssh/sshd_config

Set the variable PermitRootLogin to PermitRootLogin without-password (without quotes)

sudo /etc/init.d/sshd restart

Comments

[muru]

This is a problem with Amazon's VPS configuration, whatever that is, and should be raised with their customer support

[James Smith]

Please see the update. This is not an EC2 specific problem, it is a cloud related problem. The SSH settings appear to have been enforced by Ubuntu's own CloudInit package.

[muru]

Nominated for reopening. Please add the contents of sshd_config, /etc/pam.d/sshd to the post.

[James Smith]

That's a good idea. My next thought was whether another set of ssh settings were overriding the standard ones. I will add the additional information later when I have a moment.

[James Smith]

Hi. I'm aware of the arguments against root access, however it is (essentially) a private instance and I will be the only user. So I'm saying it's okay to be able to ssh in as root.

[Yaron]

@JamesSmith - updated my answer with a suggested way to allow root login to amazon ec2

[James Smith]

Okay, I had my doubts but gave it a go. There is no authorized_keys file for root presently so I couldn't do that step. I did change the sshd configuration as you suggested and restarted but it made no difference. I'm convinced something is overriding the sshd configuration, or at least taking precedence. That's why I grepped for (and at least partially uncovered the reason behind) the message.

[Yaron]

@JamesSmith - regarding the authorized_keys files, in order to login into a remote ssh server using keys, you should place authorized_keys files in the .ssh folder, which will include the public ssh keys of the users which can ssh into that account

[Yaron]

@JamesSmith - see this Q&A regarding ssh keys