Troubleshooting 'Failed to Negotiate Algorithms' Alerts in SSH Monitoring
Failed to Negotiate Algorithms – Critical Alerts in SSH Mode
The "failed to negotiate algorithms" exception occurs when an SSH client and server cannot agree on a common cryptographic algorithm for secure communication. This prevents the SSH connection from being established.
When an SSH connection is initiated, both client and server exchange supported cryptographic algorithms, including:
- Key Exchange Algorithms – Used to establish a secure connection.
- Ciphers – Used for encrypting data.
- Message Authentication Codes (MACs) – Ensure message integrity.
If there is no common algorithm between the Applications Manager SSH client and the monitored server, a failed to negotiate algorithms error occurs.
Troubleshooting Steps
- Log in to the target server (monitored via SSH).
- Open the SSH configuration file:
sudo vi /etc/ssh/sshd_config - Search for the Cipher, KexAlgorithm, and MACs directives.
- Ensure these directives are not commented out (remove # if present) and note down the values listed for each directive.
- In Applications Manager, navigate to Settings → Performance Polling → SSH Connection Settings
- Locate the Allowed Ciphers, Key Exchanges, and MACs and compare these with the values from the target server.
- If no common algorithm exists across the directives, a critical alert will be triggered.
Fixing the Issue
Option 1: Update Applications Manager SSH Settings
- Enable the missing algorithms in Applications Manager's SSH settings (under the respective directive).
- Restart Applications Manager for changes to take effect.
Option 2: Modify SSH Configuration on the Target Server
Create a backup of sshd_config before modifying it: sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak
- Open the SSH configuration file:sudo vi /etc/ssh/sshd_config
- Locate and update the following directives to match the supported algorithms in Applications Manager: Ciphers aes128-ctr,aes192-ctr,aes256-ctr,chacha20-poly1305@openssh.comMACs hmac-sha2-256,hmac-sha2-512,hmac-sha1KexAlgorithms curve25519-sha256,curve25519-sha256@libssh.org
,ecdh-sha2-nistp256 - Save the file and exit.
- Restart the SSH service: sudo systemctl restart sshd
- Verify SSH is running: sudo systemctl status sshd
Final Verification
- Try reconnecting to the SSH server via Applications Manager.
- If the issue persists, check system logs for SSH errors using: sudo journalctl -u sshd --no-pager | tail -n 20
New to ADSelfService Plus?
Related Articles
Why are alerts for network interfaces not raised when the configured thresholds are crossed?
In Linux SSH mode of monitoring, alerts will be triggered according to the following conditions. When the interface name starts with 'bond', alerts will be raised. When the interface has a master name as 'bond', alerts will be skipped. When an ...Real User Monitor (RUM) - Troubleshooting
If the monitor has not polled data for a long time, follow the below steps for troubleshooting. Step 1: Check the RUM Agent configuration Real User Monitor requires the RUM Agent to be installed and mapped to the Applications Manager. Refer this help ...exception during logging in Failed to negotiate a transport component
Problem :- exception during logging in Failed to negotiate a transport component [diffie-hellman-group1-sha1,diffie-hellman-group-exchange-sha1] ...Memory Usage Calculation (Linux- Telnet/SSH)
Physical Memory Utilization Calculation: Note: For version 16800 and above , the Skip option will be under Settings -> Performance Polling -> Servers -> Linux monitor type. Formula: (i) If Skip buffer and cache from monitoring (Applicable only for ...Failed login alerts for some domains
Error: Failed Login alerts are received for some specific domains. Solution: For Windows WMI monitoring, failed login alerts are received for some domains because Kerberos authentication is done first, followed by NTLM. This can be avoided by ...