63

The second field in the Linux /etc/shadow file represents a password. However, what we have seen is that:

  1. Some of the password fields may have a single exclamation 

    <account>:!:.....

  2. Some of the password fields may have a double exclamation 

    <account>:!!:.....

  3. Some of the password fields may have an asterisk sign

    <account>:*:.....

By some research on internet and through this thread, I can understand that * means password never established, ! means locked.

Can someone explain what does double exclamation (!!) mean? and how is it different from (!)?

Rui F Ribeiro
  • 55,929
  • 26
  • 146
  • 227
JavaTec
  • 797
  • 2
  • 8
  • 11
  • Which distribution are you using? – muru Dec 28 '15 at 23:08
  • Hi Muru, am new to Unix and trying to create a script which will run on RHEL 6.6 and HP-UX B.11.23 – JavaTec Dec 28 '15 at 23:35
  • 3
    "By convention, accounts that are not intended to be logged in to (e.g. bin, daemon, sshd) only contain a single asterisk in the password field. Note that there is nothing special about ‘*’, it is just one of many characters that cannot occur in a valid encrypted password (see crypt(3))." --[OpenBSD man page for passwd(5)](http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man5/master.passwd.5?query=passwd&sec=5). I would expect ! or !! to be no different, technically, regarding whether it is a valid passwd file, or regarding logins. However, some tools might have special support. – TOOGAM Dec 29 '15 at 01:45
  • 2
    Don't use the BSDs' doco as references for this. Their accounts database handles things differently and does not even have an `/etc/shadow` file. [Don't put answers into comments](http://meta.stackexchange.com/questions/17447/), either. ☺ – JdeBP Dec 29 '15 at 08:17

2 Answers2

47

Both "!" and "!!" being present in the password field mean it is not possible to login to the account using a password.

As it can be read from the documentation of RHEL-4, the "!!" in the shadow-password field means the account of a user has been created, but not yet given a password. The documentation states (possibly erroneously) that until being given an initial password by a sysadmin, it is locked by default.

However, as others have noted, and as the man pages indicate for later versions of RHEL-7, it is possible a user may still log on to the account through other means, such as via SSH using public/private key authentication.

Otheus
  • 5,945
  • 1
  • 22
  • 53
Rui F Ribeiro
  • 55,929
  • 26
  • 146
  • 227
  • 7
    This maybe true on Red Hat systems, but not necessarily elsewhere - on Ubuntu or Arch Linux, a newly-created account with no password still has only `!`, not `!!`. – muru Dec 28 '15 at 23:06
  • 2
    True indeed that I have never seen a "!!" in a Debian system. I would guess the OP is using some RH-based system, or SuSE. – Rui F Ribeiro Dec 28 '15 at 23:09
  • Thank you for your quick answers, would the above explanation provided by Rui - hold good for an hp-ux as well? – JavaTec Dec 28 '15 at 23:50
  • 4
    @JavaTec Not necessarily: I think all unices that have a `/etc/shadow` have the same field but how the password field stores non-password information varies. Check the HP-UX documentation, starting with the `shadow` man page. – Gilles 'SO- stop being evil' Dec 28 '15 at 23:57
  • Indeed it can vary by Unix versions and even in the same variant by command eg. adduser vs usermod and others. – Rui F Ribeiro Dec 29 '15 at 00:02
  • 2
    HP-UX did not even have `/etc/shadow` until relatively recently: before HP-UX 11.11, the options were either classic shadowless `/etc/passwd` or "Trusted Computing Base", that stored each user's password hashes and other account information in individual files named `/tcb/files/auth//`, readable only by root. In HP-UX 11.11, `/etc/shadow` was introduced as an [optional extra](https://h20392.www2.hpe.com/portal/swdepot/displayProductInfo.do?productNumber=ShadowPassword), in 11.23 it was an option in the base OS, and in 11.31 the TCB was finally deprecated. – telcoM Jan 21 '19 at 21:32
  • 5
    It is worth noting that an account is not actually locked in this way, it only means the user cannot use a password to authenticate and probably cannot set a password. I have tested this on both Debian and EL based distributions: login with ssh key still works with either "!" or "!!" in the password field. – Roy Oct 04 '19 at 19:40
  • @Roy What you note is partially true. If `sshd` is configured for password based authentication (`PasswordAuthentication Yes`) **OR** challenge response authentication (`ChallengeResponseAuthentication yes`), then `sshd` considers the accounts with `!!` in the 2nd field of `/etc/shadow` locked. – Samveen May 12 '22 at 08:54
  • The `!!` have probably less magic than thought. With Ansible e.g., if the user is created with a `!` in the password field and the `password_lock` field set to `yes` it puts a `!` in front of the existing password thus rendering it `!!`. So maybe it comes from some tool not doing it correctly... – Holger Böhnke Sep 18 '22 at 19:13
  • @HolgerBöhnke Maybe it comes to a tool, maybe changes over the years. This answer is from 2015. – Rui F Ribeiro Oct 13 '22 at 17:33
  • The answer does not clarify `*` – Valerio Bozz May 04 '23 at 13:46
11

It may also be worth noting <account>::..... meaning that there is no password required (empty password).

If you are creating an ssh key-only user you could use <account>::0:0:99999:7::: to require that the user set their password (i.e. that they use for sudo) on their first login.

Note: key-only authentication means that a password is NOT an authentication factor.

coolaj86
  • 455
  • 4
  • 8
  • 13
    Beware of this. An empty field means there is no password, and you just have to press ENTER to login, at least in the console. – Rui F Ribeiro May 04 '17 at 12:28
  • 1
    From `man shadow` regarding encrypted password field: "This field may be empty, in which case no passwords are required to authenticate as the specified login name." <-- Leaving this field emtpy results in open account and this should indeed be avoided! – Laas Oct 15 '19 at 12:48
  • Note that many SSH implementations block login on null passworded accounts by default: `sudo /usr/sbin/sshd -T| grep empty` would return: "permitemptypasswords no" – Brian Huntley Nov 04 '19 at 15:58
  • Changed the answer to clarify that I meant key-only login. – coolaj86 Apr 13 '20 at 01:26
  • Another note, why one should never use empty passwords. Think about what happens if you install any software that uses "linux-authentication"? E.g. phpMyAdmin would than allow logins without a password. This can be very dangerous. And key only users should have "!" – K. Frank Nov 03 '20 at 06:12