Feedback
Contents
ip source-track through ivrf
- ip ssh
- ip ssh dh min size
- ip ssh dscp
- ip ssh pubkey-chain
- ip ssh stricthostkeycheck
- ip ssh version
- ip verify unicast reverse-path
- ipv6 tacacs source-interface
ip ssh
To configure Secure Shell (SSH) control parameters on your router, use the ip ssh command in global configuration mode. To restore the default value, use the no form of this command.
ip ssh [ timeout seconds | authentication-retries integer ]
no ip ssh [ timeout seconds | authentication-retries integer ]
Syntax Description
timeout
(Optional) The time interval that the router waits for the SSH client to respond.
This setting applies to the SSH negotiation phase. Once the EXEC session starts, the standard timeouts configured for the vty apply. By default, there are 5 vtys defined (0-4), therefore 5 terminal sessions are possible. After the SSH executes a shell, the vty timeout starts. The vty timeout defaults to 10 minutes.
seconds
(Optional) The number of seconds until timeout disconnects, with a maximum of 120 seconds. The default is 120 seconds.
authentication- retries
(Optional) The number of attempts after which the interface is reset.
integer
(Optional) The number of retries, with a maximum of 5 authentication retries. The default is 3.
Command History
Release
Modification
12.0(5)S
This command was introduced.
12.1(1)T
This command was integrated into Cisco IOS Release 12.1(1) T.
12.2(17a)SX
This command was integrated into Cisco IOS Release 12.2(17a)SX.
12.2(33)SRA
This command was integrated into Cisco IOS release 12.(33)SRA.
Cisco IOS XE Release 2.4
This command was implemented on the Cisco ASR 1000 series routers.
ip ssh dh min size
To configure the modulus size on the Secure Shell (SSH) server, use the ip ssh dh min size command in privileged EXEC mode. To disable the configuration, use the no form of this command.
Usage Guidelines
Use the ip ssh dh min sizecommand to ensure that the CLI is successfully parsed from either the client side or the server side.
ip ssh dscp
To specify the IP differentiated services code point (DSCP) value that can be set for a Secure Shell (SSH) configuration, use the ip ssh dscpcommand in global configuration mode. To restore the default value, use the no form of this command.
Command History
Release
Modification
12.4(20)S
This command was introduced.
12.2SR
This command is supported in the Cisco IOS Release 12.2SR train. Support in a specific 12.2SR train depends on your feature set, platform, and platform hardware.
12.2SX
This command is supported in the Cisco IOS Release 12.2SX train. Support in a specific 12.2SX train depends on your feature set, platform, and platform hardware.
12.4(22)T
This command was integrated into Cisco IOS Release 12.4(22)T.
Usage Guidelines
IP DSCP values can be configured on both the SSH client and the SSH server for SSH traffic that is generated on either end.
ip ssh pubkey-chain
To configure Secure Shell RSA (SSH-RSA) keys for user and server authentication on the SSH server, use the ip ssh pubkey-chain command in global configuration mode. To remove SSH-RSA keys for user and server authentication on the SSH server, use the no form of this command.
Usage Guidelines
Use the ip ssh pubkey-chaincommand to ensure SSH server and user public key authentication.
ip ssh stricthostkeycheck
To enable strict host key checking on the Secure Shell (SSH) server, use the ip ssh stricthostcheck command in global configuration mode. To disable strict host key checking, use the no form of this command.
Usage Guidelines
Use the ip ssh stricthostkeycheckcommand to ensure SSH server side strict checking. Configuring the ip ssh stricthostkeycheck command authenticates all servers.
NoteThis command is not available on SSH Version 1.
- If the ip ssh pubkey-chain command is not configured, the ip ssh stricthostkeycheck command will lead to connection failure in SSH Version 2.
ip ssh version
To specify the version of Secure Shell (SSH) to be run on a router, use the ip ssh versioncommand in global configuration mode. To disable the version of SSH that was configured and to return to compatibility mode, use the no form of this command.
Command Default
If this command is not configured, SSH operates in compatibility mode, that is, Version 1 and Version 2 are both supported.
Command History
Release
Modification
12.3(4)T
This command was introduced.
12.3(2)XE
This command was integrated into Cisco IOS Release 12.3(2)XE.
12.2(25)S
This command was integrated into Cisco IOS Release 12.2(25)S.
12.3(7)JA
This command was integrated into Cisco IOS Release 12.3(7)JA.
12.0(32)SY
This command was integrated into Cisco IOS Release 12.0(32)SY.
12.4(20)T
This command was integrated into Cisco IOS Release 12.4(20)T.
15.2(2)SA2
This command was implemented on the Cisco ME 2600X Series Ethernet Access Switches.
Usage Guidelines
You can use this command with the 2 keyword to ensure that your router will not inadvertently establish a weaker SSH Version 1 connection.
Examples
The following example shows that only SSH Version 1 support is configured:
Router (config)# ip ssh version 1The following example shows that only SSH Version 2 is configured:
Router (config)# ip ssh version 2The following example shows that SSH Versions 1 and 2 are configured:
Router (config)# no ip ssh versionRelated Commands
Command
Description
debug ip ssh
Displays debug messages for SSH.
disconnect ssh
Terminates a SSH connection on your router.
ip ssh
Configures SSH control parameters on your router.
ip ssh rsa keypair-name
Specifies which RSA key pair to use for a SSH connection.
show ip ssh
Displays the SSH connections of your router.
ip verify unicast reverse-path
NoteThis command was replaced by the ip verify unicast source reachable-viacommand effective with Cisco IOS Release 12.0(15)S. The ip verify unicast source reachable-via command allows for more flexibility and functionality, such as supporting asymmetric routing, and should be used for any Reverse Path Forward implementation. The ip verify unicast reverse-path command is still supported.
To enable Unicast Reverse Path Forwarding (Unicast RPF), use the ip verify unicast reverse-pathcommand in interface configuration mode. To disable Unicast RPF, use the no form of this command.
Command History
Release
Modification
11.1(CC)
12.0
This command was introduced. This command was not included in Cisco IOS Release 11.2 or 11.3
12.1(2)T
Added ACL support using the list argument. Added per-interface statistics on dropped or suppressed packets.
12.0(15)S
The ip verify unicast source reachable-via command replaced this command, and the following keywords were added to the ip verify unicast source reachable-via command: allow-default, allow-self-ping, rx, and any.
12.1(8a)E
The ip verify unicast reverse-pathcommand was integrated into Cisco IOS Release 12.1(8a)E.
12.2(14)S
The ip verify unicast reverse-pathcommand was integrated into Cisco IOS Release 12.2(14)S.
12.2(14)SX
The ip verify unicast reverse-path command was integrated into Cisco IOS Release 12.2(14)SX.
12.2(33)SRA
The ip verify unicast reverse-pathcommand was integrated into Cisco IOS Release 12.2(33)SRA.
Usage Guidelines
Use the ip verify unicast reverse-path interface command to mitigate problems caused by malformed or forged (spoofed) IP source addresses that are received by a router. Malformed or forged source addresses can indicate denial of service (DoS) attacks on the basis of source IP address spoofing.
When Unicast RPF is enabled on an interface, the router examines all packets that are received on that interface. The router checks to ensure that the source address appears in the Forwarding Information Base (FIB) and that it matches the interface on which the packet was received. This "look backwards" ability is available only when Cisco Express Forwarding is enabled on the router because the lookup relies on the presence of the FIB. Cisco Express Forwarding generates the FIB as part of its operation.
To use Unicast RPF, enable Cisco Express Forwarding switching or distributed Cisco Express Forwarding switching in the router. There is no need to configure the input interface for Cisco Express Forwarding switching. As long as Cisco Express Forwarding is running on the router, individual interfaces can be configured with other switching modes.
NoteIt is very important for Cisco Express Forwarding to be configured globally in the router. Unicast RPF will not work without Cisco Express Forwarding.
NoteUnicast RPF is an input function and is applied on the interface of a router only in the ingress direction.
The Unicast Reverse Path Forwarding feature checks to determine whether any packet that is received at a router interface arrives on one of the best return paths to the source of the packet. The feature does this by doing a reverse lookup in the Cisco Express Forwarding table. If Unicast RPF does not find a reverse path for the packet, Unicast RPF can drop or forward the packet, depending on whether an ACL is specified in the Unicast Reverse Path Forwarding command. If an ACL is specified in the command, then when (and only when) a packet fails the Unicast RPF check, the ACL is checked to determine whether the packet should be dropped (using a deny statement in the ACL) or forwarded (using a permit statement in the ACL). Whether a packet is dropped or forwarded, the packet is counted in the global IP traffic statistics for Unicast RPF drops and in the interface statistics for Unicast RPF.
If no ACL is specified in the Unicast Reverse Path Forwarding command, the router drops the forged or malformed packet immediately and no ACL logging occurs. The router and interface Unicast RPF counters are updated.
Unicast RPF events can be logged by specifying the logging option for the ACL entries used by the Unicast Reverse Path Forwarding command. Log information can be used to gather information about the attack, such as source address, time, and so on.
Where to Use RPF in Your Network
Unicast RPF may be used on interfaces in which only one path allows packets from valid source networks (networks contained in the FIB). Unicast RPF may also be used in cases for which a router has multiple paths to a given network, as long as the valid networks are switched via the incoming interfaces. Packets for invalid networks will be dropped. For example, routers at the edge of the network of an Internet service provider (ISP) are likely to have symmetrical reverse paths. Unicast RPF may still be applicable in certain multi-homed situations, provided that optional Border Gateway Protocol (BGP) attributes such as weight and local preference are used to achieve symmetric routing.
With Unicast RPF, all equal-cost "best" return paths are considered valid. This means that Unicast RPF works in cases where multiple return paths exist, provided that each path is equal to the others in terms of the routing cost (number of hops, weights, and so on) and as long as the route is in the FIB. Unicast RPF also functions where Enhanced Internet Gateway Routing Protocol (EIGRP) variants are being used and unequal candidate paths back to the source IP address exist.
For example, routers at the edge of the network of an ISP are more likely to have symmetrical reverse paths than routers that are in the core of the ISP network. Routers that are in the core of the ISP network have no guarantee that the best forwarding path out of the router will be the path selected for packets returning to the router. In this scenario, you should use the new form of the command, ip verify unicast source reachable-via, if there is a chance of asymmetrical routing.
Examples
The following example shows that the Unicast Reverse Path Forwarding feature has been enabled on a serial interface:
ip cef ! or "ip cef distributed" for RSP+VIP based routers ! interface serial 5/0/0 ip verify unicast reverse-pathThe following example uses a very simple single-homed ISP to demonstrate the concepts of ingress and egress filters used in conjunction with Unicast RPF. The example illustrates an ISP-allocated classless interdomain routing (CIDR) block 192.168.202.128/28 that has both inbound and outbound filters on the upstream interface. Be aware that ISPs are usually not single-homed. Hence, provisions for asymmetrical flows (when outbound traffic goes out one link and returns via a different link) need to be designed into the filters on the border routers of the ISP.
ip cef distributed ! interface Serial 5/0/0 description Connection to Upstream ISP ip address 192.168.200.225 255.255.255.255 no ip redirects no ip directed-broadcast no ip proxy-arp ip verify unicast reverse-path ip access-group 111 in ip access-group 110 out ! access-list 110 permit ip 192.168.202.128 10.0.0.31 any access-list 110 deny ip any any log access-list 111 deny ip host 10.0.0.0 any log access-list 111 deny ip 172.16.0.0 255.255.255.255 any log access-list 111 deny ip 10.0.0.0 255.255.255.255 any log access-list 111 deny ip 172.16.0.0 255.255.255.255 any log access-list 111 deny ip 192.168.0.0 255.255.255.255 any log access-list 111 deny ip 209.165.202.129 10.0.0.31 any log access-list 111 permit ip any anyThe following example demonstrates the use of ACLs and logging with Unicast RPF. In this example, extended ACL 197 provides entries that deny or permit network traffic for specific address ranges. Unicast RPF is configured on Ethernet interface 0 to check packets arriving at that interface.
For example, packets with a source address of 192.168.201.10 arriving at Ethernet interface 0 are dropped because of the deny statement in ACL 197. In this case, the ACL information is logged (the logging option is turned on for the ACL entry) and dropped packets are counted per-interface and globally. Packets with a source address of 192.168.201.100 arriving at Ethernet interface 0 are forwarded because of the permit statement in ACL 197. ACL information about dropped or suppressed packets is logged (the logging option is turned on for the ACL entry) to the log server.
ip cef distributed ! int eth0/1/1 ip address 192.168.200.1 255.255.255.255 ip verify unicast reverse-path 197 ! int eth0/1/2 ip address 192.168.201.1 255.255.255.255 ! access-list 197 deny ip 192.168.201.0 10.0.0.63 any log-input access-list 197 permit ip 192.168.201.64 10.0.0.63 any log-input access-list 197 deny ip 192.168.201.128 10.0.0.63 any log-input access-list 197 permit ip 192.168.201.192 10.0.0.63 any log-input access-list 197 deny ip host 10.0.0.0 any log-input access-list 197 deny ip 172.16.0.0 255.255.255.255 any log-input access-list 197 deny ip 10.0.0.0 255.255.255.255 any log-input access-list 197 deny ip 172.16.0.0 255.255.255.255 any log-input access-list 197 deny ip 192.168.0.0 255.255.255.255 any log-inputipv6 tacacs source-interface
To specify an interface to use for the source address in TACACS packets, use the ipv6 tacacs source-interfacecommand in global configuration mode. To remove the specified interface from the configuration, use the no form of this command.
Usage Guidelines
The ipv6 tacacs source-interfacecommand specifies an interface to use for the source address in TACACS packets.
