Password Security – Easiest Way to Synchronize ‘pass’ Password Store

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).

First of all, I'd consider "editing" a passphrase replacing the value for a site by another one, not regarding the old passphrase at all (which would include a read operation). pass stores the site's URL in the file name in plain text, thus does not require any cryptographic operations for finding/"lookup" of the encrypted content at all.

If you only want to add, edit and delete passwords, you only need the public key, to be specific for the add and edit operations which encrypt the passphrase using the public key; in fact deleting does not imply any cryptographic operations at all.

On the other hand, for reading any passphrase, you will need to provide the private key, which is required to decrypt the passphrase.