122 comment

    1. Not entirely correct. Sure, if password is disabled then a normal user could not use that user but root absolutely could and so could anyone with unrestricted access to sudo (so they can use whatever command via sudo). The same goes for shell being set to (for example) /sbin/nologin

      Incidentally, ! means the password is locked. Furthermore, the entry CAN be empty and yes that means that unless the program in question denies it (because it is empty) you can indeed log in without a password.

  1. If a user changes his password (using passwd command), how is the shadow file updated to include the new passwd? I mean, doesn’t the root/admin only have write permissions to this file?

  2. passwd command has SUID (Saved User ID) enabled. When passwd command executed the effective user id (EUID) that is in force at the time is copied to the saved user id (i.e. root). Using this technique a normal user can update his/her password.

  3. username:!!: …. or
    username:!!$1$MvGJq5Nq$ersjw/IaU90l.n5sB/FFP1: …

    I tried this on Linux machine and !! appeared after passwd -l username command – locking password.
    After passwd -u username – unlock, !! disappeared again.
    So this means that user cannot log in, so it is blocked, but I am not sure about all those rpm, nscd, nfsnobody and so on users.. they have only :!!: in password field in ect/shadow file. These users cannot log in, but are they entirely blocked?

    1. They are not entirely blocked and they can be logged in to. They also don’t need to be there (well, some don’t). Example logins that don’t have to be there: halt, shutdown, reboot

      On the other hand, be careful: nobody IS necessary (if not in all cases then certainly some and you’ll want to be careful; even if no file is owned by that user that doesn’t mean it isn’t used and that rule applies to other users too), for example.

      And password locked does not mean you cannot log in to them and same goes for an invalid shell. Just as a caution there. It only means you can’t in a normal way. You can however still log in as (them).

  4. The root user can still access accounts with blocked passwords, using su, but only if those accounts have a shell enabled in /etc/passwd (if the shell is /sbin/nologin, even root cannot access the account). I don’t know if there’s a difference between !! and * in the password field of the shadow file, though.

    1. That is not true and while I certainly cannot say with 100% certainty that I remember in 2007, I am pretty sure I am remembering right: it was never true that you could not use it with an invalid shell.

      # su – user -s /bin/bash
      would log in to user with shell /bin/bash even if the shell is normally something else.

      and: ! = locked password.

    1. the passwd command executes with root permissions since it is a setuid program. root owned processes can access the shadow file… they essentially are not effected by the file permissions.

    1. Potentially, it can work. if there is another authentication directory other than “files” (/etc/passwd) specified in nsswitch, it can get the user info from that authentication directory, and the password info from /etc/shadow

  5. @sunil

    heya mate. the passwd command can only be run by root or as a root (using sudo). The root can access (including read and write) to any file even if he doesnt have the permissions. Thats why as a root, the /etc/shadow can be changed.

    You can call it perks of the job…

    HTH

  6. Hey guys,

    Can you please tell me if

    1. \”!!\” means that the password is expired and the user will not be able to login?

    2. \”*\” means that the userid is locked?

    1. Other way around. ! = locked. See shadow(5) for more information on the fields. And I promise this is the last one about this issue (did not mean to get carried away….).

      And to those who don’t know what shadow(5) means it means section 5 of the man pages. You can check by:
      $ man -s 5 shadow
      $ man 5 shadow
      (the former is for some other systems but still works for Linux man-pages)

  7. the passd command is both SUID and SGID — these stand for Set User ID and Set Group ID. See permissions below;
    % ls -l /usr/bin/passwd
    54 -r-sr-sr-x 1 root sys 27228 Aug 16 2007 /usr/bin/passwd

    Just to clarify the perms —
    * user perms (root) – read, setuid on execute
    * group perms (sys) – read, setgid on execute
    * anyone perms – read and execute

    So, when anyone runs the passwd command, they will effectively be running it as the root user and the sys group.

    Although the permissions of passwd are read (no write), root does have the ability to force write on any file on a UNIX system (locally mounted).

    That is why when you run the passwd command, you effectively become root and the shadow file is updated.

    Hope that helps.

    1. Actually, it IS saved set-user id. The system call setuid (and seteuid for effective user id equivalent) saves and sets the ids. There’s group equivalents too.

      More specifically, it saves the id and can be restored (depending on permissions). However, when it is +x suid then it means that it will then set user id. So there is a slight subtlety there but yes, that is the idea. If x is replaced with s then it is suid/guid execute.

      I should point out that suid (as you word it: you effectively become root) has always been risky and is the source of many rooted boxes over the years (buffer overflow, …). Hence why if you don’t need users to be able to use a specific command then you can make it not suid (but be careful of course.. it would be naive to think that you can do that – or anything! – blindly). traditionally ping is an example (why ? raw sockets for icmp).

      But yes, this is the idea and that is how it is possible. Mind you, if root opens a file in read only mode of, say, vi, you can save it but not by the normal way (you have to override the read-only). But in the end root has access to write even if it doesn’t. Well okay, if the mount is read-only or the disk is read-only (remember the floppy disk locks ?… nostalgia… is dangerous…) then that is different, but… with exception of finalised cd/dvd, you can get around the others.

  8. username:Kz5iZvRZAyXkQ:14132::::90::

    I use the passwd -x -1 [username] command to remove the expirations, etc., but that 90 keeps showing up. How the hell do I get rid of that damn number short of vi’ing the shadow file?

  9. Does anyone know how to set a madatory minimum length for the root password. I typed in PASSWORD=14 in the ../etc/default/passwd file, but that only ALLOWS a 14 charachter password. It doesn’t require it.

    Thanks,
    David

  10. “/etc/shadow file stores actual password in encrypted format”

    I don’t think so, I’m pretty sure that /etc/shadow stores a hashed output from the users password, by default using ‘crypt’ in solaris and therefore limited to checking the first 8 chars of a password. You can invoke MD5 or SHA-1 instead, for better password checking. /etc/default/passwd contains the hints…..

  11. Is it possible to add an root entry to the /etc/passwd and /etc/shadow where there is no password, so that we can create a root that doesn’t have a password? thanks for the help

    1. edit /etc/shadow and remove the encrypted password.
      vi /a/etc/shadow
      An example from my lab looks like this.
      root:ZW1NcbJpB8Yd6:14712:7:42:7:::
      You will need to remove the section between the first colons. In this case ZW1NcbJpB8Yd6.
      The new line should look like this.
      root::14712:7:42:7:::

  12. If I insert # comment lines, blank lines, or if I sort the contents differently, will this screw anything up? Will the system clobber comments, blank lines, or sort order? I could get the answer by experiment, but the risk of disaster is too high.

  13. “if the shell is /sbin/nologin, even root cannot access the account”
    False. Both su and sudo let you specify a shell/command, so you (not just root) can bypass what /etc/passwd says. The shell value there is only a default shell! It does NOT entirely prevent someone from logging in (very common myth)! In other words, if you have access to an account with su or sudo, you can log in to it regardless of what the default shell is set to. I do it all the time.
    While it WOULD lock someone out of telnet, SSH2 allows you to specify an alternate shell to bypass /etc/passwd as well (although I’ve not had any success using this feature of SSH, so perhaps I’m misreading or not getting it right).

    1. Am I getting something different than Keilaron has said. I guess statement is true.
      “if the shell is /sbin/nologin, even root cannot access the account”

      [[email protected] ~]# cat /etc/passwd | grep -i shridhar
      shridhar:x:504:510:shridhar:/bin/bash
      [[email protected] ~]# usermod -s /sbin/nologin shridhar
      [[email protected] ~]#
      [[email protected] ~]# su shridhar
      This account is currently not available.
      [[email protected] ~]# su – shridhar
      This account is currently not available.
      [[email protected] ~]#

      1. [[email protected] ~]# cat /etc/passwd | grep -i shridhar
        shridhar:x:504:510:shridhar:/home/shridhar:/sbin/nologin
        [[email protected] ~]# date
        Wed May 28 17:07:58 IST 2014
        [[email protected] ~]#

        1. [[email protected] ~]# tail -1 /etc/passwd
          nfsnobody:x:65534:65534:Anonymous NFS User:/var/lib/nfs:/sbin/nologin
          [[email protected] ~]# su nfsnobody -s /bin/bash
          bash-4.2$ whoami
          nfsnobody
          bash-4.2$

  14. i am a student and i m new in linux ..can anyone please explain me the term dns resolver by taking into account:
    1.how it might be used to resolve the url:breo.beds.ac.uk
    2.how it compares with the hosts file

    1. unix looks to /etc/hosts file as first point of name resolution. than /etc/resolv.conf is looked at where DNS server ip addresses are identified. The DNS server retains a database similiar to that of the /etc/hosts file. DNS server database has to be maintained with server names and ip addresses rather than system adminsitrator maintaining hundreds of /etc/hosts files on multiple machines.

  15. can anyone xplain: what happening in the boxes areas shown in the startup script of a linux system:-

    checking for hardware changes [ok]
    bringing up loopback interface:[ok]
    bringing up loopback interface eth0:
    determining ip information for etho… done

    starting snmpd:[failed]
    starting cups[ok]
    starting sshd:[failed]
    starting sendmail:[failed]

  16. can u explain how the /etc/shadow and /etc/passwd are used in the authentication process.why are two files used instead of one?how can i convert a system to use the /etc/shadow file to store password?

  17. an example of absolute pathname is shown as /home/student/myprogms while a relative pathname can be shown as ../../documents can anyone discuss the differences between absolute and relative pathname and advantages.

  18. Heyy

    can anyone tell me what is the hash here?

    username:$1$DKzYQ$HP9PrZA.mxe5/qviB3Kyw1:14266:0:99999:7:::

    i tried to crack it with md5 but it says it’s not a valid hash. I tried different combinations but it’s the same thing.

    Please help.
    Thanks.

  19. Hey Kriss,

    you can’t just crack md5, since md5 is actually a cryptographic hash function and it operates only ONE way: text -> hash!

    You might try the common words md5 database. Type “gdata md5 database” in your favourite search engine.
    If you are (un)lucky this hash will be found in the database, and you will be able to see clear text.

  20. @manish bagwari:
    Shadow file can only be opened by a super user (already mentioned in Keilaron comment). So sudo vi /etc/shadow (and enter password, if your username is added to sudoers), or first become super user with use of the su command (must know root password), and then open the file via vi /etc/shadow.

    Mod (%) in korn shell can be used in following way: mymodulus=$(( 15 % 7 ))
    If you meant something else by “unix”, please let me know.

  21. Well, without correct super user password, you can NOT read requested file!
    If you truly are authorised to use the system in super user mode, someone should have provided you with the password; or created rules in sudoers configuration file.

    If you installed the system by your self, and just forgot the password, you will probably have to boot it using rescue CD and then reset super user password. This procedure is well documented on the web.

  22. how to know the root password in unix sir when i used su command then it display athentication failure (in my own system ) siir what to do?

  23. I had a problem with the screensaver under Ubuntu 9.10 not taking my password. I fixed it by changing the permissions of /etc/shadow to:
    -r--r----- 1 root shadow 1807 2010-03-26 00:33 /etc/shadow

  24. In the figure the encrypted password is really shot when compared with the password field in my shadow password i cant really understand what is the type of encryption

    hackme:$6$OBEzW/iiKRe/ww$vfnfEFg41l1dK4zE4YM9PiRKs7ic5lvg1WgFWgi.VF0O/MYCZPELqedCmSybFQ5.0twYbc1fU6VnXqdACqELj0:14703:0:99999:7:::

    can anyone pls help me understand this

    cheers.
    Linux learner

  25. From my password field i can identify $6$ which indicates it as a SHA based scheme but when i converted my original password using some online converters i didn’t got the same encrypted password as that of my shadow password

  26. Tatineni: There’s some additional modifications that occur to the password before it is placed in the shadow file. I’m not sure what they are, but yes, it seems the hashes created by md5/sha1/ are not inserted as-is into the shadow file. I’m not sure what it is, but it’s not base64 encoding, that much I know.

  27. why /etc/shadow- and /etc/passwd- file ?

    # ls -l /etc/passwd*
    -rw-r–r– 1 root root 2230 2007-08-17 19:20 /etc/passwd
    -rw-r–r– 1 root root 2187 2007-08-17 15:03 /etc/passwd-

    # ls -l /etc/shadow*
    -r——– 1 root root 1420 2010-02-07 03:30 /etc/shadow
    -r——– 1 root root 1358 2007-08-17 15:03 /etc/shadow-

  28. Link.

    It turns out that a “salt” is used to make the hash. This ‘salt’ is a random string which is different every time a password is generated.
    When you look at the hash in your passwd file it has the following scheme:
    $*1$*2$*3

    *1 is an integer showing the hash type used (1=md5, according to one of the replies 6=SHA)
    *2 is the salt
    *3 is the hashed password (with the used salt)

    according to the link the following command will output the correct hash:
    openssl passwd -1 -salt *2
    (the -1 is for md5, not sure how to use this with other hash types)
    —–

    To be clear on hash versus encryption:
    A hash is one way. With hashes it is not unlikely that two different inputs lead to the same hash, therefore it is impossible to retrieve a password from a hash. A good hash algorithm makes it unlikely to find 2 different inputs for the same hash. One could say that on creation of the hash some information needed to reverse the process is removed and can not be recovered.

    With encryption it is two way. You will need some kind of key to decrypt (most likely a hashed password), but this key will always result in one way to the unencrypted state (ie input). In other words all information to decrypt is still available.
    —-
    For a root password reset have a look at (you will need physical access to the box):
    Link.

  29. The “Last password change” field for some users are 0 or around 6000 days or some are even blank. However, for all the above users, the “Max” field is 28 days.
    Can anyone pls explain how this is possible? Thx

  30. I’m trying to unshadow my passwd file on mac os x 10.6.7 (MBP if it helps) I can’t seem to locate the shadow file in etc/ can you help me? I’m trying to do this for use with john the ripper to test the passwords on my server, and I am new to john the ripper.

    1. There are no /etc/shadow file on Mac OS X. All passwords are stored by a daemon (DirectoryService if i’m remember correctly) which store passwords in many hashed kinds (MD5, CRYPT-DES, SHA, LM, KRB5, …) for all services who need it. All request for changing password are redirected to this daemon who update all hashes “in-the-fly”. Same thing for authentication

  31. Hi…can any one tell me…is there any procedure or any scriprt or tool through which i can change the password setting..i mean when i type the password in linux nthng displayed,is there any way to change it with * symbol…so next tym instead of nthyng i will get ******** like this form….thnx in advance…

    1. With this instance you need to break the encription layer before we can proceed to the inquiries you like. Then it time we can formulate that kind of scripting code and it depends to the one you like systems.

  32. Hi

    Can anybody tell me how to calculate the date the password has been change. I mean how to get the actual password change date.

    root:ZW1NcbJpB8Yd6:14712:

    according to this log password has been change on 14712- but how do i know which date, which month and which year password changed.

    Thank you

    1. Dileepa, (November 17, 2011)

      On linux you can use the date command to convert the EPOCH days to the date.
      The time reported back is not valid, since I am using a full day for seconds.

      date -d @`echo 14712*86400|bc`
      Mon Apr 12 20:00:00 EDT 2010

    1. Necroposting but you never know..

      You can use mkpasswd available with the package whois from debian-ubuntu repos.
      Assuming your os is using sha-512 ($6 for first parameter)
      mkpasswd -m sha-512 [your-cleartext-password-here] -S [salt-goes-here]

      example:
      the hashed password stored in /etc/shadow is:
      jim:$6$dFEoBUGm$UbApZifMythaHenyovweashBysevligAffIcicdirEdgeJiatsetDoldikbintufgufPavhofdoljabPyWrak1:13297:0:99999:7:::

      if your run

      mkpasswd -m sha-512 greendog -S dFEoBUGm

      and user’s password is indeed greendog, you should get the /etc/shadow hash, i.e

      $6$dFEoBUGm$UbApZifMythaHenyovweashBysevligAffIcicdirEdgeJiatsetDoldikbintufgufPavhofdoljabPyWrak1

      ps: strings are random

  33. Hi All,

    while you are trying to change password for any user logged in with root user. And if you get error saying “Permission Denied”. Then you just need to edit /etc/shadow file and clear the password. If in the password section you find *LK* then you just delete them and re-try changing password. It shouldb be fine.

    Cheers

  34. my acer lap linex os not open but i enter correct username and password so,my computer totally dead ,how to solve this problem??????……………please help anybody

  35. Kevin,

    It didn’t end up with Jan 1 1970.

    As it says above, this field is the days since Jan 1, 1970 that password was last changed.

    13064 means the 8th of October 2005.

    Link [timeanddate.com]

    I hope this helps.

    John

    1. Because it would be security flaw.

      File /etc/shadow contains password hashes of system users, so it is not desirable that anyone can see that file.

      However usual permissions are with no permissions for others, with read-only permission for shadow group and with read-write permission for superuser (root).

  36. I’m running solaris 10.. i messed up the /etc/shadow file using vi now i can’t use root to log on.. is there a way to get into it or am i going to have to reimage the server?

    Options?

  37. hash code is the second field in that line…

    its the content between 1st and 2nd delimiter ‘:’

    content before the 1st ‘:’ is field 1

    and content after second ‘:’ is field 2

  38. basu said on April 7, 2014:
    how to make password change mandatory for every time a user logs in in linux .using command .

    There isn’t a command to do that every time that user logs in, and if there were one, it would probably cause that user a denial of access. But, to force the user to change their password on the NEXT time they log in, use the command:

    “passwd -f ” (as root)

    That will force them to change their password the next time they log in ONLY, but not every time. A system Admin will typically use that command when changing a users password, perhaps tell the user the password in a voice mail then let them know that as soon as they log in they will be forced to change the password.

    1. One could further that, though, automatically (and or use other ways aside commands). But I call it a bad move: it will only give them more reason to use weak passwords. It is worse than password aging in that regard (the latter of which goes too far, especially as number of logins increases (of course, foolishly re-using passwords is another issue entirely)). Better would be to use login key + password or otherwise multifactor authentication.

  39. bash-4.1# adduser -s /sbin/nologin graphene

    bash-4.1# cat /etc/shadow

    graphene:!!:16374:0:99999:7:::

    The above line suggests password has yet not been set for the user graphene whose login is disabled

    Adding a password for user graphene in the line below
    bash-4.1# passwd graphene

    Retype new password:
    passwd: all authentication tokens updated successfully.

    Now checking the shadow file
    bash-4.1# cat /etc/shadow

    graphene:$6$XIIyAsEW$IspEtIHOSncTn.qFRS.6iM//MET7kaIdm/eSsm.iOET7ZQYOL4AI5G2kgwb2gSpSwGEiEPLgHgRgMvJ5fMdWL.:16374:0:99999:7:::

    bash-4.1# whoami
    root

    Now trying to login as graphene

    bash-4.1# login
    login: graphene
    Password:
    This account is currently not available.

    Even the root user doesn’t seem to login into the account which has been marked “NoLogin”

    1. You’re under the assumption (and/or you’re not thinking of other possibilities) that the only way to log in is via the console.

      But you’re wrong.

      su allows you to specify shell which means that you can change the shell. Same with sudo.

      So:
      $ su – someuser -s /bin/bash

      will allow you to log in as someuser even if someuser has the shell of /sbin/nologin

      Therefore no, it isn’t disabled in full.

      1. Addendum:

        Define “login” – you might argue that logging in means directly as in you cannot be authenticated at all before it. But su essentially lets you log in as another user even if it is indirectly logging in. Indeed, try ‘su – someuser’ versus ‘su someuser’ and there are differences. Login shells, interactive shells… Also, if you check the man page of login you’ll see how your way isn’t correct, anyway:

        “A recursive login, as used to be possible in the good old days, no longer works; for most purposes su(1) is a satisfactory substitute. Indeed, for security reasons, login does a vhangup() system call to remove any possible listening processes on the tty. This is to avoid password sniffing. If one uses the command login, then the surrounding shell gets killed by vhangup() because it’s no longer the true owner of the tty. This can be avoided by using exec login in a top-level shell or xterm.”
        But still, the fact remains you can use su and specify the shell which therefore overrides the so-called disabled account.

  40. Actually, I think what is stored in the password field inside the shadow file is only a hash of the original password, not the password itself. The password field is usually divided into three parts, each part separated by an dollar sign. The first part signifies the algorithm used, ie: a value of 1 would indicate MD5 was used. The second part is the salt, if any, used when generating the hash. The last field is the password hash itself.

    1. More important, is it isn’t world readable. And more to the point, when you disable shadowing (i.e running as root ‘pwunconv’ …) then password IS readable and it also has the encrypted password. As for shadow, it does hold the encrypted password but the structure of it (that you describe) is correct only in some cases (you do use ‘usually’ but… will elaborate).

      Salt is part of it – Linux uses the crypt library call for passwords and it involves a salt – no ifs. That’s how it has been as long as I remember (long before shadow the norm (or maybe there.. don’t remember) (okay, to be fair, I’ve only used Linux since the early 2000s; I used SunOS/Solaris and various BSDs, prior to that) and I would imagine it has always been this way.

      As for the form of the password: It only has: $id$ if it isn’t 3DES (like the old systems defaulted to). $id$ specifies the algorithm to use. The salt and the hash are there regardless. There’s one other case where crypt(3) might fail: it isn’t implemented (e.g. export restrictions).

      In addition, to Vivek, you’re wrong: the password field does NOT have to be filled. It is just that some programs might deny access if a user tries to use an account (use = authenticate as) with no password. But it is technically allowed. Secondly, the string is 13 characters (first 2 is salt) for 3DES, and it is 22 for MD5. But those two aren’t the only algorithms. Thirdly, \ is not part of the hash.

  41. lesca September 23, 2010, 4:29 am
    !! measns user account has not been initialed or has not been locked.
    ! means group password is not available.
    * means login disabled.

    – Thank you for posting this, its very helpful. Is it possible to show this with an example? I am a newbie and not a Unix Admin so cannot do it myself.

  42. Password : It is your encrypted password. The password should be minimum 6-8 characters long including special characters/digits and more.

    The password is not encrypted- it’s one-way hashed, which is a very different thing. Encryption implies two-way (it can be decrypted). Obviously, one-way hashes can only be computed one-way (they’re lossy compression).

    Also, your password should be much longer than a “minimum 6-8 characters”. I have access to a password cracking machine that can crack every SHA-1 hash created with any 8-character password within one week. Which means that a 9-character password would take 94 weeks (assuming you’re using all 94 graphical characters on an ASCII keyboard) on that same machine. This machine is a rather weak one alse.

    I would recommend a target of AT LEAST 12 characters.

Leave a Comment