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.
Best Answer
Requirements for which I will offer solutions, as bullet points:
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 keywordauth
):The referenced
common-auth
include file contains the following relevant lines: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
. Thesuccess=ok
parameter needs to be amended so that theok
is replaced by the number ofauth
lines to be skipped in the event of a successful match. In the situation shown here, that number is3
, which jumps down to theauth ... pam_permit.so
line: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 whenUsePAM 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." (IfUsePAM 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).