Local CDR Storage and FTP Push

The local CDR storage feature allows you to save RADIUS CDR data to a local CSV text file on the OCSBC. Local CDR file creation and storage can be used in addition to or independently of sending CDRs to RADIUS servers for every call. Once the OCSBC creates and saves local CDR files, you can:

  • Send the files to an FTP server by configuring a push receiver
  • Develop and implement your own script for retrieving them as necessary from the OCSBC

You configure the OCSBC to:

  • Set directory path where you want to save local CDR files
  • Set a maximum file size for the CSV file
  • Set a maximum number of local CDR files
  • Set an interval in which to close the existing local CDR file and begin writing a new file.

Once local CDR file creation is enabled, you can configure push receivers to push any non-active and closed CDR files to an FTP server using FTP or SFTP protocols. You configure the OCSBC with the push receiver’s:

  • server IP address and port information
  • login credentials
  • path to save the local CDR Files
  • The interval at which the OCSBC should send files to a push receiver

For flexibility and security, the OCSBC can log into a push receiver with either FTP or SFTP. If you are creating a secure connection with SFTP, your OCSBC can authenticate to the server with either a public shared key or SSH-encrypted username and password.

Bear in mind that the OCSBC deletes a local CDR file after the local CDR file has been successfully transferred to a push receiver.

Local CDR File Format

The CDRs are written as comma-delimited ASCII records to files on the OCSBC. The types of records are controlled by the same accounting configuration parameters used for RADIUS. The fields of the comma-delimited entries correspond to RADIUS START, INTERIM, and STOP records. Using the accounting configuration, you can configure the OCSBC to record STOP records only.

Because the record types do not have consistent field positioning, any server parsing them would need to read the first field to determine the type and learn how to parse the remaining fields.

Local CDR File Format Consistency

Unpopulated or unused fields in the RADIUS CDR are omitted from the locally-stored CSV file. This means that there is no fixed position for a RADIUS attribute across all CSV files. Instead, the missing values are skipped in the CSV file so that the order and appearance for attribute values can differ from record to record.

You can optionally guarantee the placement of attributes in locally-stored CSV files with the cdr-output-inclusive parameter. With this enhancement enabled, RADIUS records sent to a RADIUS client contain even empty attributes with an integer, date and time, or IP address format; the default value is zero. In other words, when there is no value to report:

  • An IP address attribute will report as 0.0.0.0
  • A date and time attribute will report as 00:00:00.000 UTC Jan 01 1970
  • An integer attribute value will report as 0

To maintain RFC 2865 and 2866 compliance, the Oracle Communications Session Border Controller will not send empty attributes that are string values to a RADIUS client. And when you enable this feature, the Oracle Communications Session Border Controller adds all attributes to the locally-stored CSV file.

Refer to Appendix B of this document for an example of where VSAs appear in a locally-generated CSV file for a successful Interim record.

Generate Local CDR Layout Files

Numerous factors determine the layout of local CDR files. In order to obtain an accurate local CDR layout, the SBC can write a special CDR layout file that only includes the data layout for your local CDRs based on your configuration. You can then use this file to interpret local CDR files with the proper data field order, source and identification label.

You can configure the system to produce CDR layout files with the dump_csv_format command at the superuser prompt.

ORACLE# dump_csv_format

This function uses the same process, input and output mechanisms the system uses to produce local CDRs. While this command is activated, the system produces layout files instead of actual CDRs. Once the layout files have been obtained, turn the generation feature off with the no_dump_csv_format command at the superuser prompt.

Format files are written to the same directory as local CDR files, and they use the same naming convention as local CDR files. Refer to local CDR generation instructions to identify the files you intend to retrieve, based on your configuration for rotation, naming, file size, and so forth.

Note that the push-receiver configuration may not be an efficient means of retrieving your local CDR format files because they are configured for time and size windows appropriate for CDR collection. Use SFTP manually to control what and when you retrieve.

Preform this procedure in a maintenance window. You must have complete control over prototype calls. Limit them to a single successful, and depending on your configuration, single unsuccessful call. The following is the general procedure used to capture local CDR layout files.

  1. Turn on dump_csv_format from the system's enable prompt. The system stops generating local CDR files, generating local CDR format files instead.
  2. Place a successful call.
  3. Complete the call.
  4. If you are configured for INTERIM generation upon an unsuccessful call, place an unsuccessful call.
  5. Depending on your configuration, identify the file that has the format. For example, if using rotation you may decide to wait for the data to rotate from the temp file to be sure the file is closed.
  6. Use SFTP to retrieve the layout file from the local CDR directory.
  7. Turn off the feature using no_dump_csv_format. The system begins to generate local CDR files again.
  8. Use the files to identify your CDR format and establish your collection and collation process.

Local CDR Layout File Reference and Example

Local CDR Layout File Reference and Example

The first line of every record contains the following comma-delimited information:

"1", "Accounting Status", ,"40",["## START ##" | "## INTERIM ##" | "##STOP##"]

Each line after the initial line of each record contains the following comma-delimited information:

<CDR Attribute position>,<CDR Attribute Name>,<VSA Vendor>,<VSA Number>

The CDR Attribute name only presents the shorthand of the attribute. Cross-reference the VSA number with the RADIUS dictionary to obtain the full VSA name.

The following is an example of the first 10 rows of a CDR Layout file, start record.

1,"Accounting Status",,40,## START ##
2,"NAS IP Address",,4
3,"NAS Port",,5
4,"Accounting Session ID",,44
5,"Ingress Session ID",ACME,3
6,"Egress Session ID",ACME,4
7,"Session Protocol Type",ACME,43
8,"Session-Forked-Call-Id",ACME,171
9,"Generic ID",ACME,40
10,"Calling Station ID",,31

Requirements

If you want to guarantee the CSV placement for RADIUS attribute values, you must use the entire RADIUS dictionary. You cannot use the RADIUS CDR abbreviation feature. Using an abbreviated form of the RADIUS dictionary results in adverse effects for the CSV file.

In your configuration, then, you must set the vsa-id-range parameter to use the entire range of attributes. Leaving this parameter blank disables abbreviation and all attributes are included. Alternatively, you can specify all of the parameters (by attribute number) that are used in the OS release loaded on your system.

See the RADIUS CDR Content Control section for more information.

Local CDR File Naming Convention

Filenames are derived from the date and time that the CDR file is opened for writing. The format is cdrYYYYMMDDHHMM[a-j], where:

  • YYYY=the year
  • MM=the month
  • DD=the day
  • HH=the hour
  • MM=the minute
  • [a-j]=a suffix that provides additional discrimination in case of changing system time, setting the rotation time for this feature to one minute, or in case of another occurrence that might compromise the date and time

Your file name will resemble the following sample: cdr200511151200.

Call Detail Record Sequence Number in Filename

To assist in the identification of lost Call Detail Record (CDR) files, the customer can enable the file-seq-number attribute to assign a sequence number to append to the file. A separate configuration element, temp-remote-file, allows for the prepending of the characters "tmp-" to CDR files during transfer.

Sometimes there are failures in the transmission of CDR files due to underlying network or infrastructure issues. Customers can identify missing files through the combination of a timestamp (YYYYMMDDMM) and 9-digit unique sequence numbers (SNs) appended to the file. This behavior is enabled through the file-seq-number attribute. The SN will start from one at boot time. This attribute replaces the use of alpha characters (a-z) appended to the CDR file name when more than one file is created in the same minute.

Separately, one can set the temp-remote-file attribute so the characters "tmp-" are prepended to the CDR file during transfer. Once delivered, the file will be renamed on the remote host to remove "tmp-".

For example, with both attributes enabled, a file named tmp-cdr<timestamp>-<9-digit-sequence-number> would be created and upon complete transfer to the destination renamed cdr<timestamp>-<9-digit-sequence-number>.

CDR Sequence Number in Filename Configuration

To assist in the identification of lost Call Detail Record (CDR) files, the customer can enable the file-seq-number attribute to allow a sequence number to append to the file.

  1. Access the account-config configuration element.
    ORACLE# configure terminal
    ORACLE(configure)# session-router
    ORACLE(session-router)# account-config
    ORACLE(account-config)#
    
  2. Type select to begin configuring this object.
  3. file-seq-number—set this to enabled for the system to assign a 9 digit file sequence number to append to a CDR file. The default is disabled.
    • enabled | disabled
  4. Type done to save your configuration.

Temp-remote-file creation for CDR files during transfer Configuration

The configuration element temp-remote-file allows for the prepending of the characters "tmp-" to Call Detail Record (CDR) files during transfer. When the transfer ends successfully, the system removes the characters "tmp-".

  1. Access the push-receiver configuration element.
    ORACLE# configure terminal
    ORACLE(configure)# session-router
    ORACLE(session-router)# account-config
    ORACLE(account-config)# push-receiver
    ORACLE(push-receiver)#
  2. Select the push-receiver object to edit.
    ORACLE(push-receiver)# select
    server:
    1: server = 192.168.100.101, port = 21
    
    selection: 1
    ORACLE(push-receiver)#
  3. temp-remote-file—set the state of this element to enabled for the system to prepend the characters "tmp-" to a CDR file during transfer. The default is disabled
    • enabled | disabled
  4. Type done to save your configuration.

Local CDR File Storage Directories

The OCSBC only allows local storage of ASCII CDRs to the /opt and /opt/logs directories. If you try to save to another directory (such as /code or /boot), you will receive an error message.

If you are using the ACLI and enter an inappropriate directory, the ACLI will issue an error message.

Local CDR File Size and Rotation

You can configure maximum file size, maximum number of local CSV files to store, and the interval at which the files rotate.

The OCSBC saves up to the file size limit (max file size) and maintains only number of files that you configure (max files). When the maximum file size is reached, the OCSBC closes that file and begins writing VSA attributes and values to a new local CDR file. When it is time for the OCSBC to write the max files + 1 file, the oldest file is deleted so that the newest one can be stored.

More About File Rotation Time

You can use the CDR local storage feature on its own, without enabling the ftp push feature. The OCSBC uses a period of time that you set to periodically rotate the files. The file rotate time parameter rotates the local CSV files regardless of whether you use the FTP push feature.

RADIUS CDR Redundancy

When you are using the RADIUS CDR storage and FTP push feature, the OCSBC can create a redundant copy of the comma-delimited CDR files that it stores on the standby system in the HA node.

This enhancement to the CDR storage feature ensures against data loss if, for example, an active OCSBC fails immediately before an FTP push. The standby has a duplicate set of records that it sends. This feature is enabled with the CDR output redundancy parameter found in the account config configuration element.

Caveats for H.323

H.323 calls proceed without interruption over an HA node in the event of a failover from one OCSBC to another, and RADIUS records are generated and duplicated across the active and standby systems in an HA node. However if a switchover occurs during an H.323 call (that has been initiated, but not completed), the newly active (formerly standby) system will not generate RADIUS Stop records when the call completes.

FTP Push

The FTP push feature is used to copy local CDR files to a remote FTP server on a periodic basis. This feature is configured by defining push receivers which contain standard login and FTP server credentials of the remote machine. At the configured time interval (file rotate time), the OCSBC closes the current file, and pushes the files that are complete and have not yet been pushed; including the just-closed-file.

Deprecated ACLI Configuration

The following parameters in the account-config configuration element are deprecated:

  • ftp-address
  • ftp-port
  • ftp-user
  • ftp-password
  • ftp-remote-path

These parameters will only be used if no account-config, push-receiver configuration elements have been defined. All new push receivers must be defined in the account-config, push-receiver configuration element.

Multiple Push Receivers

OCSBC now supports up to five CDR push receivers for use with the local file storage and FTP push feature. For each receiver you configure, you can set the file transfer protocol you want to use—either FTP or SFTP. The system uses the push receivers according to the priorities you set by giving a 0 through 4 priority number to the server when you configure it; 0 is the highest priority, and 4 is the lowest. By default, push receivers always have their priority at the lowest setting (4).

Based on the priority level you set, the OCSBC uses a strategy (which you also set) to select a CDR push receiver. If the highest priority push receiver selected using the strategy becomes unavailable (i.e., times out), the OCSBC uses the strategy (hunt, round robin, etc.) to select another.

This feature is dynamically configurable. When you change the configuration, the OCSBC updates the list of push receivers if it has changed.

Push Receivers

A push receiver configuration includes all the credentials that the OCSBC needs to log into an FTP server and upload any recent local CDR files. Push receiver configurations must include:

  • the server’s IP address and port
  • remote path of where to upload the local CDR files
  • protocol used to connect to the server
  • account login credentials

Secure FTP Push Configuration

You can configure the Oracle Communications Session Border Controller (OCSBC) to securely log on to a push receiver using one of the following methods that creates a secure connection.

Password authentication—Set the protocol parameter on the push receiver to SFTP, configure a username and password, and leave the public-key parameter blank. Note that you must also import the host key from the SFTP server to the OCSBC for this type of authentication.

Public key authentication—Set the protocol parameter on the push receiver to SFTP, set the public-key parameter to a configured public key record name including an account username, and configure your SFTP server with the public key pair from the OCSBC.

It is often difficult to determine whether the SFTP server uses its RSA key or its DSA key for its server application. For this reason, Oracle recommends that you import both the RSA key and the DSA key to the OCSBC to ensure a successful FTP Push.

It is also common for the SFTP server to run the Linux operating system. For Linux, the command ssh-keygen-e creates the public key that you need to import to the OCSBC. The ssh-keygen-e command sequence requires you to specify the file export type, as follows.

[linux-vpn-1 ~]# ssh-keygen -e
Enter file in which the key is (/root/.ssh/id_rsa/): /etc/ssh/ssh_host_rsa_key.pub

If you cannot access the SFTP server directly, but you can access it from another Linux host, use the ssh-keyscan command to get the key. An example command line follows.

root@server:~$ssh-keyscan -t dsa sftp.server.com

ACLI Instructions and Examples

This section shows you how to configure Local CDR storage and FTP push on your OCSBC.

Accessing the Accounting Configuration

To configure parameter for these features, you must access the accounting configuration.

To access the accounting configuration:

  1. In Superuser mode, type configure terminal and press Enter.
    ORACLE# configure terminal
  2. Type session-router and press Enter.
    ORACLE(configure)# session-router
  3. Type account-config and press Enter.
    ORACLE(session-router)# account-config
    ORACLE(account-config)#

    From here, you can enable local CDR storage and FTP push.

Enabling Local CDR Storage

To enable local CDR storage:

  1. file-output—Enable this parameter for the OCSBC to create comma-delimited CDRs (generated from RADIUS records). By default, this parameter is disabled.
  2. file-path—You must configure this path for the CDR push feature to work. Set the path to use on the OCSBC for file storage:
    • /opt

    • /opt/logs

      To use FTP push, you must configure a usable path.

      Note:

      When a Hard Disk Drive is available, you may opt to store CDRs in the data-disk.
  3. max-file-size—Set the maximum CDR file size in bytes. The default and minimum value is 1000000. Oracle recommends you limit local CDR storage on your system to 30M. For example, if you retain the max-file-size default, set max-files to 30. However, if you are using a Storage Expansion Module the maximum value is 108.
  4. max-files—Set the maximum number of files to be stored on the OCSBC at one time. The parameter's value range is from 0 to unlimited. The user should consider the max-file-size setting, the 30M recommendation, and their preferences to specify this value. The default is 5.
  5. file-rotate-time—Set how often in minutes you want to rotate the stored files; the OCSBC will overwrite the oldest file first. The minimum rotation time is 2 minutes; the default is 60 minutes. This parameter defaults to 0, and leaving it set to the default means that the OCSBC will not rotate the files.
  6. cdr-output-redundancy—Set this parameter to enabled for the OCSBC to store a redundant copy of the local CSV file to the standby HA node. Set this parameter to standby-push to enable the function and enable local storage and implement push capabilities on an HA deployment's standby to protect against CDR data loss.

Configuring a Push Receiver Fallback Method

You set the push receiver strategy and define the maximum timeout in seconds in the main accounting configuration.

Note:

You may ignore the following two parameters if only one push receiver is configured.
  1. ftp-strategy—Set the strategy you want the OCSBC to use when selecting from multiple push receivers. The default is hunt.
    • Hunt—The OCSBC selects the push receiver from the available list according the priority level. The system uses this strategy as its default.
    • Failover—The OCSBC selects the push receiver based on priority level and will continue to use that same push receiver until it fails over.
    • RoundRobin—The OCSBC selects push receivers systematically one after another, balancing the load among all responsive push receivers.
    • FastestRTT—The OCSBC selects the push receiver based on best average throughput. For this situation, throughput is the number of bytes transferred divided by the response time. The system uses a running average of the five most recent throughput values to accommodate for network load fluctuations.
  2. ftp-max-wait-failover—Enter the amount of time in seconds to wait before the OCSBC declares a push receiver to have failed over. This default value for this parameter is 60.

Setting the CSV File Format

This section shows you how to guarantee the CSV placement for RADIUS attribute values by using the entire RADIUS dictionary.

To enable fixed value placement in CSV files for RADIUS CDRs:

  1. In Superuser mode, type configure terminal and press Enter.
    ORACLE# configure terminal
    ORACLE(configure)#
  2. Type session-router and press Enter.
    ORACLE(configure)# session-router
  3. Type account-config and press Enter.
    ORACLE(session-router)# account-config
    ORACLE(account-config)#

    If you are adding support for this feature to a pre-existing accounting configuration, then you must use the ACLI select command so that you can edit it.

  4. vsa-id-range—Either leave this parameter blank (default), or enter the complete range of VSAs loaded on your system. The following example shows what you mightenter to use all of the VSAs for for a system that is not running QoS.
    ORACLE(account-config)# vsa-id-range 1-4,10-14,20-24,28,29,32-71,74-136
  5. cdr-output-inclusive—When disabled (default), the system excludes fields that have no data from the CSV file. Set to enabled to make the system include all fields in every CSV file. This ensures that there are always the same number of fields in all equivalent records. Start records would always have the same number of fields. The same would be true of interim and stop records.

Enabling FTP Push

To enable FTP push:

  1. In Superuser mode, type configure terminal and press Enter.
    ORACLE# configure terminal
    ORACLE(configure)#
  2. Type session-router and press Enter.
    ORACLE(configure)# session-router
  3. Type account-config and press Enter.
    ORACLE(session-router)# account-config

    If you are adding support for this feature to a pre-existing accounting configuration, then you must use the ACLI select command so that you can edit it.

  4. ftp-push—Set the state of FTP push feature to enabled. It is disabled by default.
  5. Type push-receiver and press Enter.
    ORACLE(account-config)# push-receiver
  6. server—Enter the IP address of this push receiver FTP server.
  7. port—Enter the port number of this push receiver FTP server.
  8. remote-path—Enter the remote pathname to which you want CDR files to be sent on the push receiver. There is no default for this parameter.
  9. filename-prefix—Enter the filename prefix (as a string) to prepend to the to the CDR files the OCSBC sends to the push receiver. The OCSBC does not rename local files. There is no default for this parameter.
  10. protocol—Enter SFTP if you want to change the transport protocol for this push receiver from its default, FTP.
  11. username—Enter the username the OCSBC uses when connecting to this push receiver. There is no default for this parameter. This parameter is always required.
  12. password—Enter the password corresponding to the username the OCSBC uses when connecting to this push receiver. There is no default for this parameter. You can leave this field blank if you are using public key authentication. Profile configuration is required for both password and public key authentication.
  13. public-key—Enter the public key profile to use for authentication to this push receiver and decryption of this servers packets. Note the procedure below, which tells you how to create a public key profile. You can leave this field blank if you are using password authentication. Profile configuration is required for both password and public key authentication.
  14. Save and activate your configuration.

Creating a Public Key Profile

The Secure Shell (SSH) and related Secure Shell File Transfer (SFTP) protocols provide for the secure transfer of audit files and for the secure transfer of management traffic across the wancom0 interface. When using password or public key authentication with push receiver configurations, use the procedures described below to create your profiles.

Create your profile by configuring:

  • SSH Properties
  • Import an SSH Host Key
  • Create the public key profile

The following two tasks are required for public key authentication mode only.

  • Generate an SSH Key Pair
  • Copy the OCSBC public key to the SFTP server

After the above, you can use this profile within the context of your FTP push configuration.

SSH Operations

SSH Version 2.0, the only version supported on the Oracle OCSBC, is defined by a series of five RFCs.

  • RFC 4250, The Secure Shell (SSH) Protocol Assigned Numbers
  • RFC 4251, The Secure Shell (SSH) Protocol Architecture
  • RFC 4252, The Secure Shell (SSH) Authentication Protocol
  • RFC 4253, The Secure Shell (SSH) Transport Layer Protocol
  • RFC 4254, The Secure Shell (SSH) Connection Protocol

RFCs 4252 and 4253 are most relevant to OCSBC operations.

The transport layer protocol (RFC 4253) provides algorithm negotiation and key exchange. The key exchange includes server authentication and results in a cryptographically secured connection that provides integrity, confidentiality and optional compression. Forward security is provided through a Diffie-Hellman key agreement. This key agreement results in a shared session key. The rest of the session is encrypted using a symmetric cipher, currently 128-bitAES, Blowfish, 3DES, CAST128, Arcfour, 192-bit AES, or 256-bit AES. The client selects the encryption algorithm to use from those offered by the server. Additionally, session integrity is provided through a crypto-graphic message authentication code (hmac-md5, hmac-sha1, umac-64 or hmac-ripemd160).

The authentication protocol (RFC 4252) uses this secure connection provided and supported by the transport layer. It provides several mechanisms for user authentication. Two modes are supported by the OCSBC: traditional password authentication and public-key authentication.

ACLI Instructions and Examples

This section provides ACLI procedures for SFTP push configurations, including SSH property configuration, certificate import, and public key profile configuration on your OCSBC.

Configure SSH Properties

The single instance ssh-config configuration element specifies SSH re-keying thresholds.

  1. Access the admin-security configuration element.
    ORACLE# configure terminal
    ORACLE(configure)# security
    ORACLE(security)# admin-security
     
  2. Access the ssh-config subelement.
    ORACLE(admin-security)# ssh-config
    ORACLE(ssh-config)#
  3. rekey-interval—specifies the maximum allowed interval, in minutes, between SSH key negotiations.

    Allowable values are integers within the range 60 through 600, with a default of 60 (minutes). Shorter lifetimes provide more secure connections.

    Works in conjunction with rekey-byte-count, which sets a packet-based threshold, to trigger an SSH renegotiation. If either trigger is activated, an SSH renegotiation is begun.

    Retain the default value, or specify a new value.

    ragnarok(ssh-config)# rekey-interval 20
    ragnarok(ssh-config) 
  4. rekey-byte-count—specifies the maximum allowed send and receive packet count, in powers of 2, between SSH key negotiations

    Allowable values are integers within the range 20 (1,048,576 packets) through 31 (2,147,483,648 packets), with a default of 31 (231). Smaller packet counts provide more secure connections.

    Works in conjunction with rekey-interval, which sets a time-based threshold, to trigger an SSH renegotiation. If either trigger is activated, an SSH renegotiation is begun.

    Retain the default value, or specify a new value.

    ragnarok(ssh-config)# rekey-packet-count 24
    ragnarok(ssh-config) 

    A sample SSH configuration appears below:

    ragnarok(ssh-config)# rekey-interval 20 
    ragnarok(ssh-config)# done 
    ragnarok(ssh-config)# exit 
    ragnarok(admin-security)# 

    Specifies a key renegotiation every 20 minutes, or at the reception/transmission of 2,147,483,648 packets, whichever comes first.

Import an SSH host Key

Importing a host key requires access to the SFTP server or servers which receive audit log transfers. Access is generally most easily accomplished with a terminal emulation program such as PuTTY, SecureCRT, or TeraTerm.

  1. Use a terminal emulation program to access the SSH file system on a configured SFTP server.
  2. Copy the server’s base64 encoded public file making sure in include the Begin and End markers as specified by RFC 4716, The Secure Shell (SSH) Public Key File Format.

    For OpenSSH implementations host files are generally found at /etc/ssh/ssh_host_dsa_key.pub, or /etc/ssh/sss_host_rsa.pub. Other SSH implementations can differ.

  3. From admin mode use the ssh-pub-key command to import the host key to the OCSBC.

    For importing a host key, this command takes the format:

    ssh-pub-key import known-host <name>

    where name is an alias or handle assigned to the imported host key, generally the server name or a description of the server function.

    ORACLE# ssh-pub-key import known-host fedallah
    
    IMPORTANT:
    Please paste ssh public key in the format defined in rfc4716.
    Terminate the key with ";" to exit.......
  4. Paste the public key with the bracketing Begin and End markers at the cursor point.
  5. Enter a semi-colon (;) to signal the end of the imported host key.
  6. Follow directions to save and activate the configuration.

    The entire import sequence is shown below.

    ORACLE# ssh-pub-key import known-host fedallah
    
    IMPORTANT:
        Please paste ssh public key in the format defined in rfc4716.
        Terminate the key with ";" to exit.......
    
    ---- BEGIN SSH2 PUBLIC KEY ----
    Comment: "2048-bit RSA, converted from OpenSSH by klee@acme54"
    AAAAB3NzaC1yc2EAAAABIwAAAQEA7OBf08jJe7MSMgerjDTgZpbPblrX4n17LQJgPC7clL
    cDGEtKSiVt5MjcSav3v6AEN2pYZihOxd2Zzismpoo019kkJ56s/IjGstEzqXMKHKUr9mBV
    qvqIEOTqbowEi5sz2AP31GUjQTCKZRF1XOQx8A44vHZCum93/jfNRsnWQ1mhHmaZMmT2LS
    hOr4J/Nlp+vpsvpdrolV6Ftz5eiVfgocxrDrjNcVtsAMyLBpDdL6e9XebQzGSS92TPuKP/
    yqzLJ2G5NVFhxdw5i+FvdHz1vBdvB505y2QPj/iz1u3TA/3O7tyntBOb7beDyIrg64Azc8
    G7E3AGiH49LnBtlQf/aw==
    ---- END SSH2 PUBLIC KEY ----
    ;
    SSH public key imported successfully....
    WARNING: Configuration changed, run "save-config" command to save it
    and run "activate-config" to activate the changes
    ORACLE# save-config
    checking configuration
    ---------------------------------------------------------------------
    ...
    ...
    ...
    ---------------------------------------------------------------------
    Save-Config received, processing.
    waiting for request to finish
    Request to 'SAVE-CONFIG' has Finished,
    Save complete
    Currently active and saved configurations do not match!
    To sync & activate, run 'activate-config' or 'reboot activate'.
    ORACLE# activate-config
    Activate-Config received, processing.
    waiting for request to finish
    SD is not QOS-capable
    Request to 'ACTIVATE-CONFIG' has Finished,
    Activate Complete
    ORACLE#

    It is important to note that it is often difficult to determine whether the server is using RSA or DSA keys for your application. Unless you can definitively determine this, bear in mind that you need to try importing both.

Create the Public Key Record

The initial step in generating an SSH key pair is to configure a public key record which will serve as a container for the generated key pair.

  1. Navigate to the public-key configuration element.
    ORACLE# configure terminal
    ORACLE(configure)# security
    ORACLE(security)# public-key
    ORACLE(public-key)#
  2. Use the name command to provide the object name, and the show command to verify object creation.
    ORACLE(public-key)# name KeyTest
    ORACLE(public-key)# show
    public-key
            name                                    KeyTest
            type                                    rsa
            size                                    1024
            last-modified-by
            last-modified-date

    This command creates a public key record named tashtego.

  3. Use the done command to complete object creation.
    ORACLE(public-key)# done
    public-key
            name                                    KeyTest
            type                                    rsa
            size                                    1024
            last-modified-by                        admin@console
            last-modified-date                      2014-05-14 14:40:55
    
    ORACLE(public-key)#
  4. Make a note of the last-modified-date time value.
  5. Move back to admin mode, and save and activate the configuration.
    ORACLE(public-key)# exit 
    ORACLE(security)# exit 
    ORACLE(configure)# exit 
    ORACLE# 
    
    ORACLE# save-config 
    ... 
    ... 
    ... 
    ORACLE# activate-config 
    ... 
    ... 
    ... 
    ORACLE#

Generate an SSH key pair

  1. Now use the ssh-pub-key generate command, in conjunction with the name of the public key record created in Step 3, to generate an SSH key pair.

    For importing an SSH key pair, this command takes the format:

    ssh-pub-key generate <name>

    where name is an alias or handle assigned to the generated key pair, generally the client name or a description of the client function.

    ORACLE# ssh-pub-key generate tashtego
    Please wait...
    public-key 'tashtego' (RFC 4716/SECSH format):
    ---- BEGIN SSH2 PUBLIC KEY ----
    Comment: "1024-bit rsa"
    AAAAB3NzaC1yc2EAAAABIwAAAIEArZEP1/WiYsdGd/Pi8V6pnSwV4cVG4U+jVOwiSwNJCC9Nk82/FKYleLZevy9D3lrZ8ytvu+sCYy0fNk4nwvz20c2N+r86kDru88JkUqpelJDx1AR718Icpr7ZaAx2L+e7cpyRSXCgbQR7rXu2H3bp9Jc0VhR2fmkclmrGAIr7Gnc=
    ---- END SSH2 PUBLIC KEY ----
    
    SSH public-key pair generated successfully....
    WARNING: Configuration changed, run "save-config" command to save it and run "activate-config" to activate the changes
    ORACLE#
  2. Copy the base64-encoded public key. Copy only the actual public key — do not copy the bracketing Begin and End markers nor any comments. Shortly you will paste the public key to one or more SFTP servers.
  3. Save and activate the configuration.
    ORACLE# save-config
    ...
    ...
    ...
    ORACLE# activate-config
    ...
    ...
    ...
  4. Return to the public-key configuration object, and select the target public key record instance.
    ORACLE# configure terminal
    ORACLE(configure)# security
    ORACLE(security)# public-key
    ORACLE(public-key)# sel
    <name>:
    1: acme01
    2: acme02
    3: tashtego
    
    selection: 3
    ORACLE(public-key)# show
    public-key
            name                tashtego
            type                rsa
            size                1024
            last-modified-by    admin@console
            last-modified-date  2009-03-06 11:24:32
    ORACLE(public-key)#
  5. Verify that the record has been updated to reflect key generation by examining the value of the last-modified-date field.

Copy the RSA Public Key to the SFTP Server

Copy the RSA public key from the from the Oracle Communications Session Border Controller (OCSBC) to the authorized_keys file in the .ssh directory on the SFTP server.

  • Confirm that the .ssh directory exists on the SFTP server.
  • Confirm the following permissions: Chmod 700 for .ssh and Chmod 600 for authorized_keys.

When adding the RSA key to the authorized_keys file, ensure that no spaces occur inside the key. Insert one space between the ssh-rsa prefix and the key. Insert one space between the key and the suffix. For example, ssh-rsa <key> root@1.1.1.1.

  1. Access the SSH file system on a configured SFTP server with a terminal emulation program.
  2. Copy the RSA key to the SFTP server, using a text editor such as vi or emacs, and paste the RSA key to the end of the authorized_keys file.

View a Public key on the OCSBC

You can use the show security ssh-pub-key command to display information about SSH keys imported to the OCSBC with the ssh-pub-key command; you cannot display information about keys generated by the ssh-pub-key command.

ORACLE# show security ssh-pub-key brief
login-name:
	acme74
finger-print:
	51:2f:f1:dd:79:9e:64:85:6f:22:3d:fe:99:1f:c8:21
finger-print-raw:
	0a:ba:d8:ef:bb:b4:41:d0:dd:42:b0:6f:6b:50:97:31

login-name:
	fedallah
finger-print:
	c4:a0:eb:79:5b:19:01:f1:9c:50:b3:6a:6a:7c:63:d5
finger-print-raw:
	ac:27:58:14:a9:7e:83:fd:61:c0:5c:c8:ef:78:e0:9c
ORACLE#

This command displays summary information for all SSH imported keys.

  • login-name: contains the name assigned to the RSA or DSA public key when it was first imported.
  • finger-print: contains the output of an MD5 hash computed across the base64-encoded public key.
  • finger-print-raw: contains the output of an MD5 hash computed across the binary form of the public key
ORACLE# show security ssh-pub-key brief fedallah 
login-name: 
	fedallah 
finger-print: 
	c4:a0:eb:79:5b:19:01:f1:9c:50:b3:6a:6a:7c:63:d5 
finger-print-raw: 
	ac:27:58:14:a9:7e:83:fd:61:c0:5c:c8:ef:78:e0:9c 
ORACLE#

This command displays summary information for a specific SSH public key (in this case fedallah).

ORACLE# show security ssh-pub-key detail fedallah 
host-name: 
	fedallah 
comment: 
	"2048-bit RSA, converted from OpenSSH by klee@acme54" 
finger-print: 
	c4:a0:eb:79:5b:19:01:f1:9c:50:b3:6a:6a:7c:63:d5 
finger-print-raw: 
	ac:27:58:14:a9:7e:83:fd:61:c0:5c:c8:ef:78:e0:9c 
pub-key: 

AAAAB3NzaC1yc2EAAAABIwAAAQEA7OBf08jJe7MSMgerjDTgZpbPblrX4n17LQJgPC7clLcDGEtKSiVt5MjcSav3v6AEN2pYZihOxd2Zzismpoo019kkJ56s/IjGstEzqXMKHKUr9mBVqvqIEOTqbowEi5sz2AP31GUjQTCKZRF1XOQx8A44vHZCum93/jfNRsnWQ1mhHmaZMmT2LShOr4J/Nlp+vpsvpdrolV6Ftz5eiVfgocxrDrjNcVtsAMyLBpDdL6e9XebQzGSS92TPuKP/yqzLJ2G5NVFhxdw5i+FvdHz1vBdvB505y2QPj/iz1u3TA/3O7tyntBOb7beDyIrg64Azc8G7E3AGiH49LnBtlQf/aw== 

modulus: (256) 
ECE05FD3C8C97BB3123207AB8C34E06696CF6E5AD7E27D7B2D02603C2EDC94B703184B4A4A256DE4C8DC49ABF7BFA004376A5866284EC5DD99CE2B26A68A34D7D924279EACFC88C6B2D133A9730A1CA52BF66055AAFA8810E4EA6E8C048B9B33D803F7D4652341308A6511755CE431F00E38BC7642BA6F77FE37CD46C9D64359A11E66993264F62D284EAF827F365A7EBE9B2FA5DAE8955E85B73E5E8957E0A1CC6B0EB8CD715B6C00CC8B0690DD2FA7BD5DE6D0CC6492F764CFB8A3FFCAACCB2761B9355161C5DC398BE16F747CF5BC176F079D39CB640F8FF8B3D6EDD303FDCEEEDCA7B4139BEDB783C88AE0EB803373C1BB137006887E3D2E706D9507FF6B 
exponent: (1) 
23 
ORACLE# 

This command displays detailed information for specific SSH public key (in this case fedallah, an RSA key).

  • host-name: contains the name assigned to the RSA key when it was first imported
  • finger-print: contains the output of an MD5 hash computed across the base64-encoded RSA public key
  • finger-print-raw: contains the output of an MD5 hash computed across the binary form of the RSA public key
  • public key: contains the base64-encoded RSA key
  • modulus: contains the hexadecimal modulus (256) of the RSA key
  • exponent: (also known as public exponent or encryption exponent) contains an integer value that is used during the RSA key generation algorithm. Commonly used values are 17 and 65537. A prime exponent greater than 2 is generally used for more efficient key generation.
ORACLE# show security ssh-pub-key detail acme74 
host-name: 
	acme74 
comment: 
	DSA Public Key 
finger-print: 
	51:2f:f1:dd:79:9e:64:85:6f:22:3d:fe:99:1f:c8:21 
finger-print-raw: 
	0a:ba:d8:ef:bb:b4:41:d0:dd:42:b0:6f:6b:50:97:31 
pub-key: 

AAAAB3NzaC1kc3MAAACBAPY8ZOHY2yFSJA6XYC9HRwNHxaehvx5wOJ0rzZdzoSOXxbETW6ToHv8D1UJ/z+zHo9Fiko5XybZnDIaBDHtblQ+Yp7StxyltHnXF1YLfKD1G4T6JYrdHYI14Om1eg9e4NnCRleaqoZPF3UGfZia6bXrGTQf3gJq2e7Yisk/gF+1VAAAAFQDb8D5cvwHWTZDPfX0D2s9Rd7NBvQAAAIEAlN92+Bb7D4KLYk3IwRbXblwXdkPggA4pfdtW9vGfJ0/RHd+NjB4eo1D+0dix6tXwYGN7PKS5R/FXPNwxHPapcj9uL1Jn2AWQ2dsknf+i/FAAvioUPkmdMc0zuWoSOEsSNhVDtX3WdvVcGcBq9cetzrtOKWOocJmJ80qadxTRHtUAAACBAN7CY+KKv1gHpRzFwdQm7HK9bb1LAo2KwaoXnadFgeptNBQeSXG1vO+JsvphVMBJc9HSn24VYtYtsMu74qXviYjziVucWKjjKEb11juqnF0GDlB3VVmxHLmxnAz643WK42Z7dLM5sY29ouezv4Xz2PuMch5VGPP+CDqzCM4loWgV 

p: (128) 
F63C64E1D8DB2152240E97602F47470347C5A7A1BF1E70389D2BCD9773A12397C5B1135BA4E81EFF03D5427FCFECC7A3D162928E57C9B6670C86810C7B5B950F98A7B4ADC7296D1E75C5D582DF283D46E13E8962B747608D783A6D5E83D7B836709195E6AAA193C5DD419F6626BA6D7AC64D07F7809AB67BB622B24FE017ED55 

q: (20) 
DBF03E5CBF01D64D90CF7D7D03DACF5177B341BD 

g: (128) 
94DF76F816FB0F828B624DC8C116D76E5C177643E0800E297DDB56F6F19F274FD11DDF8D8C1E1EA350FED1D8B1EAD5F060637B3CA4B947F1573CDC311CF6A9723F6E2F5267D80590D9DB249DFFA2FC5000BE2A143E499D31CD33B96A12384B12361543B57DD676F55C19C06AF5C7ADCEBB4E2963A8709989F34A9A7714D11ED5 

pub_key: (128) 
DEC263E28ABF5807A51CC5C1D426EC72BD6DBD4B028D8AC1AA179DA74581EA6D34141E4971B5BCEF89B2FA6154C04973D1D29F6E1562D62DB0CBBBE2A5EF8988F3895B9C58A8E32846F5D63BAA9C5D060E50775559B11CB9B19C0CFAE3758AE3667B74B339B18DBDA2E7B3BF85F3D8FB8C721E5518F3FE083AB308CE25A16815 
ORACLE# 

This command displays detailed information for specific SSH public key (in this case acme74, a DSA key).

  • host name: contains the name assigned to the DSA public key when it was first imported
  • comment: contains any comments associated with the DSA key
  • finger-print: contains the output of an MD5 hash computed across the base64-encoded DSA public key
  • finger-print-raw: contains the output of an MD5 hash computed across the binary form of the DSA public key
  • public key: contains the base64 encoded DSA key
  • p: contains the first of two prime numbers used for key generation
  • q: contains the second of two prime numbers used for key generation
  • g: contains an integer that together with p and q are the inputs to the DSA key generation algorithm
ORACLE# show security ssh-pub-key detail 
... 
... 
... 
ORACLE#

This command displays detailed information for all SSH imported keys.