Can you give a user account multiple passwords?

Yes, although quite uncommon, this is definitely doable.

Instead of trying to implement it yourself as the default /etc/password /etc/shadow based authentication method has no provision for such a configuration, the simpler way is to delegate authentication to a back-end that already supports multiple password for a user.

A well known one is LDAP which userPassword attribute is multivalued according to RFC4519:

An example of a need for multiple values in the 'userPassword' attribute is an environment where every month the user is expected to use a different password generated by some automated system. During transitional periods, like the last and first day of the periods, it may be necessary to allow two passwords for the two consecutive periods to be valid in the system.

Despite this RFC, you'll likely need to change the password policy configuration on most directory server implementations for this setting to be actually accepted.

On the Linux side, nothing forbids to do it (here an account named testuser was given both pass1 and pass2 as userPassword attribute values):

$ uname -a
Linux lx-vb 3.8.0-19-generic #29-Ubuntu SMP Wed Apr 17 18:16:28 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
$ grep VERSION /etc/os-release
VERSION="13.04, Raring Ringtail"
$ grep "^passwd" /etc/nsswitch.conf 
passwd: files ldap
$ ldapsearch -LLL -h localhost -p 1389 -D "cn=directory manager" -w xxxxxxxx "uid=testuser" userPassword
dn: uid=testuser,ou=People,dc=example,dc=com
userPassword:: e1NTSEF9b2JWYXFDcjhNQmNJVXZXVHMzbE40SFlReStldC9XNFZ0NU4yRmc9PQ==
userPassword:: e1NTSEF9eDlnRGZ5b0NhKzNROTIzOTFha1NiR2VTMFJabjNKSWYyNkN3cUE9PQ==
$ grep testuser /etc/passwd
$ getent passwd testuser
testuser:*:12345:12345:ldap test user:/home/testuser:/bin/sh
$ sshpass -p pass1 ssh testuser@localhost id
uid=12345(testuser) gid=12345 groups=12345
$ sshpass -p pass2 ssh testuser@localhost id
uid=12345(testuser) gid=12345 groups=12345
$ sshpass -p pass3 ssh testuser@localhost id
Permission denied, please try again.

Here are some technical and security related implications of that kind of configuration:

• the user account will obviously be more vulnerable to attacks although what really matters here is the quality and protection of the passwords more than their numbers.
• most utilities assume the user has a single password so won't allow a user to individually update one of the passwords. Password change will then likely result in a single password attribute for the user.
• if the goal is to allow multiple people to share the same account using each one their own password, there is no mechanism to identify who actually log in based on the password used.

I just attempted to create 2 entries for a user in the /etc/shadow file and it did not work. Which ever entry was first was the password entry that was used.

Example

Created a test user.

$ useradd -d /home/newuser newuser

Set the password to "super123":

$ passwd newuser

Manually edit the /etc/shadow file and made a second entry:

newuser:$6$....password #1...:15963:0:99999:7:::
newuser:$6$....password #2...:15963:0:99999:7:::

Then attempt to login with the account using the 2 passwords.

su - newuser

The first entry in /etc/shadow is what get's used, the entry in the second position never works, if you flip these like so:

newuser:$6$....password #2...:15963:0:99999:7:::
newuser:$6$....password #1...:15963:0:99999:7:::

Then the second password works and the first one doesn't.

Use sudo

This approach is a total hack, I would just use sudo, it's partially why sudo exists.

You can add this entry to your sudoers file (/etc/sudoers) which would allow user joe permission to do anything as you:

joe ALL=(yourusername) ALL

If you can do this, you probably shouldn't.

PAM configuration is somewhat complex and there is one truism about authentication mechanisms: there are a finite set of correct configurations but an infinite set of insecure configurations. This makes it almost a certainty that if you try to change things and don't know precisely what you are doing you'll screw things up.

If the choice is between security and "convenient in some specific situations", opt for the former.