I'm new to Linux so keep that in mind when offering advice.

I became over zealous and ran the command here:


useradd -ou 0 -g 0 john
passwd john

now I try to connect the way I usually do:

ssh -i yok.pem root@staging.yok.com -vv

and I'm getting:

debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 21: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to staging.yok.com [] port 22.
debug1: Connection established.
debug1: key_load_public: No such file or directory
debug1: identity file yok.pem type -1
debug1: key_load_public: No such file or directory
debug1: identity file yok.pem-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.9

I luckily still have one connection to the server open. I checked my ~/.ssh folder and the files all have 600 permissions.

What do I need to do here? I'm stuck.

  • 1
    Heh, sshd is struggling to figure out whether root owns the file or john owns the file. If you are trying to harden your machine using something like AllowRootLogin no in /etc/ssh/sshd_config is much more effective than creating a different root account. You will not be able to get rid of a user called root, it would break too many things. Kill the user john (with userdel). there are pretty much no security gains from a second UID 0 user
    – grochmal
    Jul 14 '16 at 18:03
  • 2
    @hamobi identity file yok.pem type -1 looks suspicious. are you sure this is the private key?
    – murphy
    Jul 14 '16 at 18:16
  • It is very bad idea to even allow to log in as root via ssh; instead, it is common practice to block it. You should better use an unprivileged user to log in via ssh, and then use sudo or su -l to gain the privileges, if you need. By the way, OpenSSH uses it's own configuration, and doesn't adhere to the local password database.
    – Andrew
    Jul 14 '16 at 18:51
  • 2
    “USER with ROOT Privileges” is a very misleading title. This doesn't create a user with root privileges, it creates another way for the root user to log in. A user account is defined by the user ID, not by the user name. The only account with root privileges is root, even if you give it other names. Changing the user ID of an existing account is bound to cause problems (the user's files won't belong to the user anymore) which that article doesn't even mention. Throw this site away as far as you can and don't look back. Jul 14 '16 at 23:15
  • The problem most likely happened because john had a different home directory than root. sshd then used john's home directory (because it has same uid as root. AFAIK, which passwd entry to use in case of duplicate uids is undefined, so you can't rely on any one being chosen) instead of root's when root tried to log in. with no ~john/.ssh/authorized_keys, your keys won't work.
    – cas
    Jul 15 '16 at 2:48

Wow okay well have you considered just removing the user?

userdel john

As others have mentioned login as root over ssh is ill advised and so is having duplicate uid's of 0.

  • Login as root over SSH is not strongly ill-advised (it's actually rather harmless on a single-user machine). Having duplicate user entries with the same UID isn't necessarily ill-advised, but the implications are subtle and you shouldn't do it if you don't understand them. Jul 14 '16 at 23:20
  • If you look at the Mozilla Guidlines for securing SSH Gilles you will notice PermitRootLogin No and the explanation as to why it's not advised. You should be using a regular user for ssh then su or sudo up to root. wiki.mozilla.org/Security/Guidelines/… Jul 14 '16 at 23:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.