I tried setting users.users.root.hashedPassword = "*"; similar to sudo passwd -d root or user { 'root': password => '*', require => Package[ruby-shadow], } in Puppet , but after sudo nixos-rebuild switch I'm still able to su - with the old password.

I'm running RHEL 8, and occasionally, I get an issue where the authentication window won't accept my password. I know I am entering it correctly because it is the same password I use to log in to the system. Checked /var/log/secure but didn't see anything useful. Could it be related to pam.d?

Here's a difficult ssh problem I can't figure out on Solaris 11, although I think I'm an experienced UNIX/Linux sysadmin. :) I've copied the root@server1:/root/.ssh/id_rsa.pub file to: root@server2:/root/.ssh/authorized_keys oracle@server2:/home/oracle/.ssh/authorized_keys No problem logging on or running commands remotely for oracle@server2. I keep getting the password prompt for root@server2. If I run "sshd -d" (debug mode) on server2 and run "ssh root@server2 uptime" from server1, I get to see the following info on server2 until I get the password prompt and press Ctrl-C to interrupt it: server2# /usr/lib/ssh/sshd -d debug1: sshd version Sun_SSH_2.2 debug1: key_load_private: loading /etc/ssh/ssh_host_rsa_key debug1: ssh_kmf_check_uri: /etc/ssh/ssh_host_rsa_key debug1: read PEM private key done: type RSA debug1: Private host key #0 of type 1 (RSA). debug1: key_load_private: loading /etc/ssh/ssh_host_dsa_key debug1: ssh_kmf_check_uri: /etc/ssh/ssh_host_dsa_key debug1: read PEM private key done: type DSA debug1: Private host key #1 of type 2 (DSA). debug1: Creating a global KMF session. debug1: Bind to port 22 on ::. Server listening on :: port 22. debug1: Server will not fork when running in debugging mode. Connection from 10.71.4.10 port 21911 debug1: Client protocol version 2.0; client software version Sun_SSH_2.2 debug1: match: Sun_SSH_2.2 pat Sun_SSH_2.* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-Sun_SSH_2.2 monitor debug1: list_hostkey_types: ssh-rsa,ssh-dss debug1: Reloading X.509 host keys to avoid PKCS#11 fork issues. monitor debug1: reading the context from the child debug1: use_engine is 'yes' debug1: pkcs11 engine initialized, now setting it as default for RSA, DSA, and symmetric ciphers debug1: pkcs11 engine initialization complete debug1: list_hostkey_types: ssh-rsa,ssh-dss debug1: My KEX proposal before adding the GSS KEX algorithm: debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: My KEX proposal I sent to the peer: debug1: KEX proposal I received from the peer: debug1: kex: client->server aes128-ctr hmac-sha2-256 none debug1: kex: server->client aes128-ctr hmac-sha2-256 none debug1: Host key algorithm 'ssh-rsa' chosen for the KEX. debug1: Peer sent proposed langtags, ctos: en-US debug1: Peer sent proposed langtags, stoc: en-US debug1: We proposed langtags, ctos: de-DE,en-US,es-ES,fr-FR,it-IT,ja-JP,ko-KR,pt-BR,zh-CN,zh-TW,i-default debug1: We proposed langtags, stoc: de-DE,en-US,es-ES,fr-FR,it-IT,ja-JP,ko-KR,pt-BR,zh-CN,zh-TW,i-default debug1: Negotiated main locale: en_US.UTF-8 debug1: Negotiated messages locale: en_US.UTF-8 debug1: Host key type is 1. debug1: SSH2_MSG_KEX_DH_GEX_REQUEST received debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent debug1: dh_gen_key: priv key bits set: 252/512 debug1: bits set: 2051/4095 debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT debug1: bits set: 2036/4095 debug1: SSH2_MSG_KEX_DH_GEX_REPLY sent debug1: set_newkeys: setting new keys for 'out' mode debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug1: set_newkeys: setting new keys for 'in' mode debug1: SSH2_MSG_NEWKEYS received debug1: KEX done debug1: userauth-request for user root service ssh-connection method none debug1: attempt 0 initial attempt 0 failures 0 initial failures 0 Failed none for root from 10.71.4.10 port 21911 ssh2 debug1: userauth-request for user root service ssh-connection method publickey debug1: attempt 1 initial attempt 0 failures 0 initial failures 0 debug1: ssh_kmf_key_from_blob: blob length is 277. debug1: Test whether the public key is acceptable. debug1: temporarily_use_uid: 0/0 (e=0/0) debug1: trying public key file /root/.ssh/authorized_keys debug1: ssh_kmf_key_from_blob: blob length is 277. debug1: matching key found: file /root/.ssh/authorized_keys, line 1 Found matching RSA key: 8e:7f:c6:54:09:e7:fa:6e:5c:cc:c7:13:e2:13:90:22 debug1: restore_uid: 0/0 debug1: userauth-request for user root service ssh-connection method publickey debug1: attempt 2 initial attempt 0 failures 0 initial failures 0 debug1: ssh_kmf_key_from_blob: blob length is 277. debug1: We received a signature in the user auth packet. debug1: temporarily_use_uid: 0/0 (e=0/0) debug1: trying public key file /root/.ssh/authorized_keys debug1: ssh_kmf_key_from_blob: blob length is 277. debug1: matching key found: file /root/.ssh/authorized_keys, line 1 Found matching RSA key: 8e:7f:c6:54:09:e7:fa:6e:5c:cc:c7:13:e2:13:90:22 debug1: restore_uid: 0/0 debug1: ssh_rsa_verify: signature correct Failed publickey for root from 10.71.4.10 port 21911 ssh2 debug1: userauth-request for user root service ssh-connection method keyboard-interactive debug1: attempt 3 initial attempt 0 failures 2 initial failures 0 debug1: keyboard-interactive devs Connection closed by 10.71.4.10 debug1: Calling cleanup 0x2df78(0xec5010) debug1: Calling cleanup 0x262a8(0xece938) debug1: Calling cleanup 0x53590(0x0) monitor debug1: child closed the communication pipe before user auth was finished monitor debug1: Calling cleanup 0x53590(0x0) monitor debug1: Calling cleanup 0x53590(0x0) More information on the SSH server configuration: server2# diff /root/.ssh/authorized_keys /home/oracle/.ssh/authorized_keys server2# server2# ls -l /root/.ssh/authorized_keys /home/oracle/.ssh/authorized_keys -rw------- 1 oracle dba 396 Aug 29 08:53 /home/oracle/.ssh/authorized_keys -rw------- 1 root root 396 Aug 29 08:53 /root/.ssh/authorized_keys server2# ls -ld /root /home/oracle drwxr-xr-x 30 oracle dba 69 Aug 20 06:13 /home/oracle drwx------ 22 root root 43 Aug 29 08:52 /root server2# ls -ld /root/.ssh /home/oracle/.ssh drwx--x--x 2 root root 5 Mar 20 2014 /home/oracle/.ssh drwx--x--x 2 root root 3 Aug 29 08:53 /root/.ssh server2# grep Root /etc/ssh/sshd_config PermitRootLogin yes Below shows the remote server server2's /var/log/authlog when I attempted ssh root@server2 uptime from server1: Aug 30 09:46:48 db01 sshd: [ID 800047 auth.debug] debug1: Forked child 13172. Aug 30 09:46:48 db01 sshd: [ID 800047 auth.info] Connection from 10.71.4.10 port 28154 Aug 30 09:46:48 db01 sshd: [ID 800047 auth.debug] debug1: Client protocol version 2.0; client software version Sun_SSH_2.2 Aug 30 09:46:48 db01 sshd: [ID 800047 auth.debug] debug1: match: Sun_SSH_2.2 pat Sun_SSH_2.* Aug 30 09:46:48 db01 sshd: [ID 800047 auth.debug] debug1: Enabling compatibility mode for protocol 2.0 Aug 30 09:46:48 db01 sshd: [ID 800047 auth.debug] debug1: Local version string SSH-2.0-Sun_SSH_2.2 Aug 30 09:46:48 db01 sshd: [ID 800047 auth.debug] monitor debug1: list_hostkey_types: ssh-rsa,ssh-dss Aug 30 09:46:48 db01 sshd: [ID 800047 auth.debug] debug1: Reloading X.509 host keys to avoid PKCS#11 fork issues. Aug 30 09:46:48 db01 sshd: [ID 800047 auth.debug] monitor debug1: reading the context from the child Aug 30 09:46:48 db01 sshd: [ID 800047 auth.debug] debug1: use_engine is 'yes' Aug 30 09:46:48 db01 sshd: [ID 800047 auth.debug] debug1: pkcs11 engine initialized, now setting it as default for RSA, DSA, and symmetric ciphers Aug 30 09:46:48 db01 sshd: [ID 800047 auth.debug] debug1: pkcs11 engine initialization complete Aug 30 09:46:48 db01 sshd: [ID 800047 auth.debug] debug1: list_hostkey_types: ssh-rsa,ssh-dss Aug 30 09:46:48 db01 sshd: [ID 800047 auth.debug] debug1: My KEX proposal before adding the GSS KEX algorithm: Aug 30 09:46:48 db01 sshd: [ID 800047 auth.debug] debug1: SSH2_MSG_KEXINIT sent Aug 30 09:46:48 db01 sshd: [ID 800047 auth.debug] debug1: SSH2_MSG_KEXINIT received Aug 30 09:46:48 db01 sshd: [ID 800047 auth.debug] debug1: My KEX proposal I sent to the peer: Aug 30 09:46:48 db01 sshd: [ID 800047 auth.debug] debug1: KEX proposal I received from the peer: Aug 30 09:46:48 db01 sshd: [ID 800047 auth.debug] debug1: kex: client->server aes128-ctr hmac-sha2-256 none Aug 30 09:46:48 db01 sshd: [ID 800047 auth.debug] debug1: kex: server->client aes128-ctr hmac-sha2-256 none Aug 30 09:46:48 db01 sshd: [ID 800047 auth.debug] debug1: Host key algorithm 'ssh-rsa' chosen for the KEX. Aug 30 09:46:48 db01 sshd: [ID 800047 auth.debug] debug1: Peer sent proposed langtags, ctos: en-US Aug 30 09:46:48 db01 sshd: [ID 800047 auth.debug] debug1: Peer sent proposed langtags, stoc: en-US Aug 30 09:46:48 db01 sshd: [ID 800047 auth.debug] debug1: We proposed langtags, ctos: de-DE,en-US,es-ES,fr-FR,it-IT,ja-JP,ko-KR,pt-BR,zh-CN,zh-TW,i-default Aug 30 09:46:48 db01 sshd: [ID 800047 auth.debug] debug1: We proposed langtags, stoc: de-DE,en-US,es-ES,fr-FR,it-IT,ja-JP,ko-KR,pt-BR,zh-CN,zh-TW,i-default Aug 30 09:46:48 db01 sshd: [ID 800047 auth.debug] debug1: Negotiated main locale: en_US.UTF-8 Aug 30 09:46:48 db01 sshd: [ID 800047 auth.debug] debug1: Negotiated messages locale: en_US.UTF-8 Aug 30 09:46:48 db01 sshd: [ID 800047 auth.debug] debug1: Host key type is 1. Aug 30 09:46:48 db01 sshd: [ID 800047 auth.debug] debug1: SSH2_MSG_KEX_DH_GEX_REQUEST received Aug 30 09:46:48 db01 sshd: [ID 800047 auth.debug] debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent Aug 30 09:46:48 db01 sshd: [ID 800047 auth.debug] debug1: dh_gen_key: priv key bits set: 267/512 Aug 30 09:46:48 db01 sshd: [ID 800047 auth.debug] debug1: bits set: 2056/4095 Aug 30 09:46:48 db01 sshd: [ID 800047 auth.debug] debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT Aug 30 09:46:49 db01 sshd: [ID 800047 auth.debug] debug1: bits set: 2053/4095 Aug 30 09:46:49 db01 sshd: [ID 800047 auth.debug] debug1: SSH2_MSG_KEX_DH_GEX_REPLY sent Aug 30 09:46:49 db01 sshd: [ID 800047 auth.debug] debug1: set_newkeys: setting new keys for 'out' mode Aug 30 09:46:49 db01 sshd: [ID 800047 auth.debug] debug1: SSH2_MSG_NEWKEYS sent Aug 30 09:46:49 db01 sshd: [ID 800047 auth.debug] debug1: expecting SSH2_MSG_NEWKEYS Aug 30 09:46:49 db01 sshd: [ID 800047 auth.debug] debug1: set_newkeys: setting new keys for 'in' mode Aug 30 09:46:49 db01 sshd: [ID 800047 auth.debug] debug1: SSH2_MSG_NEWKEYS received Aug 30 09:46:49 db01 sshd: [ID 800047 auth.debug] debug1: KEX done Aug 30 09:46:49 db01 sshd: [ID 800047 auth.debug] debug1: userauth-request for user root service ssh-connection method none Aug 30 09:46:49 db01 sshd: [ID 800047 auth.debug] debug1: attempt 0 initial attempt 0 failures 0 initial failures 0 Aug 30 09:46:49 db01 sshd: [ID 800047 auth.info] Failed none for root from 10.71.4.10 port 28154 ssh2 Aug 30 09:46:49 db01 sshd: [ID 800047 auth.debug] debug1: userauth-request for user root service ssh-connection method publickey Aug 30 09:46:49 db01 sshd: [ID 800047 auth.debug] debug1: attempt 1 initial attempt 0 failures 0 initial failures 0 Aug 30 09:46:49 db01 sshd: [ID 800047 auth.debug] debug1: ssh_kmf_key_from_blob: blob length is 277. Aug 30 09:46:49 db01 sshd: [ID 800047 auth.debug] debug1: Test whether the public key is acceptable. Aug 30 09:46:49 db01 sshd: [ID 800047 auth.debug] debug1: temporarily_use_uid: 0/0 (e=0/0) Aug 30 09:46:49 db01 sshd: [ID 800047 auth.debug] debug1: trying public key file /root/.ssh/authorized_keys Aug 30 09:46:49 db01 sshd: [ID 800047 auth.debug] debug1: ssh_kmf_key_from_blob: blob length is 277. Aug 30 09:46:49 db01 sshd: [ID 800047 auth.debug] debug1: matching key found: file /root/.ssh/authorized_keys, line 1 Aug 30 09:46:49 db01 sshd: [ID 800047 auth.info] Found matching RSA key: 8e:7f:c6:54:09:e7:fa:6e:5c:cc:c7:13:e2:13:90:22 Aug 30 09:46:49 db01 sshd: [ID 800047 auth.debug] debug1: restore_uid: 0/0 Aug 30 09:46:49 db01 sshd: [ID 800047 auth.debug] debug1: userauth-request for user root service ssh-connection method publickey Aug 30 09:46:49 db01 sshd: [ID 800047 auth.debug] debug1: attempt 2 initial attempt 0 failures 0 initial failures 0 Aug 30 09:46:49 db01 sshd: [ID 800047 auth.debug] debug1: ssh_kmf_key_from_blob: blob length is 277. Aug 30 09:46:49 db01 sshd: [ID 800047 auth.debug] debug1: We received a signature in the user auth packet. Aug 30 09:46:49 db01 sshd: [ID 800047 auth.debug] debug1: temporarily_use_uid: 0/0 (e=0/0) Aug 30 09:46:49 db01 sshd: [ID 800047 auth.debug] debug1: trying public key file /root/.ssh/authorized_keys Aug 30 09:46:49 db01 sshd: [ID 800047 auth.debug] debug1: ssh_kmf_key_from_blob: blob length is 277. Aug 30 09:46:49 db01 sshd: [ID 800047 auth.debug] debug1: matching key found: file /root/.ssh/authorized_keys, line 1 Aug 30 09:46:49 db01 sshd: [ID 800047 auth.info] Found matching RSA key: 8e:7f:c6:54:09:e7:fa:6e:5c:cc:c7:13:e2:13:90:22 Aug 30 09:46:49 db01 sshd: [ID 800047 auth.debug] debug1: restore_uid: 0/0 Aug 30 09:46:49 db01 sshd: [ID 800047 auth.debug] debug1: ssh_rsa_verify: signature correct Aug 30 09:46:49 db01 sshd: [ID 800047 auth.notice] Failed publickey for root from 10.71.4.10 port 28154 ssh2 Aug 30 09:46:49 db01 sshd: [ID 800047 auth.debug] debug1: userauth-request for user root service ssh-connection method keyboard-interactive Aug 30 09:46:49 db01 sshd: [ID 800047 auth.debug] debug1: attempt 3 initial attempt 0 failures 2 initial failures 0 Aug 30 09:46:49 db01 sshd: [ID 800047 auth.debug] debug1: keyboard-interactive devs Aug 30 09:46:51 db01 sshd: [ID 800047 auth.info] Connection closed by 10.71.4.10 Aug 30 09:46:51 db01 sshd: [ID 800047 auth.debug] debug1: Calling cleanup 0x2df78(0x34f960) Aug 30 09:46:51 db01 sshd: [ID 800047 auth.debug] debug1: Calling cleanup 0x262a8(0x3592f8) Aug 30 09:46:51 db01 sshd: [ID 800047 auth.debug] debug1: Calling cleanup 0x53590(0x0) Aug 30 09:46:51 db01 sshd: [ID 800047 auth.debug] monitor debug1: child closed the communication pipe before user auth was finished Aug 30 09:46:51 db01 sshd: [ID 800047 auth.debug] monitor debug1: Calling cleanup 0x53590(0x0) Aug 30 09:46:51 db01 last message repeated 1 time Also, below shows the output on server1 (on the originating server) when I used "ssh -v -v -v root@server2" from server1 to connect to server2: server1# ssh -v -v -v root@server2 Sun_SSH_2.2, SSH protocols 1.5/2.0, OpenSSL 0x1000110f debug1: Reading configuration data /etc/ssh/ssh_config debug1: Rhosts Authentication disabled, originating port will not be trusted. debug1: ssh_connect: needpriv 0 debug1: Connecting to db01 [10.65.4.139] port 22. debug1: Connection established. debug1: ssh_kmf_check_uri: /root/.ssh/identity debug1: Identity file/URI '/root/.ssh/identity' pubkey type UNKNOWN debug1: ssh_kmf_check_uri: /root/.ssh/id_rsa debug3: Not a RSA1 key file /root/.ssh/id_rsa. debug2: key_type_from_name: unknown key type '-----BEGIN' debug3: key_read: no key found debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug2: key_type_from_name: unknown key type '-----END' debug3: key_read: no key found debug1: ssh_kmf_key_from_blob: blob length is 277. debug1: Identity file/URI '/root/.ssh/id_rsa' pubkey type ssh-rsa debug1: ssh_kmf_check_uri: /root/.ssh/id_dsa debug1: Identity file/URI '/root/.ssh/id_dsa' pubkey type UNKNOWN debug1: Logging to host: db01 debug1: Local user: root Remote user: root debug1: Remote protocol version 2.0, remote software version Sun_SSH_2.2 debug1: match: Sun_SSH_2.2 pat Sun_SSH_2.* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-Sun_SSH_2.2 debug1: use_engine is 'yes' debug1: pkcs11 engine initialized, now setting it as default for RSA, DSA, and symmetric ciphers debug1: pkcs11 engine initialization complete debug1: Creating a global KMF session. debug1: My KEX proposal before adding the GSS KEX algorithm: debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ssh-rsa,ssh-dss,x509v3-sign-rsa,x509v3-sign-dss debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour128,arcfour256,arcfour,aes128-cbc,aes192-cbc,aes256-cbc,blowfish-cbc,3des-cbc debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour128,arcfour256,arcfour,aes128-cbc,aes192-cbc,aes256-cbc,blowfish-cbc,3des-cbc debug2: kex_parse_kexinit: hmac-sha2-256,hmac-sha2-512,hmac-sha1,hmac-sha2-256-96,hmac-sha2-512-96,hmac-sha1-96,hmac-md5,hmac-md5-96 debug2: kex_parse_kexinit: hmac-sha2-256,hmac-sha2-512,hmac-sha1,hmac-sha2-256-96,hmac-sha2-512-96,hmac-sha1-96,hmac-md5,hmac-md5-96 debug2: kex_parse_kexinit: none,zlib debug2: kex_parse_kexinit: none,zlib debug2: kex_parse_kexinit: en-US debug2: kex_parse_kexinit: en-US debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug1: Failed to acquire GSS-API credentials for any mechanisms (No credentials were supplied, or the credentials were unavailable or inaccessible ) debug1: SSH2_MSG_KEXINIT sent debug3: kex_reset_dispatch -- should we dispatch_set(KEXINIT) here? 0 && !0 debug1: SSH2_MSG_KEXINIT received debug1: My KEX proposal I sent to the peer: debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ssh-rsa,ssh-dss,x509v3-sign-rsa,x509v3-sign-dss debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour128,arcfour256,arcfour,aes128-cbc,aes192-cbc,aes256-cbc,blowfish-cbc,3des-cbc debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour128,arcfour256,arcfour,aes128-cbc,aes192-cbc,aes256-cbc,blowfish-cbc,3des-cbc debug2: kex_parse_kexinit: hmac-sha2-256,hmac-sha2-512,hmac-sha1,hmac-sha2-256-96,hmac-sha2-512-96,hmac-sha1-96,hmac-md5,hmac-md5-96 debug2: kex_parse_kexinit: hmac-sha2-256,hmac-sha2-512,hmac-sha1,hmac-sha2-256-96,hmac-sha2-512-96,hmac-sha1-96,hmac-md5,hmac-md5-96 debug2: kex_parse_kexinit: none,zlib debug2: kex_parse_kexinit: none,zlib debug2: kex_parse_kexinit: en-US debug2: kex_parse_kexinit: en-US debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug1: KEX proposal I received from the peer: debug2: kex_parse_kexinit: gss-group1-sha1-toWM5Slw5Ew8Mqkay+al2g==,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ssh-rsa,ssh-dss debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour128,arcfour256,arcfour debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour128,arcfour256,arcfour debug2: kex_parse_kexinit: hmac-sha2-256,hmac-sha2-512,hmac-sha1,hmac-sha2-256-96,hmac-sha2-512-96,hmac-sha1-96,hmac-md5,hmac-md5-96 debug2: kex_parse_kexinit: hmac-sha2-256,hmac-sha2-512,hmac-sha1,hmac-sha2-256-96,hmac-sha2-512-96,hmac-sha1-96,hmac-md5,hmac-md5-96 debug2: kex_parse_kexinit: none,zlib debug2: kex_parse_kexinit: none,zlib debug2: kex_parse_kexinit: de-DE,en-US,es-ES,fr-FR,it-IT,ja-JP,ko-KR,pt-BR,zh-CN,zh-TW,i-default debug2: kex_parse_kexinit: de-DE,en-US,es-ES,fr-FR,it-IT,ja-JP,ko-KR,pt-BR,zh-CN,zh-TW,i-default debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: mac_setup: found hmac-sha2-256 debug1: kex: server->client aes128-ctr hmac-sha2-256 none debug2: mac_setup: found hmac-sha2-256 debug1: kex: client->server aes128-ctr hmac-sha2-256 none debug1: Host key algorithm 'ssh-rsa' chosen for the KEX. debug1: Peer sent proposed langtags, ctos: de-DE,en-US,es-ES,fr-FR,it-IT,ja-JP,ko-KR,pt-BR,zh-CN,zh-TW,i-default debug1: Peer sent proposed langtags, stoc: de-DE,en-US,es-ES,fr-FR,it-IT,ja-JP,ko-KR,pt-BR,zh-CN,zh-TW,i-default debug1: We proposed langtags, ctos: en-US debug1: We proposed langtags, stoc: en-US debug1: Negotiated lang: en-US debug1: SSH2_MSG_KEX_DH_GEX_REQUEST sent debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP debug1: Remote: Negotiated main locale: en_US.UTF-8 debug1: Remote: Negotiated messages locale: en_US.UTF-8 debug1: dh_gen_key: priv key bits set: 262/512 debug1: bits set: 2025/4095 debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY debug1: ssh_kmf_key_from_blob: blob length is 277. debug3: check_host_in_hostfile: filename /root/.ssh/known_hosts debug1: ssh_kmf_key_from_blob: blob length is 277. debug3: check_host_in_hostfile: match line 17 debug3: check_host_in_hostfile: filename /root/.ssh/known_hosts debug1: ssh_kmf_key_from_blob: blob length is 277. debug3: check_host_in_hostfile: match line 17 debug1: Host 'db01' is known and matches the RSA host key. debug1: Found key in /root/.ssh/known_hosts:17 debug1: bits set: 2075/4095 debug1: ssh_rsa_verify: signature correct debug2: kex_derive_keys debug3: kex_reset_dispatch -- should we dispatch_set(KEXINIT) here? 0 && !0 debug2: set_newkeys: mode 1 debug1: set_newkeys: setting new keys for 'out' mode debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug2: set_newkeys: mode 0 debug1: set_newkeys: setting new keys for 'in' mode debug1: SSH2_MSG_NEWKEYS received debug1: done: ssh_kex2. debug1: send SSH2_MSG_SERVICE_REQUEST debug2: service_accept: ssh-userauth debug1: got SSH2_MSG_SERVICE_ACCEPT debug1: Authentications that can continue: gssapi-keyex,gssapi-with-mic,publickey,password,keyboard-interactive debug3: start over, passed a different list gssapi-keyex,gssapi-with-mic,publickey,password,keyboard-interactive debug3: preferred gssapi-keyex,gssapi-with-mic,publickey,keyboard-interactive,password debug3: authmethod_lookup gssapi-keyex debug3: remaining preferred: gssapi-with-mic,publickey,keyboard-interactive,password debug3: authmethod_is_enabled gssapi-keyex debug1: Next authentication method: gssapi-keyex debug2: we did not send a packet, disable method debug3: authmethod_lookup gssapi-with-mic debug3: remaining preferred: publickey,keyboard-interactive,password debug3: authmethod_is_enabled gssapi-with-mic debug1: Next authentication method: gssapi-with-mic debug1: Failed to acquire GSS-API credentials for any mechanisms (No credentials were supplied, or the credentials were unavailable or inaccessible ) debug2: we did not send a packet, disable method debug3: authmethod_lookup publickey debug3: remaining preferred: keyboard-interactive,password debug3: authmethod_is_enabled publickey debug1: Next authentication method: publickey debug1: Trying private key: /root/.ssh/identity debug1: ssh_kmf_check_uri: /root/.ssh/identity debug3: no such identity: /root/.ssh/identity debug1: Trying public key: /root/.ssh/id_rsa debug3: send_pubkey_test debug2: we sent a publickey packet, wait for reply debug1: Server accepts key: pkalg ssh-rsa blen 277 lastkey 73cee8 hint 1 debug3: Pubkey type from SSH_MSG_USERAUTH_PK_OK is ssh-rsa. debug1: ssh_kmf_key_from_blob: blob length is 277. debug2: input_userauth_pk_ok: fp 8e:7f:c6:54:09:e7:fa:6e:5c:cc:c7:13:e2:13:90:22 debug3: sign_and_send_pubkey debug1: ssh_kmf_check_uri: /root/.ssh/id_rsa debug1: read PEM private key done: type RSA debug1: Authentications that can continue: gssapi-keyex,gssapi-with-mic,publickey,password,keyboard-interactive debug1: Trying private key: /root/.ssh/id_dsa debug1: ssh_kmf_check_uri: /root/.ssh/id_dsa debug3: no such identity: /root/.ssh/id_dsa debug2: we did not send a packet, disable method debug3: authmethod_lookup keyboard-interactive debug3: remaining preferred: password debug3: authmethod_is_enabled keyboard-interactive debug1: Next authentication method: keyboard-interactive debug2: userauth_kbdint debug2: we sent a keyboard-interactive packet, wait for reply debug2: input_userauth_info_req debug2: input_userauth_info_req: num_prompts 1 Password: debug3: packet_send2: adding 32 (len 14 padlen 18 extra_pad 64) Connection closed by 10.65.4.139 debug1: Calling cleanup 0x418a8(0x0)

Is it possible to change password for logged in LDAP user using passwd command? I have logged in to server1 using testuser. Trying to change password for itself (testuser) and got the below error. [testuser@server1 ~]$ passwd Changing password for user testuser. (current) LDAP Password: New password: Retype new password: password change failed: Insufficient access passwd: Authentication token manipulation error

I've created a user ... but forgotten the password

mysql> create user 'blayo'@'%' identified by 'right';

Which Linux command line tool can **encrypt the password the same way mysql 5.5 does ?**

mysql> select Password,User from mysql.user
------------------------------------------+-------+
*920018161824B14A1067A69626595E68CB8284CB | blayo |

...to be sure I use the right one

$ tool right
*920018161824B14A1067A69626595E68CB8284CB

encountered this on Metasploitable 2 **Give root password for maintenance (or type Control-D to continue):** The default root password of **msfadmin** isn't working. It keeps saying login incorrect. Please what is the correct password and how do I resolve this

I am maintaining a samba server for an office environment. So far, whenever there had to be a new user, I called the person over and let him type in his samba password on my console, after I typed smbpasswd -a username. I don't want to know any of the passwords. For the unix passwords, I just let them create a password digest (e.g. http://www.askapache.com/online-tools/htpasswd-generator/) in advance and edit the password file later with vipw -s. Now I have a remote colleague who can't come over to type in his password, but I still don't want to know it at all. How can I edit the samba password without actually knowing the password itself, but just a digest?

I'm running the MATE edition of Linux Mint on my laptop. I have an external USB disk with a LUKS container on it. The USB disk is connected to the laptop's docking station. Whenever I connect the laptop to the docking station, MATE pops up a window which says, "Enter a password to unlock the volume" along with a text field and options to forget the password immediately, remember until logout, or remember forever. (Not "don't show me this popup again," which is what I would prefer.) Under normal use, I want to have this external USB disk unmounted and idle. I have a cron job which unlocks the disk via a key file, mounts the partition, and runs an automated backup. I don't want this partition to be mounted all the time, nor do I want it to be accessible to my ordinary (non-privileged) user account. Is there any way to tell gvfs (or whatever is doing this) to please stop showing me the "enter password" dialog every time I dock my laptop to the docking station?

After user password change the size of salt decreased in RHEL/Centos 6, eg:

cat /etc/shadow

...
root:$6$FkMNsNxT$FW77....................nbL0......
bin:*:15422:0:99999:7:::
...

As you can see, FkMNsNxT is 8 characters. Why it happens? In the beginning, after installation, the size is 16 chars.

I have modified /etc/samba/smb.conf to create a [public] share:

[global]
workgroup = WORKGROUP
log file = /var/log/samba/log.%m
max log size = 1000
logging = file
panic action = /usr/share/samba/panic-action %d
server role = standalone server
obey pam restrictions = yes
unix password sync = yes
passwd program = /usr/bin/passwd %u
passwd chat = *Enter\snew\s*\spassword:* %n\n *Retype\snew\s*\spassword:* %n\n *password\supdated\ssuccessfully* .
pam password change = yes
map to guest = bad user
usershare allow guests = yes
[public]
comment = Public Storage
path = /home/share
valid users = @users
force group = users
create mask = 0660
directory mask = 0771
read only = no

and then I did:

sudo /etc/init.d/smbd restart
sudo smbpasswd -a pi  # enter a password here

Unfortunately, when I access this shared folder from Windows, I need to enter a user/password login (see screenshot below). **Question: how to make this Samba share accessible without any user/password login?** ___ PS: I created/mounted the shared folder like this:

sudo mkdir /home/share
sudo chown -R root:users /home/share
sudo chmod -R ug=rwx,o=rx /home/share
sudo mount /dev/sda1 /home/share

Samba users cannot change their own passwords. The password can only be changed using root account using the command smbpasswd -a But I want users be able to change their passwords by their own. When password is tried to changed using a non-root account I get the below error message. $ smbpasswd Old SMB password: New SMB password: Retype new SMB password: Could not connect to machine 127.0.0.1: NT_STATUS_LOGON_FAILURE Failed to change password for user1 Any reasons for this? How can I fix this?

I am running a CentOS-7 virtual machine and I have the task of recovering the root password of the system. But the GRUB menu is locked with Password-Based Key Derivation Function 2. Therefore I cannot just press 'e' at the grub menu. Can anyone help point me in the right direction? I have no clue where to start. Google searches only bring up people talking about pressing 'e' at the GRUB menu which isn't possible here.

I'm running a NAS server with https://www.openmediavault.org/ on a Raspberry PI. I've made a "shared folder", activated SMB sharing and within it created a share for this folder with "only guests" mode. I can use the share over the network. But now I want to secure it with a login/password instead of "only guests" and I'm a bit overwhelmed. How do I make sure my share needs credentials for access (read/write)?

I know this has been asked before, but I couldnt find a solution that fits my needs. I am the only user on my PC (running Pop!_OS 20.10). Nobody has access to my computer because I live alone. This is why I want to remove my login password. How can I achieve the following things: 1. No password required to log in 2. No "Unlock Login Keyring" popup after login without password 3. A password for sudo is still required 4. When the computer goes to sleep because I haven't used it for a while and then wake it up again I don't want to have to enter a password So far I have tried to enable "Automatic Login" in Settings>Users>Authentication & Login. But this only solves problem 1 and 3. After booting up, I am always asked for a password for "Unlock Login Keyring". And after waking up my unused computer, I also need a password. I also have tried removing the Password from my user. But after that I couldnt execute sudo commands anymore because I had no password.

I'm trying to programmatically change a user's password using chpasswd, but I'm getting the following error:

/sbin/chpasswd "
chpasswd: (user 0s22xmgW) pam_chauthtok() failed, error:
Authentication token manipulation error
chpasswd: (line 1, user 0s22xmgW) password not changed
root@phantom:/home/ealfonso#

After trying to enhance pam debug logging by appending "debug" to most lines in /etc/pam.d/common-auth and /etc/pam.d/common-password, and checking /var/auth.log, I see the following logs:

2025-04-23T12:37:33.676089-04:00 phantom chpasswd: pam_krb5(chpasswd:chauthtok): pam_sm_chauthtok: entry (prelim)
2025-04-23T12:37:33.676432-04:00 phantom chpasswd: pam_krb5(chpasswd:chauthtok): (user 0s22xmgW) attempting authentication as 0s22xmgW@example.com for kadmin/changepw
2025-04-23T12:37:34.701043-04:00 phantom chpasswd: pam_krb5(chpasswd:chauthtok): (user 0s22xmgW) krb5_get_init_creds_password: Client '0s22xmgW@example.com' not found in Kerberos database
2025-04-23T12:37:34.701246-04:00 phantom chpasswd: pam_krb5(chpasswd:chauthtok): pam_sm_chauthtok: exit (failure)
2025-04-23T12:37:34.701331-04:00 phantom chpasswd: pam_unix(chpasswd:chauthtok): username [0s22xmgW] obtained
2025-04-23T12:37:34.701762-04:00 phantom chpasswd: gkr-pam: invalid option: debug
2025-04-23T12:37:34.701966-04:00 phantom chpasswd: pam_krb5(chpasswd:chauthtok): pam_sm_chauthtok: entry (update)
2025-04-23T12:37:34.702065-04:00 phantom chpasswd: pam_krb5(chpasswd:chauthtok): (user 0s22xmgW) attempting authentication as 0s22xmgW@MY_REALM for kadmin/changepw
2025-04-23T12:37:35.719315-04:00 phantom chpasswd: pam_krb5(chpasswd:chauthtok): (user 0s22xmgW) krb5_get_init_creds_password: Client not found in Kerberos database
2025-04-23T12:37:35.719842-04:00 phantom chpasswd: pam_krb5(chpasswd:chauthtok): pam_sm_chauthtok: exit (failure)
2025-04-23T12:37:35.719923-04:00 phantom chpasswd: pam_unix(chpasswd:chauthtok): username [0s22xmgW] obtained
2025-04-23T12:37:35.719980-04:00 phantom chpasswd: pam_unix(chpasswd:chauthtok): password - new password not obtained

I do use kerberos authentication for AFS and I see some kerberos-related logs, but in this case I'm only trying to change the local unix password of the local unix user. The last two lines in the log show that chpasswd was able to obtain the user, but for some unknown reason, not the password:

2025-04-23T12:37:35.719923-04:00 phantom chpasswd: pam_unix(chpasswd:chauthtok): username [0s22xmgW] obtained
2025-04-23T12:37:35.719980-04:00 phantom chpasswd: pam_unix(chpasswd:chauthtok): password - new password not obtained

How can I get the reason behind the new password not obtained error and further debug this? I did try using strace and I see some kerberos-auth-related DNS and network requests, but again I'm not sure whether those are relevant to the failure to set the local unix password. For detail, below is the strace log : I think I do have the proper permissions on /etc/password and /etc/shadow:

ls -l /etc/shadow /etc/passwd
-rw-r--r-- 1 root root   2474 Apr 23 12:30 /etc/passwd
-rw-r----- 1 root shadow 1371 Apr 23 12:30 /etc/shadow

# grep -i password /etc/pam.d/common*:

# grep -i password /etc/pam.d/common*
/etc/pam.d/common-password:# /etc/pam.d/common-password - password-related modules common to all services
/etc/pam.d/common-password:# used to change user passwords.  The default is pam_unix.
/etc/pam.d/common-password:#hashed passwords using the yescrypt algorithm, introduced in Debian
/etc/pam.d/common-password:#used the option "sha512"; if a shadow password hash will be shared
/etc/pam.d/common-password:password     [success=2 default=ignore]      pam_krb5.so minimum_uid=1000 debug
/etc/pam.d/common-password:password     [success=1 default=ignore]      pam_unix.so obscure use_authtok try_first_pass yescrypt debug
/etc/pam.d/common-password:password     requisite                       pam_deny.so debug
/etc/pam.d/common-password:password     required                        pam_permit.so debug
/etc/pam.d/common-password:password     optional        pam_gnome_keyring.so debug
/etc/pam.d/common-password:password     optional        pam_ecryptfs.so debug

# cat /etc/nsswitch.conf:

# cat /etc/nsswitch.conf
# /etc/nsswitch.conf
#
# Example configuration of GNU Name Service Switch functionality.
# If you have the glibc-doc-reference' and info' packages installed, try:
# `info libc "Name Service Switch"' for information about this file.

passwd:         files systemd
group:          files systemd
shadow:         files systemd
gshadow:        files systemd

hosts:          files mdns4_minimal dns [NOTFOUND=return] dns mymachines myhostname
networks:       files

protocols:      db files
services:       db files
ethers:         db files
rpc:            db files

netgroup:       nis

$ grep -P "pam_unix|pam_krb" -R /etc/pam.d

common-account :17:account	[success=1 new_authtok_reqd=done default=ignore]	pam_unix.so 
common-account :25:account	required			pam_krb5.so minimum_uid=1000
common-auth :17:auth	[success=2 default=ignore]	pam_krb5.so minimum_uid=1000 debug
common-auth :18:auth	[success=1 default=ignore]	pam_unix.so nullok try_first_pass debug
common-session-noninteractive :24:session	optional			pam_krb5.so minimum_uid=1000
common-session-noninteractive :25:session	required	pam_unix.so 
runuser :5:session		required	pam_unix.so
login :8:# to disable any delay, you should add the nodelay option to pam_unix)
common-password :6:# used to change user passwords.  The default is pam_unix.
common-password :8:# Explanation of pam_unix options:
common-password :15:#`OBSCURE_CHECKS_ENAB' option in login.defs.  See the pam_unix manpage
common-password :25:password	[success=2 default=ignore]	pam_krb5.so minimum_uid=1000 debug
common-password :26:password	[success=1 default=ignore]	pam_unix.so obscure use_authtok try_first_pass yescrypt debug
common-session :23:session	optional			pam_krb5.so minimum_uid=1000
common-session :24:session	required	pam_unix.so

I have problem automounting a network drive, and I noticed the command line to do so uses commas to separate commands. I put username=xxx,password=xxxx there, ... But my password contain a comma. Does that destroy my command line input? Is the solution to enter a utc id for the comma or is it best to change my password to not contain a comma?

About SSH I know the following command works:

ssh -i id_rsa @

Of course: * The remote server must be running * The **passphrase** of the id_rsa key is requested and if it is valid then the SSH connection happens in peace Until here all is ok --- I want to know if is possible test the passphrase but without doing an attempt of connection to the remote server. It in case: * _If_ the server is down due maintenance _and_ is need it verify if the passphrase is correct **Remember**: if the server is down then is not possible execute the ssh -i id_rsa @ command. _If is possible:_ **Question** * How to verify the passphrase of a key but without doing an attempt of ssh connection? Therefore something like:

id_rsa
Write passphrase: 
Passphrase is correct

In Ubuntu (maybe other distros too) terminals it appears that password echoing gets enabled between failed password prompts revealing whatever is being typed (the password most probable). I encountered this issue where my password became visible in plaintext on the terminal when hitting enter by accident before starting typing the password. Steps to Reproduce: 1. Execute a command that requires a password e.g. sudo ls. 2. When prompted for the password, hit Enter before typing anything, then immediately start typing the password. 3. While the system validates the empty password, the keyboard input becomes visible revealing your password. 4. By the time you hit enter again the system already rejected the empty password and successfully validates the new one leading to a correct execution. Expected Behavior: When prompted for password the system should disable input echoing until the password is correctly validated, all the attempts have failed, or the operation has been canceled.

I would like to generate a random string (e.g. passwords, user names, etc.). It should be possible to specify the needed length (e.g. 13 chars). What tools can I use? (For security and privacy reasons, it is preferable that strings are generated off-line, as opposed to online on a website.)

at https://www.man7.org/linux/man-pages/man5/login.defs.5.html > With a lot of rounds, it is more difficult to brute force thepassword. But note also that more CPU resources will be needed to authenticate users. If not specified, the libc will choose the default number of rounds (5000), **which is orders of magnitude too low for modern hardware** - this item is not mentioned in the /etc/login.defs from a clean install from rhel-8.10-x86_64-dvd.iso - github mentions using at least 10000 - at least 210000 mentioned by here: https://medium.com/@crypticrisk/increase-red-hat-enterprise-linux-hashing-rounds-996394a24a30 - as well as saying as high as feasibly possible is there a way to check and observe the number of rounds in operation? anyone have first hand experience setting this value, what is highest feasibly possible? And what should one expect to happen if it is set too high? Is it a one-time thing per user when they first log in, like instant vs 2 second delay... ? second delay?