Configure Management Remote Access
This section describes how to configure ASA access for ASDM, Telnet, or SSH, and other management parameters such as a login banner.
Configure SSH Access
To identify the client IP addresses and define a user allowed to connect to the ASA using SSH, perform the following steps. See the following guidelines:
-
To access the ASA interface for SSH access, you do not also need an access rule allowing the host IP address. You only need to configure SSH access according to this section.
-
SSH access to an interface other than the one from which you entered the ASA is not supported. For example, if your SSH host is located on the outside interface, you can only initiate a management connection directly to the outside interface. The only exception to this rule is through a VPN connection. See Configure Management Access Over a VPN Tunnel.
-
The ASA allows a maximum of 5 concurrent SSH connections per context/single mode, with a maximum of 100 connections divided among all contexts. However, because configuration commands might obtain locks on resources being changed, you should make changes in one SSH session at a time to ensure all changes are applied correctly.
-
By default, the ASA uses a proprietary SSH stack. You can choose to enable the CiscoSSH stack instead, which is based on OpenSSH. The default stack continues to be the ASA stack. Cisco SSH supports:
-
FIPS compliance
-
Regular updates, including updates from Cisco and the open source community
Note that the Cisco SSH stack does not support:
-
SSH to a different interface over VPN (management-access)
-
EDDSA key pair
-
RSA key pair in FIPS mode
If you need these features, you should continue to use the ASA SSH stack.
There is a small change to SCP functionality with the CiscoSSH stack: to use the ASA copy command to copy a file to or from an SCP server, you have to enable SSH access on the ASA for the SCP server subnet/host using the ssh command.
-
-
(8.4 and later) The SSH default username is no longer supported. You can no longer connect to the ASA using SSH with the pix or asa username and the login password. To use SSH, you must configure AAA authentication using the aaa authentication ssh console LOCAL command; then define a local user by entering the username command. If you want to use a AAA server for authentication instead of the local database, we recommend also configuring local authentication as a backup method.
-
Only SSH Version 2 is supported.
Before you begin
-
In multiple context mode, complete this procedure in the context execution space. To change from the system to a context configuration, enter changeto context name .
Procedure
|
Step 1 |
(Optional) Use the CiscoSSH stack instead of the default ASA SSH stack. ssh stack ciscossh To return to the ASA SSH stack, use no ssh stack ciscossh . |
|
Step 2 |
Generate a key pair, which is required for SSH (for physical ASAs only). For the ASAv, the key pairs are automatically created after deployment. The ASAv only supports the RSA key. |
|
Step 3 |
Save the keys to persistent flash memory. write memory Example: |
|
Step 4 |
Create a user in the local database that can be used for SSH access. You can alternatively use a AAA server for user access, but a local username is recommended. username name [password password] privilege level Example:By default, the privilege level is 2; enter a level between 0 and 15, where 15 has all privileges. You might want to create a user without a password if you want to force the user to use public key authentication (ssh authentication ) instead of password authentication. If you configure public key authentication as well as a password in the username command, then the user can log in with either method if you explicitly configure AAA authentication in this procedure. Note: Do not use the username command nopassword option; the nopassword option allows any password to be entered, not no password. |
|
Step 5 |
(Optional) Allow public key authentication for a user instead of/as well as password authentication, and enter the public key on the ASA: username name attributes ssh authentication {pkf | publickey key} Example:For a local username , you can enable public key authentication instead of/as well as password authentication. You can generate a public key/private key pair using any SSH key generation software (such as ssh keygen) that can generate ssh-rsa, ecdsa-sha2-nistp, or ssh-ed25519 raw keys (with no certificates). Enter the public key on the ASA. The SSH client then uses the private key (and the passphrase you used to create the key pair) to connect to the ASA. For a pkf key, you are prompted to paste in a PKF formatted key, up to 4096 bits. Use this format for keys that are too large to paste inline in Base64 format. For example, you can generate a 4096-bit key using ssh keygen, then convert it to PKF, and use the pkf keyword to be prompted for the key. Note: You can use the pkf option with failover, but the PKF key is not automatically replicated to the standby system. You must enter the write standby command to synchronize the PKF key. For a publickey key , the key is a Base64-encoded public key. You can generate the key using any SSH key generation software (such as ssh keygen) that can generate ssh-rsa, ecdsa-sha2-nistp, or ssh-ed25519 raw keys (with no certificates). |
|
Step 6 |
(For password access) Enable local (or AAA server) authentication for SSH access: aaa authentication ssh console {LOCAL | server_group [LOCAL]} Example:This command does not affect local public key authentication for usernames with the ssh authentication command. The ASA implicitly uses the local database for public key authentication. This command only affects usernames with passwords. If you want to allow either public key authentication or password use by a local user, then you need to explicitly configure local authentication with this command to allow password access. |
|
Step 7 |
Identify the IP addresses from which the ASA accepts connections for each address or subnet, and the interface on which you can use SSH. ssh source_IP_address mask source_interface
Unlike Telnet, you can SSH on the lowest security level interface. Example: |
|
Step 8 |
(Optional) Set the duration for how long an SSH session can be idle before the ASA disconnects the session. ssh timeout minutes Example:Set the timeout from 1 to 60 minutes. The default is 5 minutes. The default duration is too short in most cases, and should be increased until all pre-production testing and troubleshooting have been completed. |
|
Step 9 |
(Optional) Configure SSH cipher encryption algorithms: ssh cipher encryption {all | fips | high | low | medium | custom colon-delimited_list_of_encryption_ciphers} Example:The default is medium . Ciphers are used in the order they are listed. For pre-defined lists, they are listed from highest to lowest security.
|
|
Step 10 |
(Optional) Configure SSH cipher integrity algorithms: ssh cipher integrity {all | fips | high | low | medium | custom colon-delimited_list_of_integrity_ciphers} Example:The default is high .
|
|
Step 11 |
(Optional) (Admin context only) Set the Diffie-Hellman (DH) key exchange mode: ssh key-exchange group {curve25519-sha256 | dh-group1-sha1 | dh-group14-sha1 | dh-group14-sha256 | ecdh-sha2-nistp256} Example:The default is dh-group14-sha256 The DH key exchange provides a shared secret that cannot be determined by either party alone. The key exchange is combined with a signature and the host key to provide host authentication. This key-exchange method provides explicit server authentication. For more information about using DH key-exchange methods, see RFC 4253. You can only set the key exchange in the Admin context; this value is used by all contexts. |
Examples
The following example shows how to authenticate using a PKF formatted key:
ciscoasa(config)# crypto key generate eddsa edwards-curve ed25519
ciscoasa(config)# write memory
ciscoasa(config)# username dean password examplepassword1 privilege 15
ciscoasa(config)# username dean attributes
ciscoasa(config-username)# ssh authentication pkf
Enter an SSH public key formatted file.
End with the word "quit" on a line by itself:
---- BEGIN SSH2 PUBLIC KEY ----
Comment: "256-bit ED25519, converted by dean@dwinchester-mac from "
AAAAC3NzaC1lZDI1NTE5AAAAIDmIeTNfEOnuH0094p1MKX80fW2O216g4trnf7gwWe5Q
---- END SSH2 PUBLIC KEY ----
quit
INFO: Import of an SSH public key formatted file SUCCEEDED.
ciscoasa(config)#
The following example generates a shared key for SSH on a Linux or Macintosh system, and imports it to the ASA:
-
Generate the EdDSA public and private keys on your computer:
dwinchester-mac:~ dean$ ssh-keygen -t ed25519 Generating public/private ed25519 key pair. Enter file in which to save the key (/Users/dean/.ssh/id_ed25519): Enter passphrase (empty for no passphrase): key-pa$$phrase Enter same passphrase again: key-pa$$phrase Your identification has been saved in /Users/dean/.ssh/id_ed25519. Your public key has been saved in /Users/dean/.ssh/id_ed25519.pub. The key fingerprint is: SHA256:ZHOjfJa3DpZG+qPAp9A5PyCEY0+Vzo2rkGHJpplpw8Q dean@dwinchester-mac The key's randomart image is: +--[ED25519 256]--+ | . | | o | |. . + o+ o | |.E+ o ++.+ o | |B=.= .S = . | |** ooo. = o . | |.....o*.o = . | | o .. *.+.o | | . . oo... | +----[SHA256]-----+ dwinchester-mac:~ dean$ -
Convert the key to PKF format:
dwinchester-mac:~ dean$ cd .ssh dwinchester-mac:.ssh dean$ ssh-keygen -e -f id_ed25519.pub ---- BEGIN SSH2 PUBLIC KEY ---- Comment: "256-bit ED25519, converted by dean@dwinchester-mac from " AAAAC3NzaC1lZDI1NTE5AAAAIDmIeTNfEOnuH0094p1MKX80fW2O216g4trnf7gwWe5Q ---- END SSH2 PUBLIC KEY ---- dwinchester-mac:.ssh dean$ -
Copy the key to your clipboard.
-
In ASDM, choose , select the username and then click Edit. Click Public Key Using PKF and paste the key into the window:
-
Verify the user can SSH to the ASA. For the password, enter the SSH key password you specified when you created the key pair.
dwinchester-mac:.ssh dean$ ssh dean@10.89.5.26 The authenticity of host '10.89.5.26 (10.89.5.26)' can't be established. ED25519 key fingerprint is SHA256:6d1g2fe2Ovnh0GHJ5aag7GxZ68h6TD6txDy2vEwIeYE. Are you sure you want to continue connecting (yes/no/[fingerprint])? yes Warning: Permanently added '10.89.5.26' (ED25519) to the list of known hosts. dean@10.89.5.26's password: key-pa$$phrase User dean logged in to asa Logins over the last 5 days: 2. Last login: 18:18:13 UTC Jan 20 2021 from 10.19.41.227 Failed logins since the last login: 0. Type help or '?' for a list of available commands. asa>
Configure Telnet Access
To identify the client IP addresses allowed to connect to the ASA using Telnet, perform the following steps. See the following guidelines:
-
To access the ASA interface for Telnet access, you do not also need an access rule allowing the host IP address. You only need to configure Telnet access according to this section.
-
Telnet access to an interface other than the one from which you entered the ASA is not supported. For example, if your Telnet host is located on the outside interface, you can only initiate a Telnet connection directly to the outside interface. The only exception to this rule is through a VPN connection. See Configure Management Access Over a VPN Tunnel.
-
You cannot use Telnet to the lowest security interface unless you use Telnet inside a VPN tunnel.
-
The ASA allows a maximum of 5 concurrent Telnet connections per context/single mode, with a maximum of 100 connections divided among all contexts.
Before you begin
-
In multiple context mode, complete this procedure in the context execution space. To change from the system to a context configuration, enter changeto context name .
-
To gain access to the ASA CLI using Telnet, enter the login password set by the password command . You must manually set the password before using Telnet.
Procedure
|
Step 1 |
Identify the IP addresses from which the ASA accepts connections for each address or subnet on the specified interface.
If there is only one interface, you can configure Telnet to access that interface as long as the interface has a security level of 100. Example: |
|
Step 2 |
Set the duration for how long a Telnet session can be idle before the ASA disconnects the session. telnet timeout minutes Example:Set the timeout from 1 to 1440 minutes. The default is 5 minutes. The default duration is too short in most cases and should be increased until all pre-production testing and troubleshooting have been completed. |
Examples
The following example shows how to let a host on the inside interface with an address of 192.168.1.2 access the ASA:
ciscoasa(config)# telnet 192.168.1.2 255.255.255.255 inside
The following example shows how to allow all users on the 192.168.3.0 network to access the ASA on the inside interface:
ciscoasa(config)# telnet 192.168.3.0. 255.255.255.255 inside
Configure HTTPS Access for ASDM, Other Clients
To use ASDM or other HTTPS clients such as CSM, you need to enable the HTTPS server, and allow HTTPS connections to the ASA. HTTPS access is enabled as part of the factory default configuration. To configure HTTPS access, perform the following steps. See the following guidelines:
-
To access the ASA interface for HTTPS access, you do not also need an access rule allowing the host IP address. You only need to configure HTTPS access according to this section. If, however, you configure HTTP redirect to redirect HTTP connections to HTTPS automatically, you must enable an access rule to allow HTTP; otherwise, the interface cannot listen to the HTTP port.
-
Management access to an interface other than the one from which you entered the ASA is not supported. For example, if your management host is located on the outside interface, you can only initiate a management connection directly to the outside interface. The only exception to this rule is through a VPN connection. See Configure Management Access Over a VPN Tunnel.
-
In single context mode, you can have a maximum 30 ASDM concurrent sessions. In multiple context mode, you can have a maximum of 5 concurrent ASDM sessions per context, with a maximum of 32 ASDM instances among all contexts.
ASDM sessions use two HTTPS connections: one for monitoring that is always present, and one for making configuration changes that is present only when you make changes. For example, the multiple-context mode system limit of 32 ASDM sessions represents a limit of 64 HTTPS sessions.
-
The ASA allows a maximum of 6 concurrent non-ASDM HTTPS sessions in single context mode or per context, if available, with a maximum or 100 HTTPS sessions among all contexts.
-
If you enable both SSL (webvpn > enable interface) and HTTPS access on the same interface, you can access AnyConnect Client from https://ip_address and ASDM from https://ip_address/admin, both on port 443. If you also enable aaa authentication http console, then you must specify a different port for ASDM access.
Before you begin
-
In multiple context mode, complete this procedure in the context execution space. To change from the system to a context configuration, enter changeto context name .
Procedure
|
Step 1 |
Identify the IP addresses from which the ASA accepts HTTPS connections for each address or subnet on the specified interface. http source_IP_address mask source_interface
Example: |
|
Step 2 |
Enable the HTTPS server. http server enable [port] Example:By default, the port is 443. If you change the port number, be sure to include it in the ASDM access URL. For example, if you change the port number to 444, enter the following URL: https://10.1.1.1:444 |
|
Step 3 |
Allow non-browser-based HTTPS clients to access HTTPS services on the ASA. By default, ASDM, CSM, and REST API are allowed. http server basic-auth-client user_agent
Enter each client string using a separate command. Many specialty clients (for example, python libraries, curl, and wget) do not support Cross-site request forgery (CSRF) token-based authentication, so you need to specifically allow these clients to use the ASA basic authentication method. For security purposes, you should only allow required clients. Example: |
|
Step 4 |
(Optional) Set connection and session timeouts. http server idle-timeoutminutes http server session-timeoutminutes http connection idle-timeoutseconds
Example: |
Examples
The following example shows how to enable the HTTPS server and let a host on the inside interface with an address of 192.168.1.2 access ASDM:
ciscoasa(config)# http server enable
ciscoasa(config)# http 192.168.1.2 255.255.255.255 inside
The following example shows how to allow all users on the 192.168.3.0/24 network to access ASDM on the inside interface:
ciscoasa(config)# http 192.168.3.0 255.255.255.0 inside
Configure HTTP Redirect for ASDM Access or Clientless SSL VPN
You must use HTTPS to connect to the ASA using ASDM or clientless SSL VPN. For your convenience, you can redirect HTTP management connections to HTTPS. For example, by redirecting HTTP, you can enter either http://10.1.8.4/admin/ or https://10.1.8.4/admin/ and still arrive at the ASDM launch page at the HTTPS address.
You can redirect both IPv4 and IPv6 traffic.
Before you begin
Normally, you do not need an access rule allowing the host IP address. However, for HTTP redirect, you must enable an access rule to allow HTTP; otherwise, the interface cannot listen to the HTTP port.
Procedure
|
Enable HTTP redirect: http redirect interface_name [port] Example:The port identifies the port from which the interface redirects HTTP connections. The default is 80. |
Configure Management Access Over a VPN Tunnel
If your VPN tunnel terminates on one interface, but you want to manage the ASA by accessing a different interface, you must identify that interface as a management-access interface. For example, if you enter the ASA from the outside interface, this feature lets you connect to the inside interface using ASDM, SSH, or Telnet; or you can ping the inside interface when entering from the outside interface.
 Note |
This feature is not supported for SSH if you use the CiscoSSH stack. |
Note |
This feature is not supported for SNMP. |
VPN access to an interface other than the one from which you entered the ASA is not supported. For example, if your VPN access is located on the outside interface, you can only initiate a connection directly to the outside interface. You should enable VPN on the directly-accessible interface of the ASA and use name resolution so that you don’t have to remember multiple addresses.
Management access is available via the following VPN tunnel types: IPsec clients, IPsec Site-to-Site, Easy VPN, and the AnyConnect Client SSL VPN.
Before you begin
Due to routing considerations with the separate management and data routing tables, the VPN termination interface and the management access interface need to be the same type: both need to be management-only interfaces or regular data interfaces.
Procedure
|
Specify the name of the management interface that you want to access when entering the ASA from another interface. management-access management_interface For Easy VPN and Site-to-Site tunnels, you can specify a named BVI (in routed mode). Example: |
Configure Management Access for FXOS on Firepower 2100 Platform Mode Data Interfaces
If you want to manage FXOS on the Firepower 2100 in Platform Mode from a data interface, you can configure SSH, HTTPS, and SNMP access. This feature is useful if you want to manage the device remotely, but you want to keep Management 1/1, which is the native way to access FXOS, on an isolated network. If you enable this feature, you can continue to use Management 1/1 for local access only. However, you cannot allow remote access to or from Management 1/1 for FXOS at the same time as using this feature. This feature requires forwarding traffic to the ASA data interfaces using an internal path (the default), and you can only specify one FXOS management gateway.
The ASA uses non-standard ports for FXOS access; the standard port is reserved for use by the ASA on the same interface. When the ASA forwards traffic to FXOS, it translates the non-standard destination port to the FXOS port for each protocol (do not change the HTTPS port in FXOS). The packet destination IP address (which is the ASA interface IP address) is also translated to an internal address for use by FXOS. The source address remains unchanged. For returning traffic, the ASA uses its data routing table to determine the correct egress interface. When you access the ASA data IP address for the management application, you must log in using an FXOS username; ASA usernames only apply for ASA management access.
You can also enable FXOS management traffic initiation on the ASA data interfaces, which is required for SNMP traps, or NTP and DNS server access, for example. By default, FXOS management traffic initiation is enabled for the ASA outside interface for DNS and NTP server communication (required for Smart Software Licensing communication).
Before you begin
-
Single context mode only.
-
Excludes ASA management-only interfaces.
-
You cannot use a VPN tunnel to the ASA data interface and access FXOS directly. As a workaround for SSH, you can VPN to the ASA, access the ASA CLI, and then use the connect fxos command to access the FXOS CLI. Note that SSH, HTTPS, and SNMPv3 are/can be encrypted, so direct connection to the data interface is safe.
-
Ensure that the FXOS gateway is set to forward traffic to the ASA data interfaces (the default). See the getting started guide for more information about setting the gateway.
Procedure
|
Step 1 |
Enable FXOS remote management. fxos {https | ssh | snmp} permit {ipv4_address netmask | ipv6_address/prefix_length} interface_name Example: |
|
Step 2 |
(Optional) Change the default port for the service. fxos {https | ssh | snmp} port port See the following defaults:
Example: |
|
Step 3 |
Allow FXOS to initiate management connections from the ASA interface. ip-client interface_name By default, the outside interface is enabled. Example: |
|
Step 4 |
Connect to the Firepower Chassis Manager on Management 1/1 (by default https://192.168.45.45, with the username: admin and password: Admin123). |
|
Step 5 |
Click the Platform Settings tab, and enable SSH, HTTPS, or SNMP. SSH and HTTPS are enabled by default. |
|
Step 6 |
Configure an Access List on the Platform Settings tab to allow your management addresses. SSH and HTTPS only allow the Management 1/1 192.168.45.0 network by default. You need to allow any addresses that you specified in the FXOS Remote Management configuration on the ASA. |
Change the Console Timeout
The console timeout sets how long a connection can remain in privileged EXEC mode or configuration mode; when the timeout is reached, the session drops into user EXEC mode. By default, the session does not time out. This setting does not affect how long you can remain connected to the console port, which never times out.
Procedure
|
Specify the idle time in minutes (0 through 60) after which the privileged session ends. console timeout number Example:The default timeout is 0, which means the session does not time out. |
Customize a CLI Prompt
The ability to add information to a prompt allows you to see at-a-glance which ASA you are logged into when you have multiple modules. During a failover, this feature is useful when both ASAs have the same hostname.
In multiple context mode, you can view the extended prompt when you log in to the system execution space or the admin context. Within a non-admin context, you only see the default prompt, which is the hostname and the context name.
By default, the prompt shows the hostname of the ASA. In multiple context mode, the prompt also displays the context name. You can display the following items in the CLI prompt:
|
cluster-unit |
Displays the cluster unit name. Each unit in a cluster can have a unique name. |
|
context |
(Multiple mode only) Displays the name of the current context. |
|
domain |
Displays the domain name. |
|
hostname |
Displays the hostname. |
|
priority |
Displays the failover priority as pri (primary) or sec (secondary). |
|
state |
Displays the traffic-passing state or role of the unit. For failover, the following values are displayed for the state keyword:
For clustering, the values for control and data are shown. |
Procedure
|
Customize the CLI prompt by entering the following command: Example:The order in which you enter the keywords determines the order of the elements in the prompt, which are separated by a slash (/). |
Configure a Login Banner
You can configure a message to display when a user connects to the ASA, before a user logs in, or before a user enters privileged EXEC mode.
Before you begin
-
From a security perspective, it is important that your banner discourage unauthorized access. Do not use the words “welcome” or “please,” as they appear to invite intruders in. The following banner sets the correct tone for unauthorized access:
You have logged in to a secure device. If you are not authorized to access this device, log out immediately or risk possible criminal consequences. -
After a banner has been added, Telnet or SSH sessions to the ASA may close if:
-
There is not enough system memory available to process the banner message(s).
-
A TCP write error occurs when trying to display banner message(s).
-
-
See RFC 2196 for guidelines about banner messages.
Procedure
|
Add a banner to display at one of three times: when a user first connects (message-of-the-day (motd)), when a user logs in (login), and when a user accesses privileged EXEC mode (exec). banner {exec | login | motd} text Example:When a user connects to the ASA, the message-of-the-day banner appears first, followed by the login banner and prompts. After the user successfully logs in to the ASA, the exec banner appears. To add more than one line, precede each line by the banner command. For the banner text:
|
Examples
The following examples show how to add a message-of-the-day banner:
ciscoasa(config)# banner motd Only authorized access is allowed to $(hostname).
ciscoasa(config)# banner motd Contact me at admin@example.com for any issues.
Set a Management Session Quota
You can establish a maximum number of simultaneous ASDM, SSH, and Telnet sessions that are allowed on the ASA. If the maximum is reached, no additional sessions are allowed and a syslog message is generated. To prevent a system lockout, the management session quota mechanism cannot block a console session.
Note |
In multiple context mode, you cannot configure the number of ASDM sessions, where the maximum is fixed at 5 sessions. |
Note |
If you also set a resource limit per context for the maximum administrative sessions (SSH, etc.), then the lower value will be used. |
Before you begin
In multiple context mode, complete this procedure in the context execution space. To change from the system to a context configuration, enter the changeto context name command.
Procedure
|
Step 1 |
Enter the following command: quota management-session [ssh | telnet | http | user] number
Example: |
|
Step 2 |
View the current sessions in use. show quota management-session [ssh | telnet | http | user] Example: |
Feedback