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.