I performed the task as asked to do in all three app servers. Still, it is failing and shows not done in app01. Though I did in app01. Please check from your end.
For this task to work, you need to, for each of the 3 app servers:
- Log into the server and become root (
sudo -i) - Edit
/etc/sshd/sshd_config - Restart sshd.
The setting you need to change is to set âPermitRootLogin noâ
Not sure what youâre doing wrong, but I just redid this task, and it works the way I described. Please try this solution â it should work for you.
It worked yesterday afterwards.
Thanks
Thank you Rob
What threw me off was, after setting âPermitRootLogin noâ, and restarting services, I wanted to test and opened a new terminal and tried to ssh via root and I wasnât getting âpermission deniedâ, I kept getting âenter root passwordâ.
That led me to enter âAllowUsersâ âDenyUsersâ config and still root ssh connection attempt kept prompting for password rather permission blocked. I dig in this so much that I gave up earlier today.
Then I ran into your solution and I did all the lab config and didnât care if âroot is still prompting for passwordâ and submitted, and lab check passed.
I wonder what can we do to see root user being blocked? or is that behavior expected?
sshd_config:
after restart sshd root session still prompting for password
I submitted lab anyways and got it passedânot sure how can we see âroot permission deniedâ
Not sure whatâs up here. The way to find out is to run ssh with the -v flag, and see what diagnostics you get. I canât tell what host youâre trying to reach â that IP would suggest stapp03, and if that wasnât what you meant, that would cause that behavior.
Yea I did ssh -v and it acted like everything is normal, no blocked / denied in logs.
By the way that behavior was consistent across all 3 StApp servers. I will test in âReal lifeâ to see if that behavior changes. Maybe some nuance with the way Lab is set up.
I just wanted to bring it up if I am missing something obvious but lab didnât seem to complain after âcheckâ.
Thank you for your response.
What was in the /root/.ssh/authorized_keys file? The default content I think is designed to prevent a root session from coming up correctly, so you need to remove that before you add the necessary public key. Could that be the issue?
I just re-did the lab and verified in all 3 APP servers â/root/.ssh/â exists but no âauthorized_keysâ in any one of them, and still getting root password prompt but lab checks out fine.
Sharing some output below for digging for another dayâŚ
"Stapp01
thor@jumphost ~$ ssh -v [email protected]
OpenSSH_8.7p1, OpenSSL 3.2.1 30 Jan 2024
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Reading configuration data /etc/ssh/ssh_config.d/50-redhat.conf
debug1: Reading configuration data /etc/crypto-policies/back-ends/openssh.config
debug1: configuration requests final Match pass
debug1: re-parsing configuration
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Reading configuration data /etc/ssh/ssh_config.d/50-redhat.conf
debug1: Reading configuration data /etc/crypto-policies/back-ends/openssh.config
debug1: Connecting to 172.16.238.10 [172.16.238.10] port 22.
debug1: Connection established.
debug1: identity file /home/thor/.ssh/id_rsa type -1
debug1: identity file /home/thor/.ssh/id_rsa-cert type -1
debug1: identity file /home/thor/.ssh/id_dsa type -1
debug1: identity file /home/thor/.ssh/id_dsa-cert type -1
debug1: identity file /home/thor/.ssh/id_ecdsa type -1
debug1: identity file /home/thor/.ssh/id_ecdsa-cert type -1
debug1: identity file /home/thor/.ssh/id_ecdsa_sk type -1
debug1: identity file /home/thor/.ssh/id_ecdsa_sk-cert type -1
debug1: identity file /home/thor/.ssh/id_ed25519 type -1
debug1: identity file /home/thor/.ssh/id_ed25519-cert type -1
debug1: identity file /home/thor/.ssh/id_ed25519_sk type -1
debug1: identity file /home/thor/.ssh/id_ed25519_sk-cert type -1
debug1: identity file /home/thor/.ssh/id_xmss type -1
debug1: identity file /home/thor/.ssh/id_xmss-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_8.7
debug1: Remote protocol version 2.0, remote software version OpenSSH_8.7
debug1: compat_banner: match: OpenSSH_8.7 pat OpenSSH* compat 0x04000000
debug1: Authenticating to 172.16.238.10:22 as ârootâ
debug1: load_hostkeys: fopen /home/thor/.ssh/known_hosts2: No such file or directory
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts: No such file or directory
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts2: No such file or directory
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256
debug1: kex: host key algorithm: ssh-ed25519
debug1: kex: server->client cipher: [email protected] MAC: compression: none
debug1: kex: client->server cipher: [email protected] MAC: compression: none
debug1: kex: curve25519-sha256 need=32 dh_need=32
debug1: kex: curve25519-sha256 need=32 dh_need=32
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: SSH2_MSG_KEX_ECDH_REPLY received
debug1: Server host key: ssh-ed25519 SHA256:xRykjGVK0vcjcDw4eUfwwzAqDKjAGlr/s/ASPpZwqAI
debug1: load_hostkeys: fopen /home/thor/.ssh/known_hosts2: No such file or directory
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts: No such file or directory
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts2: No such file or directory
debug1: Host â172.16.238.10â is known and matches the ED25519 host key.
debug1: Found key in /home/thor/.ssh/known_hosts:1
debug1: ssh_packet_send2_wrapped: resetting send seqnr 3
debug1: rekey out after 4294967296 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: ssh_packet_read_poll2: resetting read seqnr 3
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey in after 4294967296 blocks
debug1: Will attempt key: /home/thor/.ssh/id_rsa
debug1: Will attempt key: /home/thor/.ssh/id_dsa
debug1: Will attempt key: /home/thor/.ssh/id_ecdsa
debug1: Will attempt key: /home/thor/.ssh/id_ecdsa_sk
debug1: Will attempt key: /home/thor/.ssh/id_ed25519
debug1: Will attempt key: /home/thor/.ssh/id_ed25519_sk
debug1: Will attempt key: /home/thor/.ssh/id_xmss
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519,[email protected],ssh-rsa,rsa-sha2-256,rsa-sha2-512,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,[email protected],[email protected]>
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Next authentication method: gssapi-with-mic
debug1: No credentials were supplied, or the credentials were unavailable or inaccessible
No Kerberos credentials available (default cache: KEYRING:persistent:1000)
debug1: No credentials were supplied, or the credentials were unavailable or inaccessible
No Kerberos credentials available (default cache: KEYRING:persistent:1000)
debug1: Next authentication method: publickey
debug1: Trying private key: /home/thor/.ssh/id_rsa
debug1: Trying private key: /home/thor/.ssh/id_dsa
debug1: Trying private key: /home/thor/.ssh/id_ecdsa
debug1: Trying private key: /home/thor/.ssh/id_ecdsa_sk
debug1: Trying private key: /home/thor/.ssh/id_ed25519
debug1: Trying private key: /home/thor/.ssh/id_ed25519_sk
debug1: Trying private key: /home/thor/.ssh/id_xmss
debug1: Next authentication method: password
[email protected]âs password: "
STapp03
root password prompt with no authorized file
For you to ssh w/o a password, you need to have an authorized_keys file with the public key for that user. So to not be asked for a password as root, you need to paste your public key into /root/.ssh/authorized_keys. Thatâs how it works.
1 Like
I think you needed to restart the sshd server after you changed its settings.
Restart of sshd service helped. Thank you