I don't know what's algorithm of storing password in /etc/shadow in Linux.
I tested via the following script via python: import hashlib message = b"123" md5_hash = hashlib.md5(message).hexdigest() sha1_hash = hashlib.sha1(message).hexdigest() sha256_hash = hashlib.sha256(message).hexdigest() sha384_hash = hashlib.sha384(message).hexdigest() sha512_hash = hashlib.sha512(message).hexdigest() print(f"MD5: {md5_hash}") print(f"SHA-1: {sha1_hash}") print(f"SHA-256: {sha256_hash}") print(f"SHA-384: {sha384_hash}") print(f"SHA-512: {sha512_hash}") But I did't see my password.My password is 123.
1. Does shadow store as HASH? if yes I should discard getting password.
2. If password doesn't store as hash, How can I get it?

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 :!:..... 2. Some of the password fields may have a double exclamation :!!:..... 3. Some of the password fields may have an asterisk sign :*:..... 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 (!)?

I have an embedded Linux device with a fairly modern Linux kernel. However, a strange thing happened with the last update: when a password is modified with passwd for any user, the salt value in /etc/shadow is replaced with rounds=65536, so an entry will look like root:$6$rounds=65536$6mA.... I suspect PAM is doing this. Does anyone have any idea what issue with PAM could cause such behaviour?

In /etc/shadow file there are encrypted password. Encrypted password is no longer crypt(3) or md5 "type 1" format. (according to this previous answer ) Now I have a $6$somesalt$someveryverylongencryptedpasswd as entry. I can no longer use openssl passwd -1 -salt salt hello-world $1$salt$pJUW3ztI6C1N/anHwD6MB0 to generate encrypted passwd. Any equivalent like (non existing) .. ? openssl passwd -6 -salt salt hello-world

I noticed passwd utility doesn't support the -s/--stdin option on Debian which allows to read password from standard input. With this option you can do something like echo mypassword | passwd -s mylogin to set password for specific login from script. I just wanted to try it but noticed it is not possible on Ubuntu nor Debian which is base for Ubuntu. It will print error that option is not recognized. So i went to Debian sources for **passwd** package (it's here https://salsa.debian.org/debian/shadow/-/tree/master/debian?ref_type=heads) and tried to find the patch that removes the option because in the original source code for passwd utility the option is still there (https://salsa.debian.org/debian/shadow/-/blob/master/src/passwd.c?ref_type=heads#L166) . **I can't find the patch in the repository, it looks like it's not there. Can anybody help me to find it?** I don't know the workflow that is used to patch the original source code but i expected the patch to be there because there is folder with patches (https://salsa.debian.org/debian/shadow/-/tree/master/debian/patches/debian?ref_type=heads) . Thank you.

It seems to me that /etc/shadow and /etc/passwd contain the same data. Why are there two files? Are they different?

There is a shadow around each window in Mate. If it matters I run Lightdm. How can the shadows be completely disabled for all windows regardless of the application?

We run a small lab with 20 Linux systems (RaspberryPI, NAS, Desktop PCs) for research with 4 scientists who all need sudo permissions. We trust all 4 users as they have sudo permission and physical access any way. The laboratory network is a local network and not accessible from the internet. Now we would like to synchronize the credentials. If one user changes the password, it should not be changed manually on the other 19 systems. I would like to avoid complex solutions like LDAP. The first idea which came into my mind was to maintain the credentials on the NAS as single source and copy them via scp to the clients in a systemd module. But I guess I am reinventing the wheel and there are ready to use packages/solutions and I just tried the wrong search terms. Which package or solution is commonly used for such a scenario?

I have an encrypted hard drive. The hard drive, root user, and primary user all share the same password. I have successfully logged in but seem to have forgotten the password. I'm looking to limit the damage of this forgotten password and attempt to recover it. The steps I am taking so far are the following: * Write down the password as best I can remember it. * Email a copy of /etc/passwd to myself so I can attempt to run a brute force attack on it with the characters from the prior step. * Backup unsaved data and files as best I can. Does anyone have any suggestions on a tool to use to brute force /etc/passwd? Update: It looks like the hashed passwords are now in /etc/shadow so if I want to run this brute force I need to do it now while I have a login prompt... I have no root shell and cannot sudo since it's the same password.

I need to manually edit /etc/shadow to change the root password inside of a virtual machine image. Is there a command-line tool that takes a password and generates an /etc/shadow compatible password hash on standard out?

I have the following line in my /etc/shadow file (SALT and HASHED_PASSWORD are not real values for obvious reason). And I understand $6 means SHA512 is used.

testuser:$6$SALT$HASHED_PASSWORD:19591:0:99999:7:::

I wonder how do I combine the SALT and my real password PASSWD as input for SHA512 to get the HASHED_PASSWORD value? I tried to run sha512sum command and paste in PASSWD+SALT and SALT+PASSWD (without the + sign). But the result is nothing like the HASHED_PASSWORD stored in the file.

What is the practical difference between setting *LK* in /etc/shadow and setting /usr/sbin/nologon in /etc/passwd? When would we choose one over the other? When would we combine them?

on my server running UnraidOS I got a bit suspicious. There are both 'passwd' and 'passwd-' files (same goes for shadow(-)). These ones should be only backups as I understood. Running: root@Unraid-server:~# diff /etc/passwd{,-} delivers: 2,8c2,8 bin:!:1:1:bin:/bin:/bin/false > daemon:!:2:2:daemon:/sbin:/bin/false > adm:!:3:4:adm:/var/log:/bin/false > ftp:!:14:50::/home/ftp:/bin/false > rpc:!:32:32:RPC portmap user:/:/bin/false > sshd:!:33:33:sshd:/:/bin/false > ntp:!:44:44:User for NTP:/:/bin/false 10,14c10,14 dhcpcd:!:68:68:dhcp PrivSep:/var/lib/dhcpcd:/bin/false > avahi:!:61:214:Avahi Daemon User:/dev/null:/bin/false > avahi-autoipd:!:62:62:Avahi AutoIP Daemon User:/dev/null:/bin/false > messagebus:!:81:81:User for D-BUS:/var/run/dbus:/bin/false > nobody:!:99:100:nobody:/:/bin/false As it seems, only all the 'x' for '!' were changed in the back-uped version. Nothing changed here in terms of the user id, just the 'locked' status was applied. **A) This is correct and not suspicious, right?** For shadow it is a bit different: root@Unraid-server:~# diff /etc/shadow{,-} 2,11c2,11 bin:!:19451:0:99999:7::: > daemon:!:19451:0:99999:7::: > adm:!:19451:0:99999:7::: > ftp:!:19451:0:99999:7::: > rpc:!:19451:0:99999:7::: > sshd:!:19451:0:99999:7::: > avahi:!:19451:0:99999:7::: > avahi-autoipd:!:19451:0:99999:7::: > messagebus:!:19451:0:99999:7::: > nobody:!:19451:0:99999:7::: 15c15 ntp:!:19451:::::: 17c17 dhcpcd:!:19451:::::: **Shouldn't there be the same user-id on shadow as well as shadow-? Why are the user-id's changed between the original file and the backup? -> on my /boot/config file the user-id of original shadow file are equivalent.**

I would like assistance with something I have to do. I need to verify if all users in passwd are also in shadow, if the primary group exists, if the homedir exists and if it belongs to the correct user/group. If something is wrong, it should output it to a new file, called for example "errors". How can I implement a script that does this?

Based on /etc/shadow(5) documentation on the second (password) field: > ### encrypted password > > If the password field contains some string that is not a valid result > of crypt(3), for instance ! or *, the user will not be able to use a > unix password to log in (but the user may log in the system by other > means). My question is whether there is a linux command to disable the user password,i.e. set a "*" or a "!" on password field.

Windows has a neat feature: it has a built-in password manager/storage which gets unlocked automatically when you log in. Are there any Linux applications which are linked to pam.d, so that entering your *valid* password is enough to get their stored passwords unlocked/unecrypted? A bonus feature would be to be able to run something like password=$(password_manager --item certain_item --show). AFAIK there's gnome-keyring but what if I don't use Gnome? There's a feature request for keepassxc but it's not implemented yet: https://github.com/keepassxreboot/keepassxc/discussions/5879

Consider this Shadow string

$y$j9T$PaFEMV0mbpeadmHDv0Lp31$G/LliR3MqgdjEBcFC1E.s/3vlRofsZ0Wn5JyZHXAol5

There are 4 parts - id : y (yescrypt) - param : j9T - salt : PaFEMV0mbpeadmHDv0Lp31 - hash : G/LliR3MqgdjEBcFC1E.s/3vlRofsZ0Wn5JyZHXAol5 **Q:** 1. What does j9T in param field mean? 2. Are there other options in this field? 3. Where can we find official documentation? I've seen this question; The format of encrypted password in /etc/shadow , however, there is no explanation there.

I had created two users on Linux with the same exact passwords, but when I looked at the /etc/shadow file, I found that the hashed values look different, although the salt file is the same. (Please see below, j9T is the salt). Why the hashed passwords are NOT similar, although the slat and password are similar? # tail /etc/shadow Bob:$y$**j9T**$ewJ0HB756BZDnPjx7zzbm0$i39AKrfuQuvvoQJpujwWd7Z4bcZgN1l0IWeJsNmLzg7:19254:0:99999:7::: Bob:$y$**j9T**$pFF5c93UZvdFYD2nanxEO.$SMhaxtPUPEUZdZZx.b1tGmjXgM67nqBJgMk2sNP.5s4:19254:0:99999:7:::

Kindly assist to to get user creation details (date and time) and users login details in Solaris 10

I see a hashed passphrase like the following in /etc/shadow. I don't quite understand its format.

$y$j9T$F5Jx5fExrKuPp53xLKQ..1$X3DX6M94c7o.9agCG9G317fhZg9SqC.5i5rd.RhAtQ7

It is made of four parts as shown below. According to crypt(5), y means yescrypt. https://manpages.debian.org/unstable/libcrypt-dev/crypt.5.en.html

- y
- j9T
- F5Jx5fExrKuPp53xLKQ..1
- X3DX6M94c7o.9agCG9G317fhZg9SqC.5i5rd.RhAtQ7

What is the meaning of the last three parts?