F5 Logo MyF5
Search
  1. MyF5 Home
  2. Knowledge Centers
  3. BIG-IP AFM
  4. BIG-IP Network Firewall: Policies and Implementations
  5. SSH Proxy Security
Manual Chapter : SSH Proxy Security

Applies To:

Show Versions Show Versions

BIG-IP AFM

  • 14.0.1, 14.0.0
Manual Chapter
Table of Contents | << Previous Chapter | Next Chapter >>

SSH Proxy Security

Securing SSH traffic with the SSH Proxy

Why use SSH proxy?

Network attacks are increasingly less visible, cloaked in SSL and SSH channels. The SSH Proxy lets network administrators centrally manage the different uses of SSH, determining who can do what on which servers. Additionally, as the feature is a full proxy, terminating both the client and server sides of the connection, it is possible to inspect traffic before passing it on. This prevents attackers from hiding their activities while still providing legitimate users with secure communications.

Challenges and problems that SSH proxy addresses

  • Gives administrators visibility into user command activity in the SSH channel
  • Provides fine-grained control of SSH access commands on a per-user basis
  • Allows segmentation of access control for different users, allowing, for example, one user to download (but not upload) with SCP, while another user can upload and download with SCP allowing SHELL access only to an administrator, and other examples
  • Control over SSH keep-alives that keep a session open indefinitely

Features of SSH Proxy

  • Policy based SSH control capability
  • Fine-grained control of SSH access on a per-user basis
  • Visibility and control of SSH connection
  • By controlling the SSH commands and session, the datacenter administrator can prevent advanced attacks from compromising the datacenter

Current limits of SSH Proxy

  • Supports SSH version 2.0 or above only
  • SSH proxy is supported on a virtual server, not on a route domain or global context
  • SSH proxy auth key size is limited to 4K
  • Elliptical Curve cypher (ECDHE) SSH keys are not supported for authentication

Using SSH Proxy

You can use an SSH Proxy to secure SSH traffic on a virtual server, on a per-user basis. A working SSH proxy implementation requires
  • An SSH proxy profile that defines actions for SSH channel commands
  • A virtual server for the SSH server, configured for SSH traffic, and including the SSH proxy profile
  • Authentication information for the SSH proxy

Proxying SSH traffic with an SSH Proxy profile

Configure an SSH proxy security profile to allow or deny SSH channel actions to specific users on a virtual server.
  1. On the Main tab, click Security > Protocol Security > Security Profiles > SSH Proxy .
    The Protocol Security: Security Profiles: SSH Proxy screen opens.
  2. Click Create.
    The New SSH Profile screen opens.
  3. In the Profile Name field, type a unique name for the profile.
  4. From the Lang Env Tolerance list, select which connections with LANG environment variables set are allowed to pass through if the SSH Proxy profile has the Other channel type permission (in the SSH Proxy Permissions rules) set to Disallow or Terminate.
    Option Description
    Any Allows connections with any LANG environment value set.
    Common Allows only connections with the LANG environment value set to en_US.UTF-8 to pass through the Other restrictions.
    None Disallows all connections with the LANG environment variable set.
  5. In the Timeout field, specify the idle timeout, in seconds, to maintain an SSH session if there is no activity.
    A setting of 0 means that the SSH session never times out.
  6. To filter the list of SSH proxy permission rules, type the filter text in the Filter Rules field.
    Important: The Filter Rules field is case sensitive.
  7. Edit an existing rule, or add a new rule.
    • To edit an existing rule, click the name of the rule. For example, click Default Actions to edit the default rule for a profile.
    • To add a new rule, click Add New Rule. A new line is added to the list of rules. Add a name to the rule to begin editing.
  8. In the Users column, in the add new user field, type an SSH user name to which the rule applies, then click Add.
    Note: You cannot add users to the Default Actions rule.
  9. Configure the settings for each SSH channel action.
    • To allow the session to be set up for the SSH channel action, select Allow.
    • To deny an SSH channel action, and send a command not accepted message, select Disallow. Note that many SSH clients disconnect when this occurs.
    • To terminate an SSH connection by sending a reset message when a channel action is received, select Terminate.
    Note: In non-default rules, SSH channels have an Unspecified option, which means that for a specific user, if all the rules' actions (except default actions) are unspecified, then use the Default Action rule.
  10. To enable logging for an SSH action, select the Log check box.
    Before events are logged, you need to set up a log publisher and logging profile.
  11. When you finish editing
    • An existing rule, click Done Editing.
    • A new rule, click Add Rule.
  12. When you are finished adding and editing rules, click Commit Changes to System.
The SSH proxy profile is saved to the system.
To use an SSH proxy profile with a virtual server, attach the profile to a virtual server.

SSH proxy permissions

In an SSH proxy profile, you can configure whether to Allow, Disallow, or Terminate SSH proxy permissions. Non-default action rules include an Unspecified option, which means use the Default Action. You can also choose to log the rule actions.

Channel action Description
Shell Defines use of the shell command to establish an interactive terminal (command line) session, or shell, on the remote host. It determines whether the SSH proxy allows establishing interactive sessions.

Note that Shell depends on Other. If Other is disabled, users cannot obtain Shell access.
Sub System Defines the use of the subsystem command, to invoke remote commands that are defined on the server over the SSH tunnel. It allows SSH servers to be configured to abstract certain commands and procedures.
SFTP Up Defines the use of Secure File Transfer Protocol (sftp) to upload (put) files over the SSH tunnel.
SFTP Down Defines the use of Secure File Transfer Protocol (sftp) to download (get) files over the SSH tunnel.
SCP Up Defines the use of Secure Copy (scp) to copy files from a local directory to a remote directory over the SSH tunnel.
SCP Down Defines the use of Secure Copy (scp) to copy files from a remote directory to a local directory over the SSH tunnel.
Rexec Defines the use of rexec remote execution commands over the SSH tunnel. SSH can be configured to deny interactive sessions, while allowing specific commands to execute on the remote host.
Forward Local Defines the use of the -L to do local port forwarding over the SSH tunnel. That way, SSH can be used to set up an encrypted tunnel to a remote host.
Forward Remote Defines the use of the -R to do remote port forwarding over the SSH tunnel. That way, SSH can be used to set up an encrypted tunnel from a remote host.
Forward X11 Defines the use of X11 forwarding over the SSH tunnel.
Agent Defines the use of ssh-agent over the SSH tunnel. Agent forwarding specifies that the chain of SSH connections forwards key challenges back to the original agent, removing the need for passwords or private keys on intermediate machines.
Other Provides a catch-all category. Any channel type not handled by another permission is handled here. If set to Disallow or Terminate, the following channel types are also affected (Disallowed or Terminated): Shell, Agent, X11, Local port forwarding, and Remote port forwarding.The Lang Env Tolerance setting only takes effect when Other is set to Disallow or Terminate.

Creating an SSH virtual server with SSH proxy security

Create an SSH virtual server to protect SSH connections with the SSH proxy.
  1. On the Main tab, click Local Traffic > Virtual Servers .
    The Virtual Server List screen opens.
  2. Click the Create button.
    The New Virtual Server screen opens.
  3. In the Name field, type a unique name for the virtual server.
  4. In the Destination Address field, type the IP address in CIDR format.
    The supported format is address/prefix, where the prefix length is in bits. For example, an IPv4 address/prefix is 10.0.0.1 or 10.0.0.0/24, and an IPv6 address/prefix is ffe1::0020/64 or 2001:ed8:77b5:2:10:10:100:42/64. When you use an IPv4 address without specifying a prefix, the BIG-IP system automatically uses a /32 prefix.
    Note: The IP address you type must be available and not in the loopback network.
  5. In the Service Port field, type 22 or select SSH from the list.
  6. From the SSH Proxy Profile list, select the SSH proxy profile to attach to the virtual server.
  7. For the Default Pool setting, either select an existing pool from the list, or click the Create (+) button and create a new pool.
    The pool you create or select should contain your backend SSH server.
  8. Click Finished.
The SSH virtual server appears in the Virtual Servers list.

Attaching an SSH proxy security profile to an existing virtual server

You can add SSH proxy security to your SSH virtual server with SSH proxy profile.

  1. On the Main tab, click Local Traffic > Virtual Servers .
    The Virtual Server List screen opens.
  2. In the Name column, click an SSH virtual server.
    The Properties screen for the virtual server opens.
  3. From the SSH Proxy Profile list, select the SSH proxy profile to attach to the virtual server.
  4. Click Update to save the changes.
You now have a virtual server configured so that the SSH proxy profile rules are applied to SSH traffic.

Authenticating SSH proxy traffic

What SSH authentication methods are supported?

SSH security supports public key authentication, password authentication, and keyboard-interactive authentication.

Keyboard-interactive authentication

Keyboard-interactive authentication is a more complex form of password authentication, aimed specifically at the human operator as a client. During keyboard authentication prompts or questions are presented to the user. The user answers each prompt or question. The number and contents of the questions are virtually unlimited, so certain types of automated logins are also possible.

SSH client components support keyboard authentication via the OnAuthenticationKeyboard event. The client application should fill in the Responses parameter of the mentioned event with replies to questions contained in the Prompts parameter. Use echo parameter to specify whether the response is displayed on the screen, or masked. The number of responses must match the number of prompts or questions.

Password authentication

Password authentication is the simplest authentication method. The user specifies a username and password. This authentication method requires only one set of credentials for the user.

Public key authentication

Public key authentication requires that both the SSH client and the SSH server must implement the security keys. With this method, each client must have a key pair generated using a supported encryption algorithm. When authentication occurs, the client sends a public key to the server. If the server finds the key in the list of allowed keys, the client encrypts data using the private key and sends the packet to the server with the public key.

Defining SSH proxy password or keyboard interactive authentication

Generate public/private RSA key pairs, then configure tunnel keys for password or keyboard interactive authentication to allow the SSH proxy to view tunnel traffic.
  1. On the BIG-IP system, type ssh-keygen.

    The system outputs:

    Generating public/private rsa key pair. Enter file in which to save the key (/root/.ssh/id_rsa):

  2. Hit the Enter key to save the file.

    The system outputs:

    /root/.ssh/id_rsa already exists. Overwrite (y/n)?

  3. Type y to save the file.

    The system prompts for a passphrase.

    Enter passphrase (empty for no passphrase):

  4. Leave the passphrase and confirm passphrase fields blank, and hit Enter.

    The system outputs something like the following example. The output will be different on your system:

    Your identification has been saved in /root/.ssh/id_rsa.
Your public key has been saved in /root/.ssh/id_rsa.pub.
The key fingerprint is:
08:02:33:1a:8e:45:73:c0:eb:dc:fb:da:87:c5:2c:bf root@localhost.localdomain
The key's randomart image is:
+--[ RSA 2048]----+
|=o=..            |
|+*.o             |
|o....            |
|  .. . .         |
| o .  .oS        |
|  o . . +        |
|     . =         |
|    ... o        |
|    .oo.E.       |
+-----------------+
  5. Copy the key from id_rsa including the -----BEGIN RSA PRIVATE KEY----- and -----END RSA PRIVATE KEY----- headers and footers.
    This is your private key, which you will add to the SSH proxy configuration.
  6. On the Main tab, click Security > Protocol Security > Security Profiles > SSH Proxy .
    The Protocol Security: Security Profiles: SSH Proxy screen opens.
  7. Click the name of the SSH proxy profile to edit.
    The SSH Profile screen opens.
  8. Click the Key Management tab.
  9. Click Add New Auth Info.
  10. In the Enter Auth Info Name field, type a name for the authentication info settings.
  11. In the Real Server Auth Public Key field, paste the Host public key from your backend server.
    Note: Make sure not to include the trailing comment.
    The Real Server Auth key must not be commented out in your SSHD configuration. To make sure, on your backend SSH server, locate the file /etc/ssh/sshd_config, and make sure the line HostKey /etc/ssh/ssh_host_rsa_key is not commented out.
  12. In the Proxy Server Auth Private Key field, add the private key that was generated on the BIG-IP system.
    Note: Include the -----BEGIN RSA PRIVATE KEY----- and -----END RSA PRIVATE KEY----- headers and footers.

    Leave the Proxy Server Auth Public Key field blank because the SSH proxy generates the public key from the private key.

  13. Click Add.
  14. When you are finished adding and editing rules, click Commit Changes to System.
The SSH proxy profile is saved to the system.
To use an SSH proxy profile with a virtual server, attach the profile to a virtual server.

Defining SSH proxy public key authentication

Before you can define public key authentication in the SSH proxy configuration, you need to have password or keyboard authentication and the Real Server Auth Public Key configured.
Generate a public/private key pair, then configure tunnel keys for public key authentication to allow the SSH proxy to view tunnel traffic. Start on the BIG-IP system, then continue the task on the SSH client system.
  1. On the BIG-IP system command line, type ssh-keygen.

    The system outputs:

    Generating public/private rsa key pair. Enter file in which to save the key (/root/.ssh/id_rsa):

  2. Hit the Enter key to save the file.

    The system outputs:

    /root/.ssh/id_rsa already exists. Overwrite (y/n)?

  3. Type y to save the file.

    The system prompts for a passphrase.

    Enter passphrase (empty for no passphrase):

  4. Leave the passphrase and confirm passphrase fields blank, and hit Enter.

    The system outputs something like the following example. (The output will be different on your system.)

    Your identification has been saved in /root/.ssh/id_rsa.
Your public key has been saved in /root/.ssh/id_rsa.pub.
The key fingerprint is:
08:02:33:1a:8e:45:73:c0:eb:dc:fb:da:87:c5:2c:bf root@localhost.localdomain
The key's randomart image is:
+--[ RSA 2048]----+
|=o=..            |
|+*.o             |
|o....            |
|  .. . .         |
| o .  .oS        |
|  o . . +        |
|     . =         |
|    ... o        |
|    .oo.E.       |
+-----------------+
  5. Copy the key from id_rsa.
    This is your private key, which you will add to the SSH proxy configuration.
  6. On the Main tab, click Security > Protocol Security > Security Profiles > SSH Proxy .
    The Protocol Security: Security Profiles: SSH Proxy screen opens.
  7. Click the name of the SSH proxy profile to edit.
    The SSH Profile screen opens.
  8. Click the Key Management tab.
  9. Click Add New Auth Info.
  10. In the Enter Auth Info Name field, type a name for the authentication info settings.
  11. In the Proxy Client Auth Private Key field, paste the private key you have generated. For private keys, the -----BEGIN RSA PRIVATE KEY----- and -----END RSA PRIVATE KEY----- headers/footers are required.
    Proxy Client Auth Public Key is an optional field that can be left blank because it is derived from the configured private keys.
  12. Click Add.
  13. Click Commit Changes to System.
  14. Next, log in to the SSH client system.
  15. On the SSH client system, generate a private/public key pair with the command ssh-keygen.
    The system outputs:
    Generating public/private rsa key pair.
Enter file in which to save the key (/home/user1/.ssh/id_rsa):
  16. Click Enter or specify a different file location.
  17. Type and confirm a passphrase when prompted, or leave the fields blank to specify no passphrase.
    The system outputs something like the following example. This output will be different on your system:
    Your identification has been saved in /home/user1/.ssh/id_rsa.
Your public key has been saved in /home/user1/.ssh/id_rsa.pub.
The key fingerprint is:
25:26:7e:49:56:61:71:ca:23:ec:d1:49:6b:49:61:6b user1@Ubuntu-VM1
The key's randomart image is:
+--[ RSA 2048]----+
|          X+.    |
|       . O B     |
|      . O E      |
|     . * O .     |
|      . S        |
|       .         |
|                 |
|                 |
|                 |
+-----------------+
  18. On the backend SSH server, open the sshd configuration file (/etc/ssh/sshd_config) and set the public key authentication to yes as follows: PubkeyAuthentication yes
  19. Specify a central authorized keys file by editing the AuthorizedKeysFile line as follows:
    AuthorizedKeysFile %h/.ssh/authorized_keys /etc/ssh/authorized_keys
    Note: You can specify your own path and filename for the authorized keys file on the SSH server.
    Restart the SSH daemon on the SSH server.
  20. Copy the public key from the BIG-IP AFM system and paste it into the authorized keys file on the SSH server (for example, /etc/ssh/authorized_keys). On the SSH server, paste the public key using the following commands (the file location and name may differ, and the public key is an example only). 
    user1@Ubuntu-VM3:~$ vi /etc/ssh/authorized_keys 
ssh-rsa
AAAAB3NzaC1yc2EAAAABIwAAAQEAkCmU13s2/LVfm/eJ+HGesb8WeZ3A00iNX4S6ZDa7bOwb+f
jpr8rCwt4fWw8U7VwPaeqE35odBW7LhwQUXg5zL1KdxgguILVI2i/cDSkPKcaQKcUIvG+BrpYj
wky4T9tTKo2br+XQ92eWMh+xrVUwY4h2crpZxdng+YV+hUbqgJ+PHO4t0ozAYpgIul5C+2MTcN
zMuEYxbZqWdtNFtceAywu4CYZBwAZ3mCJbfW1wtFo6DG85tIo3LuaGXpA10jav1cC2szEo0OKT
0HUPJzYfSQiU/jHQv7Becwc9L8bOC6CxryTvx3Uq/Zf0ONQHhsyasIxg2wrVwzhbI1ctSyZgww==
root@localhost.localdomain
  21. Copy the public key from the client to the SSH server in one of two ways:
    1. Copy the public key you created on the client system and paste it into the user authorized keys file (for example /.ssh/authorized_keys) using the following commands (the file location and name may differ, and the public key is an example only): 
      user1@Ubuntu-VM3:~$ vi ~/.ssh/authorized_keys 
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDSMcf/wX3YZQAg+/RxbqXvXpIPVvnugCOYJm
uapYIze7Etc+192CB/zakmT3pKDyHHiVP1PwpP3jr99tY95llYg3p+A8nfv7+1UcwJYlS2EfYy
8qenb3Q4Mdtzrxr0AEjU/a4WXmGYd5h/ju5yRxQUt//q09PbxsEAf0qY05Tpax7R3rGl+15tf6
AI1a+poNGidfAAS1Pqc453qIXM1cp/PnOaKKzveQWBM2IIPenVxwdyX06Tn2OYBh4Rq4qUrt38
PyiYmKOYqQ/M4hD0R6/VLvF24i936uKfvBdkZcvePLGMpswQAteFzJA0JJjbWUIfvCYFCOLiFO
IATUGe9Nxl user1@Ubuntu-VM1
    2. Alternatively, on the client system, you can issue the ssh-copy-id command to copy the public key generated on the client system to transparently copy it to the backend server by way of the BIG-IP system.
      Note: For this to work, you need to have established a successful SSH connection from the client to the backend SSH server through the BIG-IP.
      ssh-copy-id -i ~/.ssh/id_rsa.pub user@<Virtual-Server-IP>
      For example, 
      ssh-copy-id -i ~/.ssh/id_rsa.pub adminserver@10.2.2.140
When the SSH server is added to a pool on a virtual server, and the SSH profile is attached to the virtual server, the client should now be able to make an SSH connection to the SSH server using the virtual server address.

Authenticating SSH Proxy with the server private key

Note:

This task is optional and only applies if the SSH virtual server IP address to which you attach the SSH Proxy profile has the same IP address as the backend SSH server. Clients connect directly to the backend SSH server address via the SSH proxy in the middle.

This task describes how to configure SSH proxy authentication when the virtual server on the BIG-IP system and the backend SSH server both have the same IP address. In this case, both the BIG-IP system and the SSH server can use the same keys instead of generating a new set of keys on the BIG-IP system. This prevents clients from having to authenticate when making an SSH connection to the backend SSH server. To do this, you can use the private keys from the backend server and use them as the Proxy Server Auth Private Key in the SSH proxy configuration on the BIG-IP system.
  1. On the Main tab, click Security > Protocol Security > Security Profiles > SSH Proxy .
    The Protocol Security: Security Profiles: SSH Proxy screen opens.
  2. Click the name of the SSH proxy profile to edit, or create a new one.
    The SSH Profile screen opens.
  3. Click the Key Management tab.
  4. Click Add New Auth Info.
  5. In the Edit Auth Info Name field, type a name for the authentication info settings.
    • To edit an existing rule, click the name of the rule. For example, click Default Actions to edit the default rule for a profile.
    • To add a new rule, click Add New Rule. A new line is added to the list of rules. Add a name to the rule to begin editing.
  6. In the Real Server Auth Public Key field paste the Host public key from your backend server.
    The real server auth key must not be commented out in your sshd configuration. To make sure, on your backend SSH server, locate the file etc/ssh/sshd_config, and make sure the line HostKey /etc/ssh/ssh_host_rsa_key is not commented out.
  7. Get the private key from the backend SSH server.

    For example, on the SSH backend server, at the following prompt, the admin uses the specified command to get the SSH server private key:

    admin@Ubuntu-VM3:~$ sudo cat /etc/ssh/ssh_host_rsa_key

    The output of this command is the private key:

    -----BEGIN RSA PRIVATE KEY-----
MIIEowIBAAKCAQEAs4kusmrz6RbkYyz/Yc0YhAXFYCw8p6FqjTLsAqzkRJEog6lq
hUa8nRQhsumdVsMCbgzCMOYd7CLqrTqO/M3eqQWm16Y9EC1Mi7RsfNDnt7yJ6cMb
xtv2F/Smho6H5GrGSfrTqqDnuULHJ1GK+yMOghLqNnQVSGci/6NSMk7w3y/Pslzu
Lz82nZi9IL1dReen3kVbAhdB1K4VsHa0OgqSKV+mnLGNB2sq4Thj5lReKkc+3y8k
hyeV0M+SClyUTRyRG18drYldU7kJYc/IDjKjKdiIkqsig3FE5NjstHz2JDQFj5Yn
6uxqZWJIrfORC+VAoLR3+fea6omzkCVhQAMxxQIDAQABAoIBAHTx2cIMGr7s022q
hNtu3hY5MBz6E7RZV2+MCOGhPrtPFmXUt/cCYZ+r2luRApTeR7npg6CYdEs5X0Xh
S/xuGShd7xSvSz07VI33w2b2KMms/OSQ24oIA2ANU194fhoSVwEfajrNvsMVNWZu
HiqB5lRh/7/ik25rCAgemU79zraBdYC5FMzlMnl2TRrxlT0NjGtaniH+wpkZm1x6
S/evuvaJOYWhp8tarMQDcfPi0HNU4+agwRxrCcGNqei7nROTvXjVmsqxrcHGKCdF
4LdJyPJ6KYjtm0IcEYzKAFY3+haeX7ico3vRjSNSfMQwJbcJDMgoQpf44dFf9Jht
fEIuHUECgYEA4nwySeehTVftHxg3iv1Azy6FGT5q4KwXktA4G3fMjUmjjDQ2NAx0
VxlSEOU5sH2au8b19s/rOPsPjvYBYRAp8s+JD5BVVnfiJ/pcK8d+ws9gB65V0c3X
/ly3Gvz/He8B//CaaGCJOfzlmP4KKwfD3KzHw6+LJHEIdTHjQCMRnvUCgYEAyu60
WDEUpZf3dlOcfpTwaDdKtaHMOCQPH5LMD1vZAQdD1Gts20rEgDp8iKf/jXbo8/uA
HfR5jz89AgDygIlWO15an710W8DrhCBYvRP44X9KcQeZlqJswDiOc5tRApunrac1
fEPaJ7OTdLElyA7GuZlIJVkgCLfyDodohewb5ZECgYBfLVwgzLNvglTGrXGh+h2D
M4SBgEZ/1jIt40zA1k5izaBqKgLhSp6Vf7GKIhplPdOJt+njZ6rtDiySonUf6iAG
xwpNPRVvuf+TV1Xmm/Z8PZOYhr3P5lYvsZzNPaakWK2Zde4dkPv6H3oJGjEBtkir
8vwcEyhBDzNDtMxQRqyABQKBgQCmSsVuH4oTyFv4kruC3vnB7M1D2bpHpwTdkqW1
UEabGSD0SLODX9l2WncCZOh9PBvZExcBdPzH7cJIig4uVlxbeg45KD7ZkVVtiDQv
fNZNssmFpfyt+5uySKYzBet0f6kAHC0wD0oNjpIe5atYLQObw4fjUw11F4c7cKqu
U7TogQKBgFUu0Q5FLxaNNV1p9hNTCU+KDGN/kIe5K+8aJ08TpYhTSFSzgV2k47av
xCzTcSufjcZIpjNiGuwmT+spiwoPYqP+AdXKWWcxNfC4ahBfi7ROP6xSriCkzsYv
ZFhMHDfIjDAGDFmHI5v9Gcjxt+iFLdiDV9Pzv1XFDKd5yfJNfmGd
-----END RSA PRIVATE KEY-----
  8. Paste the private key into the Proxy Server Auth Private Key field.
  9. Click Add.
  10. When you are finished adding and editing rules, click Commit Changes to System.
The SSH proxy profile is saved to the system.
To use an SSH proxy profile with a virtual server, attach the profile to a virtual server on the Properties page, in the Configuration (Basic) settings.

Logging SSH Proxy actions

You can use a local logging profile and Proxy to secure SSH traffic on a virtual server, on a per-user basis. You do this by creating an SSH proxy profile and attaching it to a virtual server. You must also provide the server public and private keys for the encrypted traffic.

Creating a publisher to send log messages to the local Syslog database

Create a publisher to specify that the BIG-IP system sends formatted log messages to the local Syslog database, on the BIG-IP system.
  1. On the Main tab, click System > Logs > Configuration > Log Publishers .
    The Log Publishers screen opens.
  2. Click Create.
  3. In the Name field, type a unique, identifiable name for this publisher.
  4. For the Destinations setting, select the previously created destination from the Available list (which formats the logs in the Splunk format and forwards the logs to the local Syslog database) and move the destination to the Selected list.
  5. Click Finished.

Create and associate a logging profile for SSH proxy events

Create an SSH logging profile to specify the events that are logged for SSH proxy. Use a unique name for the log profile, and specify the log publisher you created for SSH Proxy events.
  1. On the Main tab, click Security > Event Logs > Logging Profiles .
    The Logging Profiles list screen opens.
  2. Click Create.
    The Create New Logging Profile screen opens.
  3. In the Profile Name field, type a unique name for the profile.
  4. Select the Protocol Security check box.
  5. In the SSH Proxy area, from the Publisher list, select the log publisher you created.
  6. To log client authentication failures, for Log Client Auth Fail Event, click Enabled.
  7. To log successful client authentications, for Log Client Auth Success Event, click Enabled.
  8. To log partial client events, for Log Client Auth Partial Event, click Enabled.
  9. To log server authentication failures, for Log Server Auth Fail Event, click Enabled.
  10. To log successful server authentications, for Log Server Auth Success Event, click Enabled.
  11. To log partial server events, for Log Server Auth Partial Event, click Enabled.
  12. To log disallowed channel action, for Log Disallowed Channel Action, click Enabled.
  13. To log allowed channel action, for Log Allowed Channel Action, click Enabled.
  14. To log SSH timeouts, for Log SSH Timeout Event, click Enabled.
  15. To log Non-SSH timeouts, for Log Non-SSH Timeout Event, click Enabled.
  16. Click Finished to create the SSH logging profile.
    Tip: To create the SSH logging profile at the command line, create the log profile with the following command: tmsh create sec log profile <log_profile_name> ssh-proxy add { ssh-log { log-publisher <log_publisher_name> allowed-channel-action enabled disallowed-channel-action enabled ssh-timeout enabled non-ssh-traffic enabled successful-server-side-auth enabled unsuccessful-client-side-auth enabled unsuccessful-server-side-auth enabled }}
  17. To associate the logging profile with the SSH virtual server, click Local Traffic > Virtual Servers .
  18. Click the name of the SSH virtual server.
  19. From the Security menu, choose Policies.
  20. For the Log Profile setting:
    1. Set it to Enabled.
    2. From the Available list, move the SSH logging profile into the Selected list.
    You can assign only one local logging profile to a virtual server, but it can have multiple remote logging profiles.
  21. Click Update.
A logging profile that includes the SSH proxy events is created and associated with the SSH virtual server.

Example: Securing SSH traffic with the SSH Proxy

In this example, you create an SSH proxy configuration, create a virtual server for SSH traffic, and apply the SSH proxy to the virtual server. This example contains IP addresses and public and private keys that do not apply to your configuration, but are included for example purposes only.

In this configuration, password or keyboard interactive authentication is used, and the SSH proxy policy disallows SCP downloads and uploads, and terminates the tunnel connection on a REXEC command.

Example: Proxying SSH traffic with an SSH Proxy profile

Configure an SSH proxy security profile to allow or deny SSH channel actions to specific users on a virtual server. In this example, the proxy profile disallows SCP uploads and downloads, and terminates the channel on REXEC commands for the root user. All data entered in this screen is example data, and may not work on your system.
  1. On the Main tab, click Security > Protocol Security > Security Profiles > SSH Proxy .
    The Protocol Security: Security Profiles: SSH Proxy screen opens.
  2. Click Create.
    The New SSH Profile screen opens.
  3. In the Profile Name field, type the name ssh_no_scp_terminate_rexec.
  4. Click Add New Rule to add a rule for the profile.
  5. In the Enter Rule Name field, type root_rules as the name for the rule.
  6. In the Users column, in the add new user field, type root, and click Add.
  7. From the SCP Up list, select Disallow.
  8. From the SCP Down list, select Disallow.
  9. From the REXEC list, select Terminate.
  10. To enable logging for the SSH actions, select the Log check boxes.
  11. Click Add Rule.
  12. When you are finished adding and editing rules, click Commit Changes to System.
The SSH proxy profile is saved to the system.
To use an SSH proxy profile with a virtual server, attach the profile to a virtual server on the Properties page, in the Configuration (Basic) settings.

Example: Defining SSH tunnel authentication keys in an SSH Proxy profile

Working with the SSH proxy you defined earlier, add key management info to allow authentication.
  1. In the same SSH proxy profile you previously created, click the Key Management tab.
  2. Click Add New Auth Info.
  3. In the Edit Auth Info Name field, type root_auth for the auth info name.
  4. In the Real Server Auth Public Key field paste the public key from your backend server.
    The real server auth key must not be commented out in your sshd configuration. To make sure, on your backend SSH server, locate the file etc/ssh/sshd_config, and make sure the line HostKey /etc/ssh/ssh_host_rsa_key is not commented out.
    This is an example key.
    AAAAB3NzaC1yc2EAAAADAQABAAABAQCziS6yavPpFuRjLP9hzRiEBcVgLDynoW
qNMuwCrOREkSiDqWqFRrydFCGy6Z1WwwJuDMIw5h3sIuqtOo78zd6pBabXpj0Q
LUyLtGx80Oe3vInpwxvG2/YX9KaGjofkasZJ+tOqoOe5QscnUYr7Iw6CEuo2dB
VIZyL/o1IyTvDfL8+yXO4vPzadmL0gvV1F56feRVsCF0HUrhWwdrQ6CpIpX6ac
sY0HayrhOGPmVF4qRz7fLySHJ5XQz5IKXJRNHJEbXx2tiV1TuQlhz8gOMqMp2I
iSqyKDcUTk2Oy0fPYkNAWPlifq7GplYkit85EL5UCgtHf595rqibOQJWFAAzHF
  5. In the Proxy Server Auth Private Key field, add a private key.
    Tip: The proxy server auth private key can be a newly-generated key. The Proxy Server Auth Public Key field can be left blank, as the public key is generated from the private key by the SSH proxy.
    This is an example key.
    -----BEGIN RSA PRIVATE KEY-----
MIIEogIBAAKCAQEAuncfRQM+yzcJW32r9DPKCzDP6cDhHbeTUlBOERUp27De+Vax
dojovwVi/tRiE/4tSbHViPF6BgS2Ar3W3tkxJySXLNczLkVV7WWkTEXCY+VrLB2I
BXA5YBWYVOjreZ/TYaJM+WxmxlDaFt1Rd2e7WVuegKjV1nVQyqdsW6vxY9GB93Pa
2v1VWUktInUAISwrT0nrE/rDkncAoKK2PUisP5u84HBIaT6QfXExNnreYHq8fWXk
0FOSOS8XlJugfumgdH9i9U5agAmG535f89O9eTDFUHSM2aaPkG+wbbLi2pxZiXR+
8n9graKVWTHl2zRvbIWB6wyfqae4zQoJVNgjdQIBIwKCAQBakaF5SrgZj8K3aO0e
11OBx0BqORzijF1/wJryWryPR0e675gGX8GBWmNIkwsRBm3EtXZYdUnlqoRKeXb+
hsAaU5nilGlQ/RsbiSPqiEh5qfI5/7cYlZg1+9xGf8LUrLcgyyyzqa5DEVP8eiBB
T6QkFo7QxwjHQEvQJW8lNkIL6JX5LP73hxvuQ3JwZizOR6cRmOyedIJHP0oNPsYS
w/nkpk15mL70S8asjWTF837vGcHS1M7TAko/r5KAd6FsbNWkk486iOhPtU2F3wJi
H9VO/Tvdl8MVSNzVzyjBjqigIU8nsMIvalYunM82w99+CA0RlWooZvEiPp5Qbv3v
TzOrAoGBAO5D8JAOuGCuWtU9cNJdtjWSeTP9ZsPYna6i4WHZYfOAGUlu5su4htY5
J26DygeHI6bm4Wew09t/ctq2Or60p6fIg/6XhEVrEkv6eZeCm7a+qajVVk77ZayT
cQdpbiDYrFI5rChTnzlSZ/QgWOFQ7klx66Qfd2nV/JAnU2K9J+CNAoGBAMhYJqdH
H7spzOTBXv6xWukRDld1/nsJC7mIIfjT2sVSLBAr5ZkyOdXwF5je6LNli3d7CpcS
tzv6YdMDEDsYNLlKFuMhgwmeCX0zwSzyfgRFFFXvIgaUUIW9RRjfLhuLFNzQ4/QB
BTmv98ltvjhorgsSonu0oydB3vHD4TJfstiJAoGBAKNhyYdajQ8YeMy8ap7hLHyB
sjJHXGkJkLJDzb9wfa5JNek2GppSpZo10eVhrxsa1p5VLNljT3Hw/kzUupFl7056
3irrjeZ1Tl/8Nh6/9b8jp4m23Bjm5qI5N5ANx9wCSkcC+bVAp7JHIrYHjWdNcDJc
vtbxAW0lBPUiR86tl6/rAoGBAJqNJSH1CdmGpWAC4uG8BE1k7c5w94N8AbsCnd01
t2UE4Cm7dprAWIB3Yqkg/KemGyGoD3vbPOUgPNX7DIVb0Oa1f17CFKEE4r+rlQVq
m7omqUmbN4FrGYu95NisKuIMNKpYAE6Ecb7Jk0OdzUF1Uw/bLOMWUfm2eMkiFB+L
pzlTAoGAQRAi+l/GHR3W6p9ahetItzPWn2tBJQnQiuM0ZFXEct41USPL4Sok8G28
Pu0C9Gf4u+bEi3BDFZMg7N6cnUYKeQjxTNmNtwgopjrGutXOM8ieiWp8oLG0zev/
pavXWCxdecuoyLtNeyTPR/GPpBqN3c5KjKnfsoid8mK59xfhic4=
-----END RSA PRIVATE KEY-----
  6. Click Add.
  7. When you are finished adding and editing rules, click Commit Changes to System.
The SSH proxy profile is saved to the system.
To use an SSH proxy profile with a virtual server, attach the profile to a virtual server on the Properties page, in the Configuration (Basic) settings.

Example: Creating an SSH virtual server with SSH proxy security

When you enable protocol security for an HTTP virtual server, the system scans any incoming HTTP traffic for vulnerabilities before the traffic reaches the HTTP servers.
  1. On the Main tab, click Local Traffic > Virtual Servers .
    The Virtual Server List screen opens.
  2. Click the Create button.
    The New Virtual Server screen opens.
  3. In the Name field, type ssh_root.
  4. In the Destination Address/Mask field, type the IP address in CIDR format.
    For example, 10.1.1.20.
  5. In the Service Port field, type 22 or select SSH from the list.
  6. From the SSH Proxy Profile list, select ssh_no_scp_terminate_rexec.
  7. For the Default Pool setting, either select an existing pool from the list, or click the Create (+) button and create a new pool.
    The pool you create or select should contain your backend SSH server.
  8. Click Finished.
The SSH virtual server appears in the Virtual Servers list.
Table of Contents | << Previous Chapter | Next Chapter >>
Contact Support Contact Support

Have a Question?

Support and Sales >

About F5

Education

F5 Sites

Support Tasks




©2023 F5 Networks, Inc. All rights reserved.


Trademarks Policies Privacy California Privacy Do Not Sell My Personal Information