Using rsync to Mirror Data to a Different Server

Like many things on this blog, I don’t use this enough to remember the full command when I need it. Like always, don’t just copy and paste this information. Use the man pages to verify what it is that you need to do.

rsync -a -v --delete --update --stats /path/to/local/data/ user@<server-name>:/path/to/folder/

This version of the command essentially maintains ownership and permissions while allowing for file changes, including file deletions, to be copied from the local server to another server. It mirrors the data on the local server to a second server. It also provides a listing of statistics when the command has completed.

A similar command using robocopy on MS systems was posted at an earlier date and can be found here:

Ubuntu Server: Google Authenticator Configuration

Before installing and configuring the Google Authenticator on a virtual server you need to check and do a few few things to avoid getting locked out of the server. I have seen this grub configuration issue on virtual Ubuntu 18.04, 20.04, and 22.04 server installs on both HyperV and vSphere infrastructures. Also, make sure that you have multiple ssh terminals open prior to restarting sshd in the event the configuration is incorrect.

In the examples below I am only targeting admin accounts with sudo privileges – normal user accounts can log in without being prompted for a Google Authenticator code. Users logging in at the terminal will not be prompted for the authentication code. This configuration only affects ssh logins.

Grub Recovery Issue:

Prior to google authenticator setup you should check to make sure that the grub bootup menu is displayed long enough for you to capture it in the event that you need to do an emergency recovery.  Doom on you if you don’t change this behavior in the grub configuration.

vim /etc/default/grub

GRUB_DEFAULT=0
#GRUB_TIMEOUT_STYLE=hidden
GRUB_TIMEOUT=20
update-grub

Reboot and verify the grub screen appears in the terminal window for a suitable amount of time.

Google Authenticator Install and Configuration – as root:

As a security suggestion – open multiple ssh sessions to avoid possible lockout during configuration.

A second suggestion – Users should not be added to the group (i.e. sudo) until after doing the user authenticator setup if they will be doing the setup using SSH. User setup of the authenticator from the local terminal will not matter since this configuration only affects ssh logins.

Check for users in certain group, in this case “sudo”:

getent group sudo

Install Gooogle Authenticator:

apt-get install libpam-google-authenticator

Edit and add to the bottom of the file (the order of these two lines matters):

vim /etc/pam.d/sshd

# Google authenticator - only for users in sudo group
auth [success=done default=ignore] pam_succeed_if.so user notingroup sudo
# Google authenticator - prompt for code
auth required pam_google_authenticator.so

Edit the sshd config file:

vim /etc/ssh/sshd_config

# For google authenticator
# Enable challenge-response passwords
ChallengeResponseAuthentication yes

Restart ssh daemon:

systemctl restart sshd

Client Setup – As normal user:

As a normal user in the terminal:

google-authenticator

Answer the following questions:

Do you want authentication tokens to be time-based (y/n) y

In the phone app, add key or use QR code. Then enter the code from the app:

Enter code from app (-1 to skip): <code>

Copy emergency one-time use codes to a safe file.

Do you want me to update your "/home/shawn/.google_authenticator" file? (y/n) y
Do you want to disallow multiple uses of the same authentication
token? This restricts you to one login about every 30s, but it increases
your chances to notice or even prevent man-in-the-middle attacks (y/n) y
By default, a new token is generated every 30 seconds by the mobile app.
In order to compensate for possible time-skew between the client and the server,
we allow an extra token before and after the current time. This allows for a
time skew of up to 30 seconds between authentication server and client. If you
experience problems with poor time synchronization, you can increase the window
from its default size of 3 permitted codes (one previous code, the current
code, the next code) to 17 permitted codes (the 8 previous codes, the current
code, and the 8 next codes). This will permit for a time skew of up to 4 minutes
between client and server.
Do you want to do so? (y/n) n
If the computer that you are logging into isn't hardened against brute-force
login attempts, you can enable rate-limiting for the authentication module.
By default, this limits attackers to no more than 3 login attempts every 30s.
Do you want to enable rate-limiting? (y/n) y

At this point you are done. Remember to add/re-add users back to the sudo group if you removed them.

Red Hat Registration and Subscriptions

I recently decided to spend some time refreshing my Red Hat knowledge because it has been a while since I have supported production Red Hat based servers. A lot has changed. You can signup for a developer license for free and get limited access to Red Hat products.

Registration, among other things, controls the repos that the server can use.  For instance, you cannot run ‘dnf update’ until the system is registered and attached to the available desired software repositories. The ‘subscription-manager’ command exists to handle various subscription configuration situations.

For a basic free developer subscription, the following will get things started from the command line.

Show the various commands available to the subscription manager command:

subscription-manager

Subscribe and configure the available repos. This can apparently be used with kickstart as well:

subscription-manager register --username --password --auto-attach

Update the system:

dnf update

There is a lot more to subscription manager based on workflows, hosted repositories, configurations, etc. Because of different workflows, registration can also be performed via the GUI, web console, automation, etc.