11

I must admit that I like servers without passwords in some cases. A typical server is vulnerable to anyone who has physical access to it. So in some cases it is practical to lock it physically and since then trust any physical access.

Basic concepts

In theory, when I physically reach such a server, I should be able to perform administration tasks without password by simply typing root as the login and I shouldn't be asked for a password. The same may apply to user accounts but one would not really access them physically. Therefore no system passwords are needed for (occasional) local access.

When accessing the server remotely, either for administration, or for user account, I expect to always use an SSH private key. It is very easy to set up an SSH key for a just created account and thus no system passwords are needed for (regular) remote access.

# user=...
# 
# useradd -m "$user"
# sudo -i -u "$user"

$ keyurl=...
$
$ mkdir -p .ssh
$ curl -o .ssh/authorized_keys "$keyurl"

The conclusion is that, in theory, we wouldn't neeed any system passwords for use cases like that. So the question is, how do we configure the system and user accounts to make it happen in a consistent and secure way.

Local access details

How do we ensure the root account can be accessed locally without a password? I don't think we can use passwd -d as that will make root access too permissive and an unpriviliged user could switch to root for free, which is wrong. We cannot use passwd -l as it prevents us from logging in.

Note that local access is exclusively about access using the local keyboard. Therefore a valid solution must not allow any user switching (whether using su or sudo).

Remote access details

Until recently the above solution would work but now SSH started to check for locked user accounts. We cannot probably use passwd -d for the same reasons. We cannot use passwd -u as it just complains that it would lead to what passwd -d does.

There's a workaround with dummy password for this part.

user=...

echo -ne "$user:`pwgen 16`\n" | chpasswd

It might also be possible to turn off locked account checking in SSH entirely but it would be nicer to retain the support of locked accounts and just be able to unlock them.

Final notes

What I'm interested in is a solution that would allow you to log in to the root account locally and all accounts including root remotely, without any passwords. On the other hand, a solution must not impact security except in explicitly described ways, especially not by allowing remote users to get access to the root account or other users' account. The solution should be sufficiently robust so that it doesn't cause security issues indirectly.

An accepted and awarded answer may or may not describe detailed configuration of individual tools but must contain the key points to reach the stated goals. Note that this probably cannot be solved through conventional use of tools like passwd, ssh, su, sudo and the like.

More ideas after reading the first answers

Just an idea – the local root access could be achieved by starting root shells instead of login processes. But there's still the need to lock only password authentication, not public key authentication.

  • Use a customized PAM configuration for local access without password and do the same for sudo and SSH logons. – 0xC0000022L Mar 20 '15 at 22:55
4
+150

Requirements for which I will offer solutions, as bullet points:

  1. Passwordless root console login
  2. Passwordless root remote login from pre-authorised users
  3. Passwordless remote login for specified accounts from pre-authorised users
  4. Passwordless remote login for any account from pre-authorised users

The following examples are based on Debian, since that's what I've got here for testing. However, I see no reason why the principles cannot be applied to any distribution (or indeed any PAM-based *ix derivative).

Passwordless root console login

I think the way I would approach this would be to leverage PAM and the /etc/securetty configuration file.

As a pre-requisite, a "sufficiently secure" root password must be set. This is not required for console login but exists to make brute force cracking attempts unrealistic. The account is otherwise a perfectly normal root account.

In /etc/pam.d/login I have the following standard set of lines for authentication (those beginning with keyword auth):

auth       optional   pam_faildelay.so  delay=3000000
auth [success=ok new_authtok_reqd=ok ignore=ignore user_unknown=bad default=die] pam_securetty.so
auth       requisite  pam_nologin.so

@include common-auth
auth       optional   pam_group.so

The referenced common-auth include file contains the following relevant lines:

auth    [success=1 default=ignore]      pam_unix.so nullok_secure
auth    requisite                       pam_deny.so
auth    required                        pam_permit.so
auth    optional                        pam_cap.so

The common-auth file instructs PAM to skip one rule (the deny) if a "UNIX login" succeeds. Typically this means a match in /etc/shadow.

The auth ... pam_securetty.so line is configured to prevent root logins except on tty devices specified in /etc/securetty. (This file already includes all the console devices.)

By modifying this auth line slightly it is possible to define a rule that permits a root login without a password from a tty device specified in /etc/securetty. The success=ok parameter needs to be amended so that the ok is replaced by the number of auth lines to be skipped in the event of a successful match. In the situation shown here, that number is 3, which jumps down to the auth ... pam_permit.so line:

auth [success=3 new_authtok_reqd=ok ignore=ignore user_unknown=bad default=die] pam_securetty.so

Passwordless root remote login from pre-authorised users

This is a straightforward inclusion of ssh keys for those authorised users being added to the root authorized_keys file.

Passwordless remote login for specified accounts from pre-authorised users

This is also a straightforward inclusion of ssh keys for authorised users being added to the appropriate and corresponding user's .ssh/authorized_keys file. (The typical remote user chris wants passwordless login to local user chris scenario.)

Note that accounts can remain in the default locked state after creation (i.e. with just ! in the password field for /etc/shadow) but permit SSH key based login. This requires root to place the key in the new user's .ssh/authorized_keys file. What is not so obvious is that this approach is only available when UsePAM Yes is set in /etc/ssh/sshd_config. PAM differentiates ! as "account locked for password but other access methods may be permitted" and !... "account locked. Period." (If UsePAM No is set, then OpenSSH considers any presence of ! starting the password field to represent a locked account.)

Passwordless remote login for any account from pre-authorised users

It wasn't entirely clear to me whether you wanted this facility or not. Namely, certain authorised users would be able to ssh login without a password to any any every local account.

I cannot test this scenario but I believe this can be achieved with OpenSSH 5.9 or newer, which permits multiple authorized_keys files to be defined in /etc/ssh/sshd_config. Edit the configuration file to include a second file called /etc/ssh/authorized_keys. Add your selected authorised users' public keys to this file, ensuring permissions are such that it is owned by root and has write access only by root (0644).

  • I will have to examine #1 more carefully and test it. It looks very interesting, even though it still requires a (strong) password configured. The #3 isn't complete as nowadays a newly created user is locked by default also from SSH login. I didn't really ask for point #4 but it looks very interesting anyway and I might have a use for such method, actually. – Pavel Šimerda Mar 22 '15 at 0:24
  • The strong password for root is required but never used. I assumed you knew how to implement #3; let me know if you need more detail. On (Debian) systems it is possible to ssh in to a new account that has not yet had a password defined, provided that the .ssh/authorized_keys file contains the relevant public key. Does this help? – roaima Mar 22 '15 at 0:31
  • I think I need a nice and standard way to recover the behavior that you see on Debian, i.e. that a newly created account is only locked for password authentication and not for public key one. – Pavel Šimerda Mar 22 '15 at 0:33
  • For the test user account I created to confirm the ssh statement in my previous comment, I see a single ! in the password field in /etc/shadow. According to the man page this indicates a valid account for which no password can match. – roaima Mar 22 '15 at 0:36
  • 1
    That's interesting, that is really not so obvious at the least, thanks. – Pavel Šimerda Mar 30 '15 at 19:57
1

It sounds like you want real (non-root) user accounts with ssh keys and full NOPASSWD access via sudo (which is available by default in most Linux distros these days and is also trivial to install manually). You can have blank passwords for each user account (which won't work remotely), then the user either runs sudo -s or the user's ~/.bash_profile merely contains that command.

Sudo

Add each user to the sudo UNIX group (e.g. usermod -a -G sudo USERNAME, though older systems will have less intuitive ways of doing this; worst case, you edit /etc/groups directly).

In /etc/sudoers or /etc/sudoers.d/local, you want a line like this:

%sudo    ALL=(ALL:ALL) NOPASSWD: ALL

If you want automatic root access, add this to the user's profile. For bash, that would be ~/.bash_profile:

sudo -s

This will allow you to see who is logged in (try who or last) and will leave logs in /var/log/auth.log.

Passwordless login

On much older systems, you could just edit /etc/passwd (or on slightly older systems, /etc/shadow) and remove the hash, so e.g. bob:$1$salt$hash:12345:0:99999:7::: becomes just bob::12345:0:99999:7:::. This was all you needed. Modern systems don't like this. There are likely other ways to do this, but the way I've just verified is as follows (source: Leo's Random Stuff):

Open /etc/shadow and observe an account with real information. This will include three elements delimited by dollar signs ($). These represent the hashing mechanism, then the salt, then the hash. Note the salt, then run this:

openssl passwd -1 -salt SALT

(This uses MD5 as the hashing mechanism. It's a blank password, so you shouldn't mind.) When prompted for a password, hit enter. Save that string, including any trailing dots, and paste it after the first colon on that user's line in /etc/shadow (this should replace any pre-existing content between the first and second colons). (Please don't literally use SALT as your salt!)

SSH

Your ssh daemon configuration lives either in /etc/sshd_config or /etc/ssh/sshd_config. For proper security, I recommend it include these lines:

PermitRootLogin no
PermitEmptyPasswords no

See the Secure Secure Shell writeup for additional security measures you can add to your ssh configuration to better harden it against sophisticated attackers.

Now your users cannot log in via ssh due to having empty passwords (this is a necessary security measure). This means they can only log in with ssh keys.

Each user, for each of their client systems, should create an ssh key pair, e.g.

ssh-keygen -t rsa -b 4096 -f $HOME/.ssh/id_rsa -o -a 100 -C "Bob Roberts on his laptop"

This produces a private key at $HOME/.ssh/id_rsa and a public key at $HOME/.ssh/id_rsa.pub. Have that user send you their public keys and append them to this server's $HOME/.ssh/authorized_keys (note that each user's $HOME/.ssh must be mode 700, e.g. mkdir -p ~user/.ssh && chmod 700 ~user/.ssh).

Users who do not want ssh keys can be walked over to the physical system. There, their blank password will log them in, at which point they can type passwd from the shell and set a password, thus allowing them remote access.

(I actually used this technique to give people access to a collection of systems back when I ran an IT department. It forced users to use ssh keys and I didn't have to give them passwords. Their initial ~/.bash_profile had two lines at the bottom: passwd and then mv ~/.bash_profile.real ~/.bash_profile so that they set a new password upon first login.)

Risks

You are placing full trust in your users. There's nothing stopping a user from messing with another user's ~/.ssh/authorized_keys file and thus altering your ability to revoke and audit access, but this is unavoidable if you're giving out full root access.

Conclusion

Each user is now a member of the sudo group and have full passwordless access to a root shell. These users have no passwords for their accounts and can log in remotely using ssh keys.

If you lose one of your employees, you can remove his/her account. If one of your employees' laptops is stolen, you can remove that laptop's ssh key from that user's authorized_keys file. If you have a security breach, you have logs showing who logged in.

  • The part about sudo misses the question as it was exclusively about new logins, not switching users. Amended the question to make it clearer. The part about passwordless login exhibits the exact same wrong behavior as passwd -d in the question, allowing su to switch to that user without password. The risks section describes two things (messing with other users' data and getting root access) whose removal is the very point of the question. Therefore, while individual sections are nicely written, this is by no means an answer to the question. – Pavel Šimerda Mar 20 '15 at 22:26
  • I assumed you'd add the user and then restrict the user. – Adam Katz Jul 22 '15 at 23:08

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.