Last verified: October 2026 against Red Hat's registration and Simple Content Access documentation and the RHEL 10.0 release notes.
We encountered the error message ‘*This system is not registered with an entitlement server*, *You can use “rhc” or “subscription-manager*” to register’. On CentOS Stream 9 Linux system while trying to perform package installations. For RHEL, this usually is an indication that your system is not registered with Red Hat’s subscription management service. ``` $ sudo dnf clean all Updating Subscription Management repositories. Unable to read consumer identity This system is not registered with an entitlement server. You can use "rhc" or "subscription-manager" to register. 21 files removed ``` Here is how we solved the issue on the system. Open the following file for editing: ``` sudo vi /etc/dnf/plugins/subscription-manager.conf ``` Change from `enabled=1` to `enabled=0`: ``` [main] enabled=0 # When following option is set to 1, then all repositories defined outside redhat.repo will be disabled # every time subscription-manager plugin is triggered by dnf or yum disable_system_repos=0 ``` You can then update package cache and try install your packages. For RHEL system, run the following command to register your system with the Red Hat Subscription Manager: ``` sudo subscription-manager register --usernameNo attach step is needed after registering. Simple Content Access is now the default for all Red Hat accounts, so a registered system can use the content its account is entitled to straight away. `subscription-manager attach --auto` from older guides was deprecated in RHEL 9.5 and the attach commands were removed in RHEL 10.
Check that registration was successful: ``` sudo subscription-manager status ``` To enable a specific repository, run: ``` sudo subscription-manager repos --enable=Last verified: October 2026 against Red Hat's RHEL 9 system-wide cryptographic policies guide and the sshd\_config manual.
On Red Hat Enterprise Linux 9 (RHEL 9 / Rocky Linux 9 / AlmaLinux 9 etc.), SSH configuration is primarily managed through system-wide crypto policies. Direct settings in /etc/ssh/sshd\_config for KexAlgorithms, Ciphers, etc., are often ignored unless you properly override the policy. ### 1. Recommended: Add Curve25519 (preferred) and Diffie-Hellman group exchange **Curve25519-sha256** (and its @libssh.org variant) is already enabled by default in RHEL 9 and is the modern, secure choice. diffie-hellman-group-exchange-sha256 is also generally available and reasonably secure. Create a drop-in config. Red Hat's guidance is to use a two-digit prefix smaller than 50 so the file is read before `50-redhat.conf` (which pulls in the crypto policy). sshd uses the **first** value it reads for each keyword: ```bash sudo mkdir -p /etc/ssh/sshd_config.d sudo tee /etc/ssh/sshd_config.d/49-custom-kex.conf << EOF # Only offer these KEX algorithms (the client chooses the order) KexAlgorithms curve25519-sha256,curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha256,diffie-hellman-group16-sha512 EOF ``` ### 2. Test the config ```bash sudo sshd -t ``` If no errors, reload SSH: ```bash sudo systemctl reload sshd ``` ### 3. Temporarily allow legacy algorithms (if needed for old clients/servers) Legacy algorithms (e.g., SHA-1 based ones like diffie-hellman-group1-sha1 or older group-exchange) are disabled for security. **Best temporary option** (least impact): ```bash # Append legacy KEX to OpenSSH's built-in default list sudo tee /etc/ssh/sshd_config.d/48-legacy-kex.conf << EOF KexAlgorithms +diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1 EOF ``` Because 48-legacy-kex.conf is read first, its KexAlgorithms line is used instead of the one in 49-custom-kex.conf while it exists. Test with `sudo sshd -t`, reload sshd, and delete the file when the old clients are gone. Or use the broader (but riskier) **LEGACY** crypto policy: ```bash sudo update-crypto-policies --set LEGACY sudo reboot ``` **Warning**: LEGACY weakens many other things system-wide (not just SSH). Revert with `sudo update-crypto-policies --set DEFAULT` and reboot when done. Red Hat recommends a reboot after changing the policy so every service picks it up. ### Verification commands ```bash # Available KEX algorithms ssh -Q kex # Effective configuration used by sshd sudo sshd -T | grep -E '^(kexalgorithms|ciphers|macs)' # Test connection ssh -v user@yourserver ``` ### Notes for your homelab / self-hosted setup - Prefer **drop-in files** under /etc/ssh/sshd\_config.d/ (numbered < 50, for example 49-\*.conf, so they are read before Red Hat’s 50-redhat.conf; the first value read wins). - After any change: sshd -t → systemctl reload sshd. - If you have specific old clients (e.g., very old Windows, network devices, or RHEL 6-era), the + syntax to append is safest. #### Sources - [https://docs.redhat.com/en/documentation/red\_hat\_enterprise\_linux/9/html/security\_hardening/using-the-system-wide-cryptographic-policies\_security-hardening](https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html/security_hardening/using-the-system-wide-cryptographic-policies_security-hardening) - [https://man.openbsd.org/sshd\_config](https://man.openbsd.org/sshd_config) # Linux - Commands to KnowLast verified: October 2026 against the current man pages (tar, touch, useradd, userdel, groupadd, groupdel) for RHEL / Rocky Linux.
This is a quick version of commands to be aware of. #### System information `uname -a` : Displays all system information. `hostnamectl` : Shows current hostname and related details. `lscpu` : Lists CPU architecture information. `timedatectl status` : Shows system time. #### System monitoring and management `top` : Displays real-time system processes. `htop` : An interactive process viewer (needs installation; on RHEL / Rocky Linux it comes from the EPEL repository). `df -h` : Shows disk usage in a human-readable format. `free -m` : Displays free and used memory in MB. `kill [PID]` : Terminates a process (sends SIGTERM by default). #### Running commands `| Generating public/private rsa key pair. Enter file in which to save the key (/root/.ssh/id\_rsa): /root/.ssh/id\_rsa already exists. Overwrite (y/n)? |
| Generating public/private rsa key pair. Enter file in which to save the key (/root/.ssh/id\_rsa): Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /root/.ssh/id\_rsa Your public key has been saved in /root/.ssh/id\_rsa.pub The key fingerprint is: SHA256:JoMN/cxvsqZWBHws4eyrU5Q0F0qRe//44qdrrjiQmbU root@client01 The key's randomart image is: +---\[RSA 3072\]----+ | .+=.. | | =B.+ | | ..=O | | ==+o | | = E=... | | o... oo | | ..o..++ o | | .oo+o==\*. | +----\[SHA256\]-----+ You have mail in /var/spool/mail/root |
| /usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/root/.ssh/id\_rsa.pub" The authenticity of host 'server02 (192.168.x.x)' can't be established. ED25519 key fingerprint is SHA256:oZnvrgY+2Xpd2/huaffvzLMBAgI52AMPUmq/LPLIXbE. This key is not known by any other names Are you sure you want to continue connecting (yes/no/\[fingerprint\])? yes /usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed /usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys remuser@server02's password: tput: No value for $TERM and no -T specified tput: No value for $TERM and no -T specified tput: No value for $TERM and no -T specified tput: No value for $TERM and no -T specified tput: No value for $TERM and no -T specified tput: No value for $TERM and no -T specified tput: No value for $TERM and no -T specified Number of key(s) added: 1 Now try logging into the machine, with: "ssh 'remuser@server02'" and check to make sure that only the key(s) you wanted were added. |
Continued in [Linux - Bag of Tricks (Part 2): Certificates, Databases, Disks & Boot](https://docs.thehomestack.io/books/linux/page/linux-bag-of-tricks-part-2-certificates-databases-disks-boot).
# Linux - Bag of Tricks (Part 2): Certificates, Databases, Disks & BootThis page continues [Linux - Bag of Tricks](https://docs.thehomestack.io/books/linux/page/linux-bag-of-tricks).
### Create a CERT First, you need to generate the private key and the Certificate Signing Request (CSR). You can do this via the openssl command: ```shell openssl req -nodes -newkey rsa:2048 -keyout privatekey.key -out mail.csr ``` Then, generate a signing request ```shell openssl x509 -req -days 365 -in mail.csr -signkey privatekey.key -out secure.crt ``` Create a localhost cert on the server ```shell openssl req -newkey rsa:2048 -nodes -keyout /etc/pki/tls/private/localhost.key -x509 -days 365 -out /etc/pki/tls/certs/localhost.crt ``` #### Mariadb Log Rotate If log file is large, try if the logrotate logrotate --force /etc/logrotate.d/mariadb #### MySQL Fail to Start If MySQL does not restart, it probably will not as the index of the log files will not be changed| cd /var/lib/mysql mv ib\_logfile0 ib\_logfile0.old mv ib\_logfile1 ib\_logfile1.old systemctl restart mariadb |
Last verified: October 2026 against the sudoers manual (sudo.ws).
### What is Cmnd\_Alias? Cmnd\_Alias (Command Alias) is a feature in /etc/sudoers (and files in /etc/sudoers.d/) that lets you **group multiple commands** under a single, easy-to-read name. Instead of repeating long command paths many times, you define the group once and then reference the alias name in your user permission rules. This makes the sudoers configuration: - Much cleaner and more readable - Easier to maintain (add/remove commands in one place) - Less error-prone It is one of four main alias types in sudoers: - User\_Alias — groups of users - Host\_Alias — groups of hosts - Runas\_Alias — groups of users to run as - **Cmnd\_Alias** — groups of commands (this one) ### Basic Syntax ```bash Cmnd_Alias ALIAS_NAME = /full/path/to/command1, \ /full/path/to/command2 arg1 arg2, \ /full/path/to/command3 ``` Rules: - Alias name **must** start with a capital letter and can contain uppercase letters, numbers, and underscores (e.g., API\_SERVICE, SYSTEMCTL\_API). - Always use **full absolute paths** to commands (never just systemctl). - You can continue long lines with a backslash \\. - You can include other Cmnd\_Alias names inside another one. ### Example for Your api.service (Recommended Version) Create or edit the file with `sudo visudo -f /etc/sudoers.d/10-deploy-api`: ```bash # Command alias for managing the api.service safely Cmnd_Alias API_SERVICE_CMDS = /usr/bin/systemctl start api.service, \ /usr/bin/systemctl stop api.service, \ /usr/bin/systemctl restart api.service, \ /usr/bin/systemctl status api.service # Grant the deploy user passwordless access to only these commands deployuser ALL=(ALL) NOPASSWD: API_SERVICE_CMDS ``` This is cleaner than listing the four commands directly on the user line. ### More Flexible Example (Allow Any Action on the Specific Service) If you want the deploy user to run **several** systemctl actions on api.service, do **not** use a wildcard such as `/usr/bin/systemctl * api.service`. In sudoers, wildcards in command arguments match any characters, including spaces, so that rule does not limit the user to api.service. It also matches, for example, `systemctl stop sshd.service api.service` or `systemctl edit api.service` (which opens an editor as root). List each allowed command explicitly (as in the example above), or on sudo 1.9.10 and later (check with `sudo -V`) use a regular expression, which must start with `^` and end with `$`: ```bash Cmnd_Alias API_SERVICE_CMDS = /usr/bin/systemctl ^(start|stop|restart|reload|status) api\.service$ deployuser ALL=(ALL) NOPASSWD: API_SERVICE_CMDS ``` This allows only the listed actions on api.service. ### How to Use It in Your Setup - Create the file: ```bash sudo visudo -f /etc/sudoers.d/10-deploy-api ``` - Paste the Cmnd\_Alias + user rule above. - Set correct permissions: ```bash sudo chmod 0440 /etc/sudoers.d/10-deploy-api ``` - Test it: ```bash sudo -l -U deployuser ``` 1. You should see the allowed commands listed for deployuser. Then update your PowerShell script to use deployuser (instead of root). ### Why This Is Better Than the Original Line Your original line: ```bash deployuser ALL=(ALL) NOPASSWD: /usr/bin/systemctl stop api.service, /usr/bin/systemctl restart api.service, /usr/bin/systemctl status api.service ``` Works fine, but using Cmnd\_Alias is preferred when: - You have more than 2–3 commands - You might want to add more actions later - You manage multiple services (you can create one alias per service) #### Sources - [https://www.sudo.ws/docs/man/sudoers.man/](https://www.sudo.ws/docs/man/sudoers.man/)