How to fix Connection closed by invalid user username hostname port in SSH

SSHBEGINNERMEDIUM

The 'Connection closed by invalid user' message appears in sshd server logs when someone attempts to SSH into your server using a username that doesn't exist on the system. This is a security event (usually an automated attack) and is normal on any publicly accessible SSH server.

What this error means

The "Connection closed by invalid user" message is logged by the SSH server daemon (sshd) when it receives an authentication attempt using a username that doesn't exist in the system's user database or is not allowed to log in via SSH. This is **not an error on your client machine** - it's information logged on the **SSH server** showing that someone (or something) tried to connect with invalid credentials. Key points: - This happens automatically on every internet-connected SSH server - Hackers use automated tools to scan for weak credentials - It is not a configuration problem unless you cannot access YOUR OWN server - The connections are automatically rejected and closed by sshd - This is normal security noise, not a system problem

How to fix "Connection closed by invalid user username hostname port"

1Verify your own access still works

First, confirm that YOU can still log in with your valid username and credentials:

bash

# From your local machine
ssh [email protected]

# This should work normally if you have correct credentials

If you CAN log in successfully, the 'invalid user' messages are just failed external attacks and are not affecting your access.

2Review server logs to understand the pattern

Check the SSH server logs to see the extent of the attack:

bash

# View recent invalid user attempts
sudo grep "Invalid user" /var/log/auth.log | tail -20

# Count total attempts by IP
sudo grep "Invalid user" /var/log/auth.log | awk '{print $(NF-2)}' | sort | uniq -c | sort -rn | head -10

# View entries from the last hour
sudo grep "Invalid user" /var/log/auth.log | tail -100

Expected output:

bash

Invalid user admin from 203.0.113.45 port 54321
Invalid user root from 198.51.100.89 port 12345
Invalid user test from 192.0.2.200 port 9999

These are from attackers, not actual problems.

3Harden SSH to reduce attack impact

Even though invalid user attempts are harmless, you should harden SSH to reduce noise and improve security:

bash

# Edit SSH server configuration
sudo nano /etc/ssh/sshd_config

Add or modify these settings:

bash

# Disable root login (very common target)
PermitRootLogin no

# Only accept public key authentication
PubkeyAuthentication yes
PasswordAuthentication no

# Reduce MaxAuthTries to fail faster on wrong passwords
MaxAuthTries 3

# Disable empty passwords
PermitEmptyPasswords no

# Use only modern SSH protocol
Protocol 2

# Specify allowed key types (Ed25519 and RSA-4096 are most secure)
HostKeyAlgorithms ssh-ed25519,rsa-sha2-512,rsa-sha2-256
PubkeyAcceptedKeyTypes ssh-ed25519,rsa-sha2-512,rsa-sha2-256

Then restart SSH:

bash

sudo systemctl restart sshd

4Change SSH port to reduce attack frequency

Moving SSH from port 22 (the default) to an unpredictable high port significantly reduces automated attacks:

bash

# Edit SSH configuration
sudo nano /etc/ssh/sshd_config

# Find the line "Port 22" and change it:
Port 2222  # or any high number > 1024 (avoid common ports like 3389, 5900)

Restart SSH:

bash

sudo systemctl restart sshd

Now connect using the new port:

bash

ssh -p 2222 [email protected]

# Or configure it permanently in ~/.ssh/config
Host myserver
  HostName your-server.com
  Port 2222
  User username

Important: Make sure your firewall allows the new port and update any deployment scripts that use SSH.

5Use fail2ban to automatically block attackers

fail2ban monitors logs and temporarily bans IPs that make too many failed attempts:

bash

# Install fail2ban
sudo apt-get update
sudo apt-get install fail2ban

# Start the service
sudo systemctl enable fail2ban
sudo systemctl start fail2ban

Configure it for SSH:

bash

# Create a local jail configuration
sudo nano /etc/fail2ban/jail.local

Add:

bash

[DEFAULT]
bantime = 3600
findtime = 600
maxretry = 3

[sshd]
enabled = true
port = ssh
logpath = /var/log/auth.log
maxretry = 3

Restart fail2ban:

bash

sudo systemctl restart fail2ban

# Check banned IPs
sudo fail2ban-client status sshd

6Use key-based authentication only

Disable password authentication entirely - use SSH keys instead:

bash

# On your server, edit sshd_config
sudo nano /etc/ssh/sshd_config

# Make sure these lines are set:
PubkeyAuthentication yes
PasswordAuthentication no

Then restart:

bash

sudo systemctl restart sshd

Now attackers cannot guess your password because passwords are not accepted:

bash

# This will fail
ssh [email protected]   # No password prompt, connection refused

# This will work
ssh -i ~/.ssh/id_ed25519 [email protected]

7Allow SSH only from specific IPs

If you always connect from the same IP address, restrict SSH access to that IP:

bash

# Using ufw (Ubuntu)
sudo ufw allow from 203.0.113.100 to any port 22/tcp

# For multiple IPs
sudo ufw allow from 203.0.113.100 to any port 22/tcp
sudo ufw allow from 203.0.113.101 to any port 22/tcp

# Check the rules
sudo ufw status

Or using SSH config (/etc/ssh/sshd_config):

bash

# Allow only from specific IPs
ListenAddress 0.0.0.0
AllowUsers [email protected] [email protected]

Then restart:

bash

sudo systemctl restart sshd

8Monitor ongoing attacks

Keep an eye on attack patterns to detect changes:

bash

# Watch for new attacks in real-time
sudo tail -f /var/log/auth.log | grep "Invalid user"

# Or use journalctl on systemd systems
sudo journalctl -u sshd -f

# Generate a daily report of attack summary
sudo grep "Invalid user" /var/log/auth.log | wc -l  # Total attempts

# Top attacking IPs
sudo grep "Invalid user" /var/log/auth.log | awk '{print $(NF-2)}' | sort | uniq -c | sort -rn | head -20

# Most commonly attempted usernames
sudo grep "Invalid user" /var/log/auth.log | awk '{print $3}' | sort | uniq -c | sort -rn | head -20

This helps you identify if attacks are increasing or coming from new sources.

9Consider using a VPN or bastion host

For additional security, access SSH through a VPN or jump host:

bash

# Connect through a jump host (bastion)
ssh -J jump-host.com [email protected]

# Or configure in ~/.ssh/config
Host bastion
  HostName jump-host.com
  User username
  IdentityFile ~/.ssh/bastion_key

Host internal-server
  HostName internal-ip
  User username
  ProxyJump bastion
  IdentityFile ~/.ssh/internal_key

Then connect normally:

bash

ssh internal-server

Or use a VPN:

bash

# Connect to VPN first
sudo openvpn --config client.ovpn

# Then SSH is only available through VPN
ssh username@internal-ip

Advanced notes

Why this is normal:

Any server with a public IP address on the internet receives constant automated SSH probing. Major platforms like AWS, Azure, Google Cloud report thousands of failed login attempts per day as the norm. This is not a sign of a breach - it's just the background radiation of internet attacks.

Understanding the attack process:

Automated scanners work in stages:
1. Port scanning (checking if port 22 is open)
2. Banner grabbing (identifying SSH version)
3. Username enumeration (trying common usernames: root, admin, ubuntu, pi)
4. Password spraying (trying weak passwords against discovered usernames)
5. Keylogging (if they gain access)

The "Invalid user" message appears at stage 3 - the connection is immediately rejected because the username doesn't exist. This is a failed attempt and harmless.

The difference between "Invalid user" and "Failed password":

- "Invalid user": Username doesn't exist in /etc/passwd
- "Failed password": Username exists but wrong password was provided

Seeing "Invalid user" frequently is actually a GOOD sign - it means attackers are getting rejected early without reaching the authentication stage.

Security best practices in order of importance:

1. Use SSH keys, not passwords - eliminates guessing attacks entirely
2. Disable root login - most automated attacks target root account
3. Use fail2ban - rate limits failed attempts (basic but effective)
4. Change default port - reduces automated scanning (security through obscurity, but helps with noise)
5. Restrict source IPs - only if your IP is static
6. Use VPN/bastion - excellent for defense-in-depth

Tools to monitor SSH security:

bash

# Watch for successful logins
sudo grep "Accepted" /var/log/auth.log

# Look for permission denied (password auth attempts)
sudo grep "Permission denied" /var/log/auth.log

# Find any successful key-based logins
sudo grep "Accepted publickey" /var/log/auth.log

# Check for repeated failed attempts from same IP
sudo grep "Failed password" /var/log/auth.log | awk '{print $(NF-3)}' | sort | uniq -c | sort -rn

Should you be concerned?

- If you see "Invalid user" messages: No, this is normal noise
- If you see "Accepted password" from unknown IPs: Yes, investigate immediately
- If you cannot log in with your credentials: Critical, your account may be compromised

Check for unauthorized access:

bash

# Successful logins in last 24 hours
sudo grep "Accepted" /var/log/auth.log | grep -v "grep"

# If you see IPs/users you don't recognize, change your password/keys immediately

How to fix Connection closed by invalid user username hostname port in SSH

What this error means

Typical symptoms

Common causes

How to fix "Connection closed by invalid user username hostname port"

Advanced notes

Related errors

Official resources & further reading