Solved: How may I assist you today?

#devops #programming #tutorial #cloud

🚀 Executive Summary

TL;DR: The ‘How may I assist you today?’ prompt, often from the MOTD system’s motd-news script, can disrupt automated SSH processes by corrupting stdout. Solutions range from a user-specific .hushlogin file to system-wide fixes like disabling the specific motd-news script via chmod -x or reconfiguring the motd-news service to prevent its execution.

🎯 Key Takeaways

The ‘How may I assist you today?’ prompt is typically a dynamic Message of the Day (MOTD) component, often motd-news on Ubuntu/Debian, not an SSH daemon feature.
Three primary methods exist to silence the prompt: creating a ~/.hushlogin file (user-specific), removing execute permissions from the offending script in /etc/update-motd.d/ (targeted system-wide), or disabling the motd-news service via /etc/default/motd-news (fleet-wide).
Unexpected output from MOTD scripts can break automation, making targeted suppression crucial for predictable and reliable system operations, especially in deployment pipelines.

Tired of the “How may I assist you today?” prompt breaking your automation and cluttering your SSH sessions? Here’s a senior engineer’s no-nonsense guide to silencing it for good across your Linux fleet.

The Ghost in the Shell: Banishing “How may I assist you today?” From Your SSH Sessions

I remember it like it was yesterday. 3 AM, a critical database migration for a major client, and my deployment script starts failing with the most bizarre errors. The script was simple: SSH into prod-db-01, run a pg\_dump, and pipe the output back to a local file. But it kept dying. After an hour of pulling my hair out, I finally ran the SSH command manually and saw it: “How may I assist you today?”. A well-intentioned, but utterly infuriating, welcome message was prepended to my stdout stream, corrupting the backup file and breaking the script. That little “helpful” prompt cost us an hour of downtime. Never again.

So, What’s Actually Happening Here?

Let’s get one thing straight: this isn’t an SSH daemon feature. SSH just gives you a shell. The “ghost” is a script, usually part of the Message of the Day (MOTD) system, that runs when your shell session starts. On systems like Ubuntu, this is often handled by a dynamic MOTD framework that pulls in various pieces of information. One of these, motd-news, is notorious for displaying promotional messages or “tips,” which can change unexpectedly and, as I learned, wreak havoc on automated processes that expect clean, predictable output.

The Fixes: From a Band-Aid to Brain Surgery

Look, I get it. You just want it gone. We’ve got a few ways to tackle this, from a quick personal fix to a permanent fleet-wide solution. Choose your weapon.

Solution 1: The Quick & Dirty (The `.hushlogin`)

If you just need to silence login messages for your own user account and don’t have sudo rights, this is your go-to. It’s the equivalent of putting on headphones in an open-plan office. It tells the login process to suppress all MOTD messages, including the annoying one.

Just create an empty file named .hushlogin in your home directory.

touch ~/.hushlogin

That’s it. Log out and log back in. Silence. The downside? It only applies to your user, and it silences everything, including potentially useful system info in the MOTD. It’s a hack, but it’s an effective one.

Solution 2: The Surgical Strike (Disarm the Offending Script)

If you have administrative rights and want to kill the message for everyone without disabling the entire MOTD system, you need to find the specific script causing the problem and neutralize it. On most Ubuntu/Debian systems, these scripts live in /etc/update-motd.d/.

The culprit is usually a script with “news” or a high number, like 99-news or similar. The cleanest way to disable it is to simply remove its execute permission.

# First, find the script (your number might be different)
ls -l /etc/update-motd.d/

# Let's say we find '98-motd-news'
sudo chmod -x /etc/update-motd.d/98-motd-news

This is my preferred method. It’s targeted, easily reversible (just chmod +x the file to restore it), and it solves the problem at the source without collateral damage.

Darian’s Pro Tip: Before you go changing permissions on system files, make sure you know what you’re disabling. A quick cat /etc/update-motd.d/98-motd-news will show you the script’s contents. If it mentions motd.ubuntu.com, you’ve found your ghost.

Solution 3: The ‘Nuclear’ Option (Reconfigure the Service)

Sometimes, a problem is a symptom of a misconfigured system. If your organization’s policy is “no external news or ads on our servers, ever,” then you should disable the service entirely. For Ubuntu’s news service, this is controlled by a configuration file.

You’ll need to edit /etc/default/motd-news and change the ENABLED flag.

# Open the file with your favorite editor
sudo nano /etc/default/motd-news

# Find this line:
ENABLED=1

# And change it to:
ENABLED=0

This prevents the service from even trying to fetch news updates. This is the “scorched earth” approach, perfect for configuration management tools like Ansible or Puppet to enforce a consistent state across your entire server fleet.

Choosing Your Path

Not sure which one to use? Here’s how I break it down for my team:


Solution	Scope	Best For	Risk
.hushlogin	Single User	Quick personal fix, no sudo access.	Low
chmod -x	System-Wide (Single Server)	Targeted removal on a few servers.	Low
Disable Service	System-Wide (Fleet Policy)	Enforcing a standard via automation.	Minimal

At the end of the day, our job is to build reliable, predictable systems. A “helpful” message that breaks a 3 AM deployment isn’t helpful; it’s a liability. Find it, understand why it’s there, and get rid of it. Now, if you’ll excuse me, I have a Jenkins pipeline to fix.