Whew. I solved the problem. It amounts to a config but within /etc/pam.d/vsftpd
Because ssh sessions succeeded while ftp sessions failed, I went to
/etc/pam.d/vsftpd, removed everything that was there and instead placed the contents of ./sshd to match the rules precisely. All worked!
By method of elimination, I found that the offending line was:
auth required pam_shells.so
Removing it allows me to proceed.
Tuns out, "pam_shells is a PAM module that only allows access to the system if the users shell is listed in /etc/shells." I looked there and sure enough, no bash, no nothing. This is a bug in vsftpd configuration in my opinion as nowhere in the documentation does it have you editing /etc/shells. Thus default installation and instructions do not work as stated.
I'll go find where I can submit the bug now.
Requirements for which I will offer solutions, as bullet points:
- Passwordless root console login
- Passwordless root remote login from pre-authorised users
- Passwordless remote login for specified accounts from pre-authorised users
- 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).
Best Answer
Thanks to two other SE posts (one on SO, one on SF), the answer lies in using advanced
control
syntax. Theshould therefore become
Now it is imperative that the
pam_ssh
line exactly precedes thepam_unix
one, sincesuccess=N
means to skipN
following module(s).Also, don't forget the
session pam_ssh.so
line while you're at it!In my first attempt, I used
instead, but this method locks out all users without SSH keys! Turns out that
default=ignore
isn't sufficient,auth_err=ignore
has to be added since that is apparently not considered part ofdefault
. Also, this attempt means there'll either be a "password" or "SSH passphrase" prompt depending on whether the user has an SSH key!Note that in Arch Linux, the
pam_unix
line used bylogin
lies in theinclude
chainand that
system-login
has some otherrequired
before includingsystem-auth
, so you cannot simply putauth [success=1 default=ignore] pam_ssh.so try_first_pass
in beforelogin
'sauth include system-local-login
- you'd skip the wrongrequired
and thanks to thepam_unix.so use_first_pass
(instead oftry_first_pass
) you could still only login with your login password! On the other hand, by modifyingsystem-auth
, you're also allowing other services such assshd
to use your SSH key as authentication option to the login password. If you truly want only yourlogin
to use this, you have to pretty much break theinclude
chain and manually copy allauth
s tologin
.