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 Default
SSH control parameters are set to default router values.
Command Modes
Global configuration (config)
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. |
Usage Guidelines
Before you configure SSH on your router, you must enable the SSH server using the crypto key generate rsacommand.
Examples
The following examples configure SSH control parameters on your router:
ip ssh timeout 120 ip ssh authentication-retries 3
ip ssh dh min size
To configure the modulus size on the IOS Secure Shell (SSH) server and client, use the ip ssh dh min size command in global configuration mode. To configure the default value of 1024 bits, use the no form or the default form of this command.
ip ssh dh min size number
no ip ssh dh min size
default ip ssh dh min size
Syntax Description
|
number |
Minimum number of bits in the key size. The available options are 1024, 2048, and 4096. The default value is 1024. |
Command Default
Minimum size of Diffie-Hellman (DH) key on IOS SSH server and client is 1024 bits.
Command Modes
Global configuration (config)
Command History
|
Release |
Modification |
|---|---|
|
12.4(20)T |
This command was introduced. |
|
15.1(2)S |
This command was integrated into Cisco IOS Release 15.1(2)S. |
|
15.1(1)SY |
This command was integrated into Cisco IOS Release 15.1(1)SY. |
Usage Guidelines
Use the ip ssh dh min size command to ensure that the CLI is successfully parsed from either the client side or the server side.
In both DH key exchange methods, IOS SSH server and client negotiates and establishes connections with only groups (ranges) whose modulus sizes are equal to or higher than the value configured in the CLI.
Examples
The following example shows how to set the minimum modulus size to 2048 bits:
Device> enable Device# configure terminal Device(config)# ip ssh dh min size 2048
Related Commands
|
Command |
Description |
|---|---|
|
show ip ssh |
Displays the status of SSH server connections. |
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.
ip ssh dscp number
no ip ssh dscp number
Syntax Description
|
number |
Value that can be set. The default value is 0 (zero).
|
Command Default
The IP DSCP value is not specified.
Command Modes
Global configuration (config)
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.
Examples
The following example shows that the DSCP value is set to 35:
Router(config)# ip ssh dscp 35
Related Commands
|
Command |
Description |
|---|---|
|
ip ssh precedence |
Specifies the IP precedence value that may be set. |
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.
ip ssh pubkey-chain
no ip ssh pubkey-chain
Syntax Description
This command has no arguments or keywords.
Command Default
SSH-RSA keys are not configured.
Command Modes
Global configuration (config)
Command History
|
Release |
Modification |
|---|---|
|
15.0(1)M |
This command was introduced. |
|
15.1(1)S |
This command was integrated into Cisco IOS Release 15.1(1)S. |
Usage Guidelines
Use the ip ssh pubkey-chaincommand to ensure SSH server and user public key authentication.
Examples
The following example shows how to enable public key generation:
Router(config)# ip ssh pubkey-chain
Related Commands
|
Command |
Description |
|---|---|
|
ip ssh stricthostkeycheck |
Enables strict host key checking on the SSH server. |
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.
ip ssh stricthostkeycheck
no ip ssh stricthostkeycheck
Syntax Description
This command has no arguments or keywords.
Command Default
Strict host key checking on the SSH server is not enabled.
Command Modes
Global configuration (config)
Command History
|
Release |
Modification |
|---|---|
|
15.0(1)M |
This command was introduced. |
|
15.1(1)S |
This command was integrated into Cisco IOS Release 15.1(1)S. |
Usage Guidelines
Use the ip ssh stricthostkeycheckcommand to ensure SSH server side strict checking. Configuring the ip ssh stricthostkeycheck command authenticates all servers.
 Note | This 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.
Examples
The following example shows how to enable strict host key checking:
Router(config)# ip ssh stricthostkeycheck
Related Commands
|
Command |
Description |
|---|---|
|
ip ssh pubkey-chain |
Configures SSH-RSA keys for user and server authentication on the SSH server. |
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.
ip ssh version [ 1 | 2 ]
no ip ssh version [ 1 | 2 ]
Syntax Description
|
1 |
(Optional) Router runs only SSH Version 1. |
|
2 |
(Optional) Router runs only SSH Version 2. |
Command Default
If this command is not configured, SSH operates in compatibility mode, that is, Version 1 and Version 2 are both supported.
Command Modes
Global configuration
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 1
The following example shows that only SSH Version 2 is configured:
Router (config)# ip ssh version 2
The following example shows that SSH Versions 1 and 2 are configured:
Router (config)# no ip ssh version
Related 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
Note | This 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.
ip verify unicast reverse-path [list]
no ip verify unicast reverse-path [list]
Syntax Description
Command Default
Unicast RPF is disabled.
Command Modes
Interface configuration (config-if)
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.
Note | It is very important for Cisco Express Forwarding to be configured globally in the router. Unicast RPF will not work without Cisco Express Forwarding. |
Note | Unicast 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-path
The 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 any
The 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-input
Related Commands
|
Command |
Description |
|---|---|
|
ip cef |
Enables Cisco Express Forwarding on the route processor card. |
ipv6 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.
ipv6 tacacs source-interface interface
no ipv6 tacacs source-interface interface
Syntax Description
|
interface |
Interface to be used for the source address in TACACS packets. |
Command Default
No interface is specified.
Command Modes
Global configuration (config)
Command History
|
Release |
Modification |
|---|---|
|
Cisco IOS XE Release 3.2S |
This command was introduced. |
Usage Guidelines
The ipv6 tacacs source-interfacecommand specifies an interface to use for the source address in TACACS packets.
Examples
The following example shows how to configure the Gigabit Ethernet interface to be used as the source address in TACACS packets:
Router(config)# ipv6 tacacs source-interface GigabitEthernet 0/0/0
Related Commands
|
Command |
Description |
|---|---|
|
tacacs server |
Configures the TACACS+ server for IPv6 or IPv4 and enters TACACS+ server configuration mode. |
Feedback