When setting up passwordless SSH for cron jobs or automated tasks, the Message of the Day (MOTD) becomes an unexpected nuisance. While legally required for access warnings, these messages create false positives in cron email alerts. The core challenge is suppressing MOTD output only during automated sessions while preserving it for interactive logins.

Common approaches like ssh -q or output redirection prove inadequate because:

• MOTD gets printed to stderr, surviving basic >/dev/null redirection
• ~/.hushlogin requires server-side file modifications
• Full output suppression masks genuine errors

This solution uses SSH's LogLevel parameter combined with stderr filtering:

ssh -o LogLevel=ERROR user@host "your_command" 2>&1 | grep -v "^Last login\|^Welcome"

For cron jobs, implement this wrapper script (ssh_silent.sh):

#!/bin/bash
{
    ssh -o LogLevel=ERROR "$@" 2>&1 | \
    grep -v -e "^Last login" -e "^Welcome" -e "^.*Message of the Day" -e "^Warning:"
} || exit $?

Create dedicated SSH configurations in ~/.ssh/config:

Host production-backup
    HostName server.example.com
    User backupuser
    LogLevel ERROR
    RemoteCommand /usr/bin/script -q -c "/path/to/backup.sh" /dev/null
    RequestTTY no

Remember that MOTD suppression should never bypass legal access warnings. These techniques only apply to:

• Automated processes with pre-authorized access
• Systems where the initial interactive login already displayed the warning
• Environments with alternative compliance mechanisms

Always implement proper exit code handling in cron jobs:

0 */6 * * * /usr/local/bin/ssh_silent.sh user@host backup-command || [ $? -eq 1 ]

This ensures emails only trigger on non-zero exit codes while still filtering MOTD messages.

When setting up passwordless SSH for cron jobs, the Message of the Day (MOTD) becomes an unexpected nuisance. The legal requirement to display access warnings conflicts with practical automation needs. Here's how to solve this without compromising either requirement.

Common approaches like ssh -q or ~/.hushlogin fail because:

# These don't work for our use case:
ssh -q user@host  # Still shows MOTD
echo > ~/.hushlogin  # Requires server-side changes

The MOTD typically goes to stderr, making output redirection problematic for error detection.

For cron jobs where you need to preserve error output but suppress MOTD:

# Option 1: Filter MOTD specifically
ssh user@host "command" 2> >(grep -v '^Last login\|^Welcome\|^Unauthorized access')

# Option 2: Use SSH's internal logging control
ssh -o LogLevel=ERROR -o "UserKnownHostsFile=/dev/null" -o "StrictHostKeyChecking=no" user@host

Here's a complete cron-ready solution that maintains legal compliance while preventing false-positive email alerts:

#!/bin/bash
TEMP_ERROR_FILE=$(mktemp)

if ! ssh_output=$(ssh -o LogLevel=ERROR user@host "backup-command" 2>"$TEMP_ERROR_FILE"); then
    # Real error occurred
    cat "$TEMP_ERROR_FILE" | mail -s "SSH Backup Error" admin@example.com
    rm "$TEMP_ERROR_FILE"
    exit 1
fi

# Clean up if no error
rm "$TEMP_ERROR_FILE"

For environments where you sometimes want MOTD but not in automated scripts:

# In your ~/.ssh/config
Host production-*
    # Show MOTD for interactive sessions
    Match exec "test -t 0"
        LogLevel INFO
    # Suppress for non-interactive
    Match all
        LogLevel ERROR

This approach maintains the legal warning display for human logins while keeping automated connections clean. The warning remains visible for:

• Direct terminal logins
• Interactive sessions
• Manual SSH connections

All while preventing cron spam from automated jobs.