How To Enable SSH Login Alerts on AlmaLinux 10
Securing your AlmaLinux 10 server requires constant vigilance, and one of the most effective ways to monitor unauthorized access is through SSH login alerts. These notifications provide real-time information about who accesses your system, when they log in, and from which IP address they connect. This comprehensive guide will walk you through two proven methods to enable SSH login alerts on AlmaLinux 10, ensuring you maintain complete awareness of your server’s access patterns.
SSH (Secure Shell) remains the primary method for remote server administration, making it a critical security focal point. Every successful login represents a potential security event that administrators should monitor. Whether you manage a single server or an entire infrastructure, implementing automated SSH login notifications enhances your security posture significantly. This tutorial covers both bashrc-based and PAM (Pluggable Authentication Module) approaches, providing flexible options for different security requirements and technical environments.
Understanding SSH Login Alerts
What Are SSH Login Alerts?
SSH login alerts are automated notifications triggered whenever a user successfully authenticates to your server via SSH protocol. These alerts capture essential connection details including the username, source IP address, timestamp, and hostname. The notification system works by executing scripts at specific points during the authentication or session initialization process, then sending formatted messages to your designated email address or messaging platform.
Modern SSH monitoring goes beyond simple logging. While traditional log files in /var/log/secure record authentication events, they require active monitoring and analysis. Automated alerts bridge this gap by pushing notifications directly to administrators, enabling immediate awareness of access patterns. This proactive approach helps identify unauthorized access attempts, compromised credentials, or unusual login patterns that might indicate security breaches.
Why Enable SSH Login Alerts on AlmaLinux 10?
AlmaLinux 10 represents the latest enterprise-grade Linux distribution with enhanced security features and updated OpenSSH implementations. The operating system includes advanced security frameworks like SELinux, firewalld, and modern authentication mechanisms. Despite these robust protections, human oversight remains crucial for detecting anomalous behavior that automated systems might miss.
SSH login alerts provide multiple security benefits. First, they create an audit trail of all access events with timestamps and connection sources. This information becomes invaluable during security investigations or compliance audits. Second, alerts enable rapid incident response by notifying administrators immediately when suspicious logins occur, potentially preventing data breaches before they escalate. Third, monitoring alerts helps administrators understand normal access patterns, making anomalies more apparent. Finally, the mere presence of login monitoring serves as a deterrent to potential attackers who may reconsider their actions knowing their activities are being tracked.
AlmaLinux 10’s advanced security architecture, including its updated kernel and enhanced cryptographic libraries, provides the foundation for secure SSH operations. However, technology alone cannot guarantee security without proper monitoring and response procedures. Implementing SSH login alerts complements AlmaLinux 10’s built-in security features by adding a human oversight layer.
Prerequisites and System Requirements
System Requirements
Before implementing SSH login alerts, ensure your AlmaLinux 10 system meets basic requirements. You need a fully installed AlmaLinux 10 server, either the stable release or beta version. The system must have OpenSSH server installed and running, which typically comes pre-configured on AlmaLinux installations. Administrative access through root or sudo privileges is mandatory for modifying system configuration files and installing required packages.
Verify your SSH service status by running systemctl status sshd. The service should show as “active (running)” for the configuration to work properly. Check your current AlmaLinux version with cat /etc/almalinux-release to confirm you’re running version 10.
Required Packages
Several software packages enable email-based SSH login alerts. A Mail Transfer Agent (MTA) handles outgoing email delivery—Postfix is recommended for AlmaLinux 10 due to its reliability, security features, and extensive documentation. The mailx package provides command-line mail functionality that scripts use to send notifications. A text editor like nano or vi is necessary for editing configuration files.
Install these prerequisites using DNF, AlmaLinux’s package manager:
sudo dnf install postfix mailx -yThis command downloads and installs both Postfix and mailx along with their dependencies. The installation process typically completes within minutes depending on your network speed.
Preliminary Checks
Before making configuration changes, perform several verification steps to ensure system readiness. First, confirm SSH is listening on the correct port (default 22) using ss -tlnp | grep ssh. Second, test your mail system’s ability to send external emails by using a simple test command: echo "Test email" | mail -s "Test Subject" your-email@example.com. Check whether the test email arrives in your inbox, remembering to verify spam folders.
Review firewall configurations to ensure SMTP traffic can exit your server. Use firewall-cmd --list-all to check current firewall rules. If your server uses an external SMTP relay, ensure outbound connections to ports 25, 465, or 587 are allowed.
Always create backups before modifying critical system files. Copy configuration files using commands like sudo cp /etc/pam.d/sshd /etc/pam.d/sshd.backup to enable quick restoration if problems arise.
Method 1: Configuring SSH Login Alerts Using Bashrc
Understanding the Bashrc Method
The bashrc method leverages shell initialization files that execute automatically when users start interactive shell sessions. Every user account has a .bashrc file in their home directory that contains commands, aliases, and scripts executed upon login. By adding email notification commands to these files, administrators can trigger alerts whenever users successfully authenticate and start shell sessions.
This approach offers simplicity and ease of implementation, making it ideal for smaller environments or quick deployments. The method requires minimal system changes and doesn’t modify authentication infrastructure. However, limitations exist: the alerts only trigger after successful shell initialization, meaning they can be bypassed if attackers prevent shell startup or use non-interactive sessions. Additionally, each user requires individual configuration, which becomes cumbersome in multi-user environments.
Step 1: Installing Required Mail Packages
Begin by ensuring all necessary mail components are installed and operational. If you haven’t already installed Postfix and mailx during prerequisite setup, do so now:
sudo dnf install postfix mailx -yEnable and start the Postfix service to ensure it launches automatically on system boot:
sudo systemctl enable postfix
sudo systemctl start postfixVerify Postfix is running correctly:
sudo systemctl status postfixThe output should display “active (running)” in green text. If the service fails to start, check /var/log/maillog for error messages that might indicate configuration issues or port conflicts.
Test mail functionality before proceeding:
echo "SSH alert test from $(hostname)" | mail -s "Test Alert" your-email@example.comReplace your-email@example.com with your actual email address. Wait a few minutes and check your inbox and spam folder for the test message.
Step 2: Configuring Root User SSH Alerts
Root account monitoring is critical since root access provides unlimited system privileges. Navigate to the root home directory and edit the .bashrc file:
sudo nano /root/.bashrcScroll to the bottom of the file and add the following script:
# SSH Login Alert for root
echo "ALERT - Root SSH Login on $(hostname) at $(date)" | mail -s "Root SSH Login Alert from $(hostname)" your-email@example.comThis script creates an email notification containing the hostname and timestamp whenever root logs in via SSH. The $(hostname) command substitutes the server’s hostname, while $(date) provides the current date and time.
For more detailed alerts including IP address information, use this enhanced version:
# Enhanced SSH Login Alert for root
IP=$(echo $SSH_CONNECTION | awk '{print $1}')
echo "ALERT - Root SSH Login
Server: $(hostname)
User: root
Source IP: $IP
Time: $(date)
Connection: $SSH_CONNECTION" | mail -s "Root SSH Login Alert - $(hostname)" your-email@example.comSave the file (Ctrl+O, Enter, Ctrl+X in nano) and apply the changes by logging out and logging back in as root. Within moments, you should receive an email notification with login details.
Step 3: Configuring Regular User SSH Alerts
Standard user accounts require similar configuration. For each user account you want to monitor, edit their respective .bashrc files. For example, to configure alerts for a user named “adminuser”:
sudo nano /home/adminuser/.bashrcAdd the following script at the end:
# SSH Login Alert for adminuser
IP=$(echo $SSH_CONNECTION | awk '{print $1}')
echo "ALERT - SSH Login Detected
Server: $(hostname)
User: $(whoami)
Source IP: $IP
Time: $(date)" | mail -s "SSH Login: $(whoami) on $(hostname)" your-email@example.comThe $(whoami) command dynamically inserts the current username, allowing you to use the same script template across multiple user accounts. Save the changes and test by logging in as that user.
For environments with many users, create a script to deploy the configuration automatically:
#!/bin/bash
for user in adminuser developer webmaster; do
echo 'IP=$(echo $SSH_CONNECTION | awk '\''{print $1}'\'')
echo "SSH Login - User: $(whoami), IP: $IP, Time: $(date)" | mail -s "SSH Login Alert" admin@example.com' >> /home/$user/.bashrc
doneThis approach streamlines deployment across multiple accounts while maintaining consistent monitoring.
Step 4: Testing Bashrc-Based Alerts
Thorough testing ensures your alert system functions correctly. Log out of your current session completely and establish a new SSH connection:
ssh root@your-server-ipYou should receive an email within 1-3 minutes containing login details. If the email doesn’t arrive, check several potential issues. First, verify the mail command works manually by running the echo and mail command directly from the command line. Second, examine /var/log/maillog for delivery errors or rejection messages. Third, confirm your .bashrc file has correct syntax without typos or missing quotes.
Test from different source IP addresses to verify the IP detection works correctly. Connect from your office network, then try from a different location or VPN to ensure both connections generate accurate alerts with proper IP address information.
Check spam folders if emails seem missing—some mail providers flag automated server messages as potential spam. Consider adding your server’s IP address to your email provider’s whitelist or configuring SPF records for better deliverability.
Method 2: Implementing SSH Login Alerts Using PAM (Recommended)
Understanding PAM-Based Authentication
Pluggable Authentication Modules (PAM) provide a flexible framework for authenticating users in Linux systems. PAM sits between applications (like SSH) and authentication backends (like password files or LDAP directories), allowing administrators to customize authentication behavior without modifying applications themselves. This architecture enables sophisticated authentication workflows including two-factor authentication, password policies, and custom scripts execution.
PAM-based SSH alerts offer significant advantages over bashrc methods. Most importantly, PAM executes during the authentication phase before shell initialization, making it virtually impossible to bypass. Even if users prevent shell startup or use non-interactive sessions, PAM still triggers the notification script. Additionally, PAM provides a centralized configuration point affecting all users simultaneously, eliminating the need to modify individual user accounts.
The PAM configuration for SSH resides in /etc/pam.d/sshd, which contains directives controlling SSH authentication and session management. By adding a pam_exec.so directive, administrators can execute custom scripts at specific authentication stages.
Step 1: Creating the Notification Script
Create a dedicated directory for custom scripts if it doesn’t exist, then create the notification script:
sudo mkdir -p /usr/local/bin
sudo nano /usr/local/bin/ssh-login-notify.shAdd the following comprehensive script:
#!/bin/bash
# SSH Login Notification Script for PAM
# This script sends email alerts for SSH logins
# Check if this is a login session
if [ "$PAM_TYPE" != "open_session" ]; then
exit 0
fi
# Gather login information
USER=$PAM_USER
IP=$PAM_RHOST
HOSTNAME=$(hostname)
TIMESTAMP=$(date '+%Y-%m-%d %H:%M:%S')
# Prepare email content
EMAIL_SUBJECT="SSH Login Alert - $HOSTNAME"
EMAIL_RECIPIENT="your-email@example.com"
EMAIL_BODY="SSH LOGIN ALERT
Server Information:
- Hostname: $HOSTNAME
- Server IP: $(hostname -I | awk '{print $1}')
Login Details:
- User: $USER
- Source IP: $IP
- Timestamp: $TIMESTAMP
- PAM Service: $PAM_SERVICE
Connection Information:
$(w -h $USER | head -1)
This is an automated security notification.
If you did not initiate this login, investigate immediately.
"
# Send email notification
echo "$EMAIL_BODY" | mail -s "$EMAIL_SUBJECT" $EMAIL_RECIPIENT
# Log to syslog for record-keeping
logger -t ssh-login-alert "SSH login: user=$USER from=$IP"
exit 0This script uses PAM environment variables ($PAM_USER, $PAM_RHOST, $PAM_TYPE) to gather authentication details. The $PAM_TYPE check ensures the script only executes during session opening, preventing duplicate notifications. The script sends email notifications and also logs events to syslog for redundant record-keeping.
Replace your-email@example.com with your actual email address. Save the file after editing.
Step 2: Configuring Script Permissions
The script requires executable permissions and appropriate ownership:
sudo chmod 755 /usr/local/bin/ssh-login-notify.sh
sudo chown root:root /usr/local/bin/ssh-login-notify.shThe chmod 755 command grants read and execute permissions to all users while restricting write access to root. This prevents unauthorized modifications while allowing PAM to execute the script.
Test the script manually to verify functionality:
sudo PAM_USER=testuser PAM_RHOST=192.168.1.100 PAM_TYPE=open_session /usr/local/bin/ssh-login-notify.shThis command simulates PAM environment variables and executes the script. Check your email for the test notification. If errors occur, verify the script syntax using bash -n /usr/local/bin/ssh-login-notify.sh which checks for syntax errors without executing the script.
Step 3: Integrating with PAM Configuration
Edit the PAM configuration file for SSH:
sudo nano /etc/pam.d/sshdAdd the following line near the end of the file, preferably after other session directives but before the final pam_selinux.so line:
session optional pam_exec.so /usr/local/bin/ssh-login-notify.shUnderstanding this directive is crucial. The session type indicates the script runs during session establishment. The optional flag means authentication succeeds even if the script fails, preventing login lockouts due to script errors. The pam_exec.so module executes external programs, and the path points to your notification script.
Save the configuration file carefully—syntax errors in PAM configurations can lock you out of your system. Always maintain an active SSH session while testing PAM changes so you can revert modifications if problems occur.
Step 4: Testing PAM-Based Alerts
With an existing SSH session still open (as a safety measure), open a new terminal window and establish a fresh SSH connection:
ssh username@your-server-ipYou should receive an email notification within 1-2 minutes containing detailed login information. The notification arrives faster than bashrc-based alerts since PAM executes earlier in the authentication process.
Verify the alert contains accurate information including correct username, source IP address, and timestamp. Test with multiple users and from different source IP addresses to ensure comprehensive functionality.
Check PAM execution logs if notifications don’t arrive:
sudo tail -f /var/log/secureLook for entries related to pam_exec which indicate whether the script executed successfully. Additionally, check syslog for your custom log entries:
sudo grep ssh-login-alert /var/log/messagesStep 5: Advanced PAM Configuration Options
Fine-tune your PAM configuration for specific requirements. To send alerts only for root logins, modify your script to check the username:
if [ "$PAM_USER" != "root" ]; then
exit 0
fiFor monitoring only external IP addresses while ignoring local network connections:
if [[ $IP =~ ^192\.168\. ]] || [[ $IP =~ ^10\. ]] || [[ $IP =~ ^172\.(1[6-9]|2[0-9]|3[0-1])\. ]]; then
exit 0
fiThis regex pattern matches common private IP ranges, preventing notification spam from internal management connections.
Consider implementing rate limiting to prevent email flooding during brute force attacks or automated scanner activity. Create a temporary file to track recent notifications and only send alerts if sufficient time has elapsed since the last notification.
Configuring Email Delivery with Postfix
Installing Postfix on AlmaLinux 10
Postfix serves as the primary mail transfer agent for delivering SSH login notifications. Install Postfix if not already present:
sudo dnf install postfix -yConfigure Postfix to start automatically on boot:
sudo systemctl enable postfix
sudo systemctl start postfixVerify the service status:
sudo systemctl status postfixCheck that Postfix is listening on the correct ports:
sudo ss -tlnp | grep masterThe output should show Postfix listening on port 25 for SMTP traffic.
Basic Postfix Configuration
Edit the main Postfix configuration file:
sudo nano /etc/postfix/main.cfConfigure essential parameters for your environment. Set the hostname to match your server’s FQDN:
myhostname = server.example.com
mydomain = example.com
myorigin = $mydomainConfigure network interfaces and trusted networks:
inet_interfaces = all
mynetworks = 127.0.0.0/8, [::1]/128The inet_interfaces = all directive allows Postfix to listen on all network interfaces. The mynetworks parameter defines trusted sources—keeping this restricted to localhost prevents your server from becoming an open relay.
Set destination domains:
mydestination = $myhostname, localhost.$mydomain, localhostSave the configuration and restart Postfix:
sudo systemctl restart postfixTest mail delivery from the command line:
echo "Postfix configuration test" | mail -s "Test Email" your-email@example.comMonitor mail logs for delivery confirmation:
sudo tail -f /var/log/maillogConfiguring SMTP Relay (Optional)
Many hosting providers block outbound port 25 to prevent spam, requiring SMTP relay configuration through a trusted mail provider. Configure Postfix to use an external SMTP server like Gmail or your organization’s mail server.
Add relay configuration to /etc/postfix/main.cf:
relayhost = [smtp.gmail.com]:587
smtp_use_tls = yes
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_sasl_security_options = noanonymous
smtp_tls_CAfile = /etc/pki/tls/certs/ca-bundle.crtCreate the password file for SMTP authentication:
sudo nano /etc/postfix/sasl_passwdAdd your SMTP credentials:
[smtp.gmail.com]:587 username@gmail.com:app-passwordFor Gmail, use an app-specific password rather than your regular password. Generate app passwords through your Google Account security settings.
Secure and hash the password file:
sudo chmod 600 /etc/postfix/sasl_passwd
sudo postmap /etc/postfix/sasl_passwdRestart Postfix to apply changes:
sudo systemctl restart postfixTest relay functionality by sending another test email and monitoring delivery.
Firewall Configuration
Ensure AlmaLinux 10’s firewall allows mail traffic. If using local delivery, no firewall changes are needed. For external SMTP relay, allow outbound connections:
sudo firewall-cmd --permanent --add-service=smtp
sudo firewall-cmd --permanent --add-port=587/tcp
sudo firewall-cmd --reloadVerify firewall rules:
sudo firewall-cmd --list-allCheck SELinux contexts if mail delivery fails despite correct Postfix configuration:
sudo setsebool -P httpd_can_sendmail onThis command allows processes to send email through the local mail system.
Security Best Practices for SSH on AlmaLinux 10
Hardening SSH Configuration
SSH login alerts complement broader security measures. Edit the SSH configuration file to implement security hardening:
sudo nano /etc/ssh/sshd_configDisable password authentication in favor of SSH key-based authentication:
PasswordAuthentication no
PubkeyAuthentication yesDisable root login via SSH:
PermitRootLogin noChange the default SSH port to reduce automated attack exposure:
Port 2222Remember to update firewall rules when changing SSH ports. Limit SSH access to specific users:
AllowUsers adminuser developerImplement connection rate limiting to prevent brute force attacks:
MaxAuthTries 3
MaxSessions 2Save changes and restart SSH:
sudo systemctl restart sshdAlmaLinux 10 Specific Security Features
AlmaLinux 10 includes enhanced security features that administrators should leverage. The updated SELinux policies provide mandatory access controls preventing unauthorized system modifications. Verify SELinux is enabled and enforcing:
sudo getenforceThe output should show “Enforcing”. If SELinux is disabled, enable it by editing /etc/selinux/config and setting SELINUX=enforcing.
AlmaLinux 10 introduces updated system roles for managing services through Ansible playbooks, simplifying secure configuration deployment across multiple servers. The enhanced firewalld integration provides robust network filtering with zones and rich rules.
Implement fail2ban alongside SSH login alerts for automated response to brute force attacks:
sudo dnf install fail2ban -y
sudo systemctl enable --now fail2banConfigure fail2ban to monitor SSH logs and ban repeat offenders automatically.
Monitoring and Logging Best Practices
Regularly review SSH login alert emails to identify patterns and anomalies. Create email filters to organize alerts by server or user, making pattern analysis easier. Correlate email alerts with system logs in /var/log/secure for comprehensive security analysis:
sudo grep 'Accepted' /var/log/secureImplement log rotation to prevent log files from consuming excessive disk space:
sudo nano /etc/logrotate.d/sshdConfigure appropriate retention periods based on your compliance requirements.
Consider centralized logging solutions like rsyslog forwarding to aggregate logs from multiple AlmaLinux 10 servers. This approach simplifies security monitoring in multi-server environments.
Alert Management
Create email rules to highlight suspicious login patterns such as logins from unknown countries or unusual times. Set up mobile notifications for critical alerts requiring immediate attention. Establish documented procedures for responding to suspicious login alerts, including steps for investigating potential compromises, changing passwords, and escalating to security teams.
Implement alert aggregation for environments with multiple servers to prevent notification overload. Consider using tools that consolidate multiple server alerts into periodic summary reports.
Troubleshooting Common Issues
Email Delivery Problems
Email delivery failures represent the most common issue with SSH login alerts. If notifications don’t arrive, begin by checking spam folders—many email providers flag automated server messages as potential spam. Add your server’s IP address or domain to your email provider’s whitelist.
Verify Postfix service status:
sudo systemctl status postfixIf Postfix isn’t running, start it and check logs for error messages. Examine mail logs for delivery failures:
sudo tail -100 /var/log/maillogLook for error codes and rejection messages indicating why delivery failed. Common issues include DNS problems, firewall blocks, or authentication failures.
Test mail functionality independently from SSH alerts:
echo "Direct test" | mail -s "Test Subject" your-email@example.comIf this test fails, the problem lies with mail configuration rather than SSH alert scripts. Check DNS configurations ensuring your server has proper PTR records:
host your-server-ipMany mail providers reject emails from servers without proper reverse DNS.
Script Execution Failures
If alerts don’t trigger despite successful SSH logins, verify script execution. For bashrc-based alerts, check that you’re establishing interactive shell sessions rather than non-interactive ones. Test by running the alert command manually:
source ~/.bashrcThis command executes bashrc contents, triggering alerts if the script works correctly.
For PAM-based alerts, verify script permissions:
ls -la /usr/local/bin/ssh-login-notify.shThe script should be executable (755 permissions) and owned by root. Test script execution manually with simulated PAM variables as described earlier.
Check bash syntax in your scripts:
bash -n /usr/local/bin/ssh-login-notify.shThis command reports syntax errors without executing the script.
PAM-Specific Issues
PAM configuration errors can prevent SSH login entirely, requiring careful testing. Always maintain an active SSH session when modifying PAM files. If you accidentally lock yourself out, console access allows recovery.
Verify PAM configuration syntax using:
sudo pam-config-test sshdThough this command might not exist on all systems, checking PAM logs provides similar information:
sudo grep pam_exec /var/log/secureLook for error messages indicating why script execution failed. Common issues include incorrect script paths, permission problems, or SELinux denials.
Check SELinux alerts:
sudo ausearch -m avc -ts recentSELinux might block script execution from PAM contexts. Create appropriate SELinux policies or temporarily set SELinux to permissive mode for testing:
sudo setenforce 0Remember to return to enforcing mode after resolving issues.
Performance Considerations
High-traffic servers might generate excessive alert emails. Implement rate limiting in your notification scripts to prevent email flooding. Create a timestamp file and only send alerts if sufficient time elapsed since the last notification:
LAST_ALERT="/tmp/last-ssh-alert-$PAM_USER"
CURRENT_TIME=$(date +%s)
RATE_LIMIT=300 # 5 minutes
if [ -f "$LAST_ALERT" ]; then
LAST_TIME=$(cat "$LAST_ALERT")
TIME_DIFF=$((CURRENT_TIME - LAST_TIME))
if [ $TIME_DIFF -lt $RATE_LIMIT ]; then
exit 0
fi
fi
echo $CURRENT_TIME > $LAST_ALERTThis code prevents repeated alerts for the same user within a 5-minute window.
Optimize script execution time by removing unnecessary commands or external tool calls. Every millisecond counts in authentication paths—inefficient scripts can slow login processes noticeably.
Alternative Notification Methods
Beyond Email Notifications
Email notifications work well for many environments, but alternative methods offer advantages for specific use cases. Telegram bots provide instant mobile notifications without relying on email infrastructure. Create a Telegram bot through BotFather and obtain an API token, then modify your notification script to use curl for sending messages to Telegram:
TOKEN="your-bot-token"
CHAT_ID="your-chat-id"
MESSAGE="SSH Login: $USER from $IP on $(hostname)"
curl -s -X POST "https://api.telegram.org/bot$TOKEN/sendMessage" \
-d chat_id="$CHAT_ID" \
-d text="$MESSAGE"Signal messenger offers encrypted messaging with similar notification capabilities. Third-party services like Pushover provide dedicated push notification infrastructure with mobile apps for iOS and Android.
Slack and Microsoft Teams integration enables team-wide visibility of server access events. Create webhook URLs in these platforms and post JSON-formatted messages using curl:
WEBHOOK_URL="your-slack-webhook-url"
curl -X POST -H 'Content-type: application/json' \
--data "{\"text\":\"SSH Login: $USER from $IP\"}" \
$WEBHOOK_URLSyslog forwarding to Security Information and Event Management (SIEM) systems provides enterprise-grade monitoring. Configure rsyslog to forward SSH authentication events to centralized logging platforms for correlation analysis with other security events.
Mobile Push Notifications
Self-hosted push notification services like Gotify provide privacy-focused alternatives to commercial services. Install Gotify on your infrastructure and use its API for sending push notifications to mobile devices. Ntfy offers another self-hosted option with minimal resource requirements.
Commercial services like Pushover provide reliable push notifications with simple API integration and mobile applications. These services often include features like priority levels, custom sounds, and delivery confirmation.
Congratulations! You have successfully setup SSH Login Alerts. Thanks for using this tutorial to configure SSH Login Alerts on AlmaLinux OS 10 system. For additional help or useful information, we recommend you check the official Fedora website.
