This section is dedicated to Cisco Wireless technologies. Wireless networks have without doubt become an integral part of today's networks. Cisco, a world leader in wireless technologies, offers a number of solutions and a wide range of equipment for wireless networks, each one designed to cover specific needs.

This category aims to analyse, help understand and setup Cisco wireless Aironet access points, wireless LAN Controllers (WLC), WLCs with remote access point (Flexconnect  & H-REAP) and much more. Be sure to frequently visit the Cisco Wireless Technologies category of Firewall.cx as new articles are constantly added.

We hope you enjoy the provided articles and welcome your feedback and suggestions.

This article shows how to configure and setup SSH for remote management of Cisco IOS Routers. We’ll show you how to check if SSH is supported by your IOS version, how to enable it, generate an RSA key for your router and finally configure SSH as the preferred management protocol under the VTY interfaces.

Secure Shell (SSH) provides a secure and reliable mean of connecting to remote devices. It’s an encrypted network protocol that allows users to safely access equipment via command line interface sessions. SSH makes use of TCP port 22 which’s assigned to secure logins, file transfer and port forwarding.

SSH uses public key for authenticating the remote device and encrypt all data between that device and the workstation which makes it the best choice for public networks, unlike (telnet) which transmits data in plain text which subjects it to security threats, this makes (telnet) recommended for private networks only to keep the data uncompromised.

Verifying SSH Support on your Router

The first step involves examining whether your Cisco router’s IOS supports SSH or not. Most modern Cisco routers support SSH, so this shouldn’t be a problem.

Products with (K9) in the image name e.g c2900-universalk9-mz.SPA.154-3.M2.bin, support strong encryption with 3DES/AES while (K8) IOS bundles support weak encryption with the outdated DES.

To check, simply enter privilege mode and use the show ip ssh command:

R1# show ip ssh
SSH Disabled - version 1.99
%Please create RSA keys to enable SSH (and of atleast 768 bits for SSH v2).
Authentication timeout: 120 secs; Authentication retries: 3
Minimum expected Diffie Hellman key size : 1024 bits
IOS Keys in SECSH format(ssh-rsa, base64 encoded): NONE

In the above output, the system is showing SSH support, but it’s currently disabled as no RSA key has been generated.  It is also worth noting that a key of at least 768 bits must be generated to enable SSHv2.

Securing Access to Router

It’s always a good idea to first restrict access to the Cisco router before enabling SSH. This is very important especially when the device has an interface facing public networks e.g Internet, Public Hotspot.

We first create user credentials for the device and then enable Athentication, Authorization & Accounting Services (AAA).  Finally, ensure a secret password is set to protect access to privilege mode, along with the service password-encryption command to ensure all clear-text passwords are encrypted:

Next, it is highly recommended to restrict remote access via the SSH protocol only. This will ensure that insecure services such as Telnet cannot be used to access the router. Telnet sends all information unencrypted, including username/password, and is therefore considered a security risk.

We’ll use the transport input ssh command under the VTY section to restrict remote access using SSH only. Note that we can also use Access-lists to restrict SSH connections to our router:

Note: the password command used under line vty 0 4 section is completely optional and not used in our case because of the login authentication default command which forces the router to use the AAA mechanism for all user authentication.

Generating Our Router’s RSA Key – Digital Certificate

What makes Palo Alto Networks Next-Generation Firewall (NGFW) so different from its competitors is its Platform, Process and Architecture. Palo Alto Networks delivers all the next generation firewall features using the single platform, parallel processing and single management systems, unlike other vendors who use different modules or multiple management systems to offer NGFW features.

More technical and how-to articles covering Palo Alto's Firewalls can be found in our Palo Alto Networks Firewall Section

Palo Alto Networks Next-Generation Firewall’s main strength is its Single Pass Parallel Processing (SP3) Architecture, which comprises two key components:

1. Single Pass Software
2. Parallel Processing Hardware

Figure 1.   Palo Alto Networks Firewall Single Pass Parallel Processing Architecture

Single Pass Software

Palo Alto Networks Next-Generation Firewall is empowered with Single Pass Software, which processes the packet to perform functions like networking, user identification (User-ID), policy lookup, traffic classification with application identification (App-ID), decoding, signature matching for identifying threats and contents, which are all performed once per packet as shown in the illustration below:

Figure 2: Palo Alto Networks Firewall - Single-Pass Architecture Traffic Flow

This processing of a packet in one go or single pass by Palo Alto Networks Next-Generation Firewall enormously reduces the processing overhead, other vendor firewalls using a different type of architecture produce a significantly higher overhead when processing packets traversing the firewall. It’s been observed that the Unified Threat Management (UTM), which processes the traffic using multi-pass architecture, results in process overhead, latency introduction and throughput degradation.

The diagram below illustrates the multi-pass architecture process used by other vendors’ firewalls, clearly showing differences to the Palo Alto Networks Firewall architecture and how the processing overhead is produced: