Viewing SSH local Destination IP for authentication attempts

[SCDow]

Hi folks,

Raising within this community board because it had the most hits for SSH questions,

I have a number of "%SEC_LOGIN-4-LOGIN_FAILED" failed SSH authentication attempts which I've tracked down to being a scanning-type behaviour from a customer's 3rd party service provider. Unfortunately it's so persistent, and widespread, that it has backed a number of routers into Quiet Mode.

This isn't the only affected router, and there are a number of solutions, however just from an intellectual standpoint let's say I'm going to ask the 3rd party to stop spraying a certain range of IPs.

When I check the logs I get:
[Sanitised]

"000000: Oct 02 2025 00:00:00.000 NTP: %SEC_LOGIN-4-LOGIN_FAILED: Login failed [user: 3RD_PARTY] [Source: 10.0.0.1] [localport: 22] [Reason: Login Authentication Failed] at 00:00:00 NTP Thu Oct 02 2025"

QUESTION:
Is there a way for me to see what destination (local) IP this address was attempting to log on to? I have 3 management loopbacks and an interface IP I believe they could be hitting.

I've searched "ip ssh debug" command sample output, and scoured many threads, but cannot see what I need.

I also realise this may be a question that's too dumb to have been asked, so please, if this is obvious just spell it out to me...

Thank you in advance!

[Rob Ingram]

@SCDow An ACL with logging should capture the source/destination IP and port. Any reason why you not configure a VTY line ACL to block those connection attempts from putting your router into quiet mode in the first place? 

[SCDow]

Absolutely, there are a few solutions to tackle the SSH attempts, there is currently an ACL allowing the 10.x.x.x /8 as the customer's private addressing space, but we hadn't expected these SSH attempts from within their network. They're coming from a 3rd party service provider who haven't been directed or authorised to probe SSH, so I could exclude their addresses, but I wanted to find the range they're sweeping - is SSH being attempted on Loopback 2, Loopback 3, the WAN interface IP, etc.

I tried the log suggestion and modified entry 100 to "100 permit 10.0.0.0 0.255.255.255 log", however this didn't give me the local destination IP or interface on which the SSH was targeted to, but instead just logged any hits as a counter:

"000000: Oct 2 2025 00:00:00.000 NTP: %SEC-6-IPACCESSLOGS: list 10 permitted 10.0.0.1 1 packet"

I'm a little baffled as to why the local destination IP/interface isn't included in the existing "%SEC_LOGIN-4-LOGIN_FAILED:" log, only "[localport: 22]"?

[Rob Ingram · Accepted solution]

@SCDow I'm using a named ACL on the VTY lines and I get source and destination IP/ports.

*Oct 3 11:12:37.569: %SEC-6-IPACCESSLOGP: list ACL-VTY permitted tcp 192.168.6.10(51744) -> 192.168.6.2(22), 1 packet
*Oct 3 11:13:01.355: %SEC-6-IPACCESSLOGP: list ACL-VTY denied tcp 192.168.6.10(51763) -> 192.168.6.2(23), 1 packet

[SCDow]

Excellent, this could be the subtlety I needed - my access lists are standard numbered by default. I'll try replicating it as named and switch that in, and return with the results

[SCDow]

Great stuff thank you Rob, that got me the info I was needing!

I wasn't thinking outside of the box there, I was thinking, "Surely there's a 'debug' clause or something I can use to invoke the collection of a destination IP/Interface within the SSH command set..."

As it turns out, there isn't, but the Extended ACL saved the day as it inherently logs both source and destination.

[balaji.bandi]

Its all depends on the network, if you have any firewall in front, you can view that Logs or enable Logs and send to syslog to investigate.

Also make ACL to allow only required IP for SSH connection for best practice.

[SCDow]

Yes I totally agree. In this case these are from within the private address space for that customer, and this is "rogue" behaviour from one of their 3rd party service providers, no firewalls in the way unfortunately.

This is more of a "where do I find this..." question for theory knowledge. My thoughts are, surely IOS XE Cupertino 17.9.x on a 1117 router captures that detail and not just "[localport: 22]"? And it's either that or I'm being stupid... Could be my knowledge of fundamentals for SSH negotiation is lacking! I believe any Loopback and the WAN interface IP all accept SSH requests unless configured not to? Then it should log which one has been hit.

[balaji.bandi]

sure if you have ACL with Logs you can find @Rob Ingram  provided the example