Mercans Official website logo

Official public repository for Mercans' encryption public keys, including key rotations and deprecation notices.

    SSH Public Key Update Process for SFTP Services

    This document outlines the mandatory process to update SSH public keys used for SFTP services. It ensures consistent handling, proper tracking through security Change Requests (CRs), and validation against enterprise security policies.

    1. Preparation: Generate an OpenSSH Public Key

    • Use ssh-keygen to generate a key pair
    ssh-keygen -t ed25519 -C "[email protected]"

    • This creates:
      • Private key (keep secret): id_ed25519
      • Public key (to be submitted): id_ed25519.pub

    OpenSSH Public Key Format:

    <key-type> <base64-encoded-key-data> [comment]

    Example:

    ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIM+9+3LHQf... [email protected]

    2. Calculate the Public Key Fingerprint

    Generate the fingerprint to ensure key integrity and traceability:

    ssh-keygen -lf id_ed25519.pub

    You will see output like:

    256 SHA256:abcdef1234567890abcdef1234567890abcdef user@host (ED25519)

    3. Open a Security Change Request (CR)

    Submit a CR in the appropriate ITSM/change management system with the following content:

    • Title: SSH Public Key Update for SFTP – [User/Service Name]
    • Requester: Requester’s full name and contact information
    • SSH Public Key: Full key line in OpenSSH format
    • Key Type: (e.g., ed25519, rsa)
    • Fingerprint: SHA256 form (as above)
    • Affected Systems/Accounts: List of SFTP users and servers
    • Justification: Reason for key update (e.g., rotation, expiry, compromise)
    • Effective Date/Time: Requested implementation window
    • Implementation Steps: Including validation and rollback plan

    4. Trusted Signatory Requirement

    IMPORTANT: The CR must be reviewed and signed by a designated security personnel listed in the current Trusted Source List (TSL). This ensures that only authorized personnel can approve changes affecting secure service access mechanisms.
    • If the CR is submitted without a valid signature from a TSL entity, it will be rejected.
    • Confirm the current TSL via the organizationʼs internal knowledge base or governance contacts.

    Signature Requirements

    • Include the full name, title, and email of the authorized signatory.
    • Digital signature or internal platform approval traceability must be retained with the CR record.

    5. Security Review & Approval

    The security team will review the CR, verifying:

    • Valid key format (OpenSSH mandatory)
    • Accuracy of fingerprint
    • Security integrity of the request
    • Appropriate signatory approval from the TSL

    References