login on-failure
Log authentication failures for security auditing and to detect credential stuffing or brute-force attacks against network devices.
Definition: login on-failure is a Cisco IOS global config command. Enables syslog logging of failed login attempts, recording the username attempted, source IP address, and timestamp. Used for security monitoring and brute-force detection.
Overview
The `login on-failure log` command is a security feature in Cisco IOS that enables logging of failed login attempts to the syslog server. When configured globally, this command instructs the router or switch to generate a syslog message each time a login attempt fails, regardless of the method (console, VTY, AUX, or HTTP/HTTPS). This is critical for security monitoring and auditing because it provides visibility into potential brute-force attacks, unauthorized access attempts, or misconfigured credentials.
The underlying concept is that authentication failures are a key indicator of security threats; by logging them, network administrators can detect patterns, trigger alerts, and investigate incidents. This command is typically used in conjunction with AAA (Authentication, Authorization, and Accounting) services, but it also works with local authentication. It is often paired with `login on-success log` to log successful logins as well, providing a complete audit trail.
Compared to alternatives like `debug aaa authentication` or `debug login`, the `login on-failure log` command is less intrusive and more suitable for production environments because it generates syslog messages rather than verbose debug output that can impact router performance. It fits into the broader security configuration workflow after setting up authentication methods (e.g., local username/password or AAA server) and before enabling logging to a syslog server. Important IOS behavior: The command is available in global configuration mode and requires privilege level 15 to configure.
It does not affect the running configuration in terms of performance; the logging overhead is minimal. The syslog messages are sent to the configured logging hosts (e.g., via `logging host`). The default severity level for these messages is 5 (notification), but this can be adjusted with `logging console` or `logging monitor` commands.
The command is supported in IOS 12.0 and later, including IOS-XE, but not in NX-OS or IOS-XR (which have equivalent but different commands). It is important to note that this command only logs failures; it does not lock accounts or trigger any other action. For account lockout, additional commands like `login block-for` or AAA rate-limiting are needed.
The command is persistent across reloads once saved to startup configuration. A common mistake is forgetting to configure a syslog server; without it, the logs are only visible in the router's buffer (via `show logging`), which may not be sufficient for long-term auditing. Another mistake is assuming the command logs all failures, including those from HTTP/HTTPS; it does, but only if HTTP/HTTPS authentication is configured.
The command is part of the 'security' category and is often required for compliance with standards like PCI-DSS or HIPAA that mandate logging of authentication failures.
login on-failure log [every <number>]When to Use This Command
- Security monitoring — detect repeated failed logins from the same source IP
- Compliance requirement — many frameworks require logging of authentication failures
- Forensics — determine if an account was targeted during an incident
- Combined with login block-for to implement automatic lockout after failures
Command Examples
Enable login failure logging with lockout
Router(config)# login on-failure log Router(config)# login on-success log Router(config)# login block-for 120 attempts 5 within 60 Router(config)# end ! Sample syslog output: %SEC_LOGIN-4-LOGIN_FAILED: Login failed [user: admin] [Source: 192.168.1.100] [localport: 22] [Reason: Login Authentication Failed] at 14:23:05 UTC Sat Jun 27 2026
Understanding the Output
Syslog message shows username attempted, source IP, port (22=SSH, 23=Telnet), and reason. login block-for 120 attempts 5 within 60 = block all logins for 120 seconds if 5 failures occur within 60 seconds. login on-success log records successful logins as well. Both appear in show log output.
Configuration Scenarios
Enable failed login logging on a branch router with local authentication
A branch router uses local usernames and passwords for administrative access. The security team needs to monitor failed login attempts to detect brute-force attacks. The router should send syslog messages to a central syslog server at 192.168.1.100.
Topology
R1(Gi0/0)---192.168.1.0/24---(Gi0/0) Syslog ServerSteps
- 1.Step 1: Enter global configuration mode: Router> enable; Router# configure terminal
- 2.Step 2: Configure a local username and password: Router(config)# username admin secret Cisco123
- 3.Step 3: Enable logging of failed logins: Router(config)# login on-failure log
- 4.Step 4: (Optional) Enable logging of successful logins for completeness: Router(config)# login on-success log
- 5.Step 5: Configure syslog server: Router(config)# logging host 192.168.1.100
- 6.Step 6: Set logging severity to include notifications (default is already 5): Router(config)# logging trap notifications
- 7.Step 7: Exit and save: Router(config)# end; Router# write memory
! Full IOS config block Router(config)# username admin secret Cisco123 Router(config)# login on-failure log Router(config)# login on-success log Router(config)# logging host 192.168.1.100 Router(config)# logging trap notifications Router(config)# end
Verify: Verify with `show logging` to see syslog messages. Expected output includes lines like: `%SEC_LOGIN-5-LOGIN_FAILED: Login failed [user: admin] [Source: 10.0.0.1] [localport: 23] at 12:34:56 UTC Mon Mar 1 2021`
Watch out: If no syslog server is configured, the logs are only stored in the router's buffer (viewable with `show logging`), which is limited and lost on reload. Always configure a syslog server for persistent logging.
Enable failed login logging with AAA authentication on a core switch
A core switch authenticates administrative users via a RADIUS server at 10.10.10.5. The network team wants to log all failed login attempts to the RADIUS server's syslog and also to a local syslog server at 172.16.1.10 for redundancy.
Topology
SW1(Vlan1)---10.10.10.0/24---(Gi0/0) RADIUS Server; SW1(Gi0/1)---172.16.1.0/24---(Gi0/0) Syslog ServerSteps
- 1.Step 1: Enter global configuration mode: Switch> enable; Switch# configure terminal
- 2.Step 2: Configure AAA new-model: Switch(config)# aaa new-model
- 3.Step 3: Configure RADIUS server: Switch(config)# radius server RADIUS; Switch(config-radius-server)# address ipv4 10.10.10.5 auth-port 1812 acct-port 1813; Switch(config-radius-server)# key CiscoKey123
- 4.Step 4: Configure AAA authentication for login: Switch(config)# aaa authentication login default group radius local
- 5.Step 5: Enable logging of failed logins: Switch(config)# login on-failure log
- 6.Step 6: Configure syslog servers: Switch(config)# logging host 172.16.1.10; Switch(config)# logging host 10.10.10.5
- 7.Step 7: Exit and save: Switch(config)# end; Switch# write memory
! Full IOS config block Switch(config)# aaa new-model Switch(config)# radius server RADIUS Switch(config-radius-server)# address ipv4 10.10.10.5 auth-port 1812 acct-port 1813 Switch(config-radius-server)# key CiscoKey123 Switch(config-radius-server)# exit Switch(config)# aaa authentication login default group radius local Switch(config)# login on-failure log Switch(config)# logging host 172.16.1.10 Switch(config)# logging host 10.10.10.5 Switch(config)# end
Verify: Verify with `show logging` and check the syslog server for messages. Expected syslog message: `%SEC_LOGIN-5-LOGIN_FAILED: Login failed [user: admin] [Source: 192.168.1.100] [localport: 22] at 12:34:56 UTC Mon Mar 1 2021`
Watch out: When using AAA, ensure the RADIUS server is reachable and the shared key matches. If the RADIUS server is unreachable, the switch falls back to local authentication (if configured), and failed logins are still logged. Also, the syslog message includes the source IP of the login attempt, which is useful for identifying attackers.
Troubleshooting with This Command
The `login on-failure log` command is primarily a logging tool, but it can be used for troubleshooting authentication issues. Healthy output in the syslog or `show logging` shows occasional failed login messages, typically from legitimate users mistyping passwords. Problem indicators include a high frequency of failed login messages from the same source IP, which suggests a brute-force attack.
Also, if you see failed login messages for usernames that do not exist (e.g., 'root', 'admin123'), it indicates scanning activity. When troubleshooting, focus on the 'Source' field in the syslog message, which shows the IP address of the client attempting to log in. The 'localport' field indicates the service (23 for Telnet, 22 for SSH, 80 for HTTP, 443 for HTTPS).
Common symptoms this command helps diagnose include: (1) Users unable to log in – check if failed login messages appear for their username; if not, the issue may be network connectivity or service availability. (2) Intermittent authentication failures – correlate with RADIUS server availability or local user database issues. (3) Security incidents – identify attacking IPs and block them with ACLs or `login block-for`. A step-by-step diagnostic flow: Step 1: Enable logging with `login on-failure log` if not already enabled. Step 2: Monitor logs in real-time with `terminal monitor` and `show logging | include LOGIN_FAILED`.
Step 3: Identify the source IP and username from the messages. Step 4: Check if the source IP is legitimate (e.g., known admin workstation) or external. Step 5: If external, consider implementing ACLs or `login block-for` to rate-limit attempts.
Step 6: Verify AAA server connectivity if using remote authentication – use `test aaa group radius user password` or `debug radius authentication`. Step 7: Check local user database with `show running-config | include username`. Correlate with other commands: `show users` shows currently logged-in users; `show ip ssh` shows SSH sessions; `debug aaa authentication` provides detailed authentication flow but is resource-intensive.
The `login on-failure log` command is lightweight and should be left enabled in production. If you notice that failed logins are not being logged, verify that the command is present in the running config (`show running-config | include login on-failure`). Also ensure that logging is enabled globally (`logging on`) and that syslog servers are configured.
If logs are not reaching the syslog server, check network connectivity and UDP port 514 (default syslog port). The command itself does not have any debug equivalent; it simply generates syslog messages. For more granular troubleshooting, use `debug ip ssh` or `debug telnet` to see the actual authentication exchange, but be cautious in production.
CCNA Exam Tips
CCNA exam: login on-failure log is a security hardening command. login block-for is the companion brute-force protection
Know that these require login local or AAA authentication configured on vty lines to be meaningful
Without authentication configured on the lines, there are no failures to log
Common Mistakes
Enabling login on-failure without configuring authentication on vty lines — nothing to log
Forgetting login on-success log to also track successful logins for forensics
Not forwarding syslog to a remote server — device local log is circular and may be overwritten
login on-failure vs service password-encryption
Both login on-failure and service password-encryption are global configuration commands that enhance security, but they address different aspects: login on-failure monitors authentication attempts, while service password-encryption protects stored passwords. They are often considered together because they are both simple to enable and commonly used in initial security hardening.
| Aspect | login on-failure | service password-encryption |
|---|---|---|
| Scope | Failed login events | Plaintext passwords in config |
| Configuration mode | Global config | Global config |
| Effect | Enables syslog logging of failed logins | Encrypts passwords with weak Type 7 cipher |
| Persistence | Persists in running config (no-show command hides it) | Persists in running config and is visible |
| Reversibility | Disabled with 'no login on-failure' | Cannot be reversed; passwords remain encrypted |
| Typical use | Brute-force attack detection and audit trail | Basic password obfuscation in configuration files |
Use login on-failure when you need to monitor and log failed login attempts for security auditing or brute-force detection.
Use service password-encryption when you want to prevent casual viewing of plaintext passwords in the configuration, but understand it is not strong encryption.
Platform Notes
In IOS-XE (e.g., Catalyst 9000 switches, ISR 4000 routers), the `login on-failure log` command is supported with identical syntax and behavior. However, IOS-XE uses a newer syslog message format that includes additional fields like 'Session ID'. For example: `%SEC_LOGIN-5-LOGIN_FAILED: Login failed [user: admin] [Source: 10.0.0.1] [localport: 22] [Reason: Invalid password] at 12:34:56 UTC Mon Mar 1 2021`.
The command is available in IOS 12.0 and later, including 15.x and 16.x. In NX-OS (e.g., Nexus switches), the equivalent command is `login on-failure log` as well, but it is configured under the `username` or `aaa` context? Actually, NX-OS uses `login on-failure log` globally, but the syslog message format differs: `%AAA-5-LOGIN_FAILED: Login failed for user 'admin' from source 10.0.0.1 on vty0`.
NX-OS also supports `login on-success log`. In IOS-XR (e.g., ASR 9000), the command is not available; instead, use `logging events login failure` under the appropriate configuration mode. For ASA firewalls, the equivalent is `logging enable` and `logging asdm informational` or `logging buffered informational`, but ASA does not have a specific command for failed login logging; instead, it logs authentication failures automatically when AAA is configured.
In older IOS versions (12.x), the syslog message might be `%SEC-6-IPACCESSLOGP` or similar, but the `login on-failure log` command was introduced in 12.2(15)T. Always verify the exact syntax with `?` in the CLI. The command is not available in IOS-XR; use `logging events login failure` instead.
In IOS-XE, the command works identically to classic IOS. There are no differences in output format between 15.x and 16.x. The command is persistent across reloads and is part of the running configuration.
Related Commands
banner motd
Configures a Message of the Day banner that is displayed to all users who connect to the device before authentication. Used for legal warnings about unauthorized access.
service password-encryption
Enables Cisco Type 7 (Vigenère cipher) encryption for all plaintext passwords stored in the running configuration, including line passwords, CHAP passwords, and username passwords not already using stronger hashing.
show aaa servers
Displays statistics for all AAA servers (RADIUS and TACACS+) configured on the device including server status, request/response counts, authentication success and failure rates, and round-trip times.
username privilege
Creates a local user account with a specific privilege level (0-15) and a hashed password stored in the configuration. Privilege 15 grants full access equivalent to enable mode.
Practice for the CCNA 200-301
Test your knowledge with practice questions covering all CCNA 200-301 exam domains.
Practice CCNA 200-301 Questions