SSH Keys: A Cryptographic Pair for Secure Communication

SSH Keys: A Cryptographic Pair for Secure Communication
Home Page

SSH Keys: A Cryptographic Pair for Secure Communication

SSH (Secure Shell) keys are a pair of cryptographic keys used to secure communication between two parties, typically a client and a server. The two keys in the pair are known as the public key and the private key.

1. Public Key

This key is shared openly and is used by others to encrypt messages or data that can only be decrypted by the corresponding private key. It's safe to share the public key.

2. Private Key

This key is kept secret and should never be shared. The private key is used to decrypt messages or data that have been encrypted with the corresponding public key.

When you want to establish a secure connection to a server using SSH, you generate a pair of SSH keys. You keep the private key on your local machine, and the public key is placed in a special file on the server. When you attempt to connect to the server, the server uses your public key to create a message that can only be decrypted by your private key. If you can successfully decrypt the message, it proves that you possess the corresponding private key, and the server allows you to connect.

SSH keys provide a more secure and convenient way to authenticate compared to traditional password-based authentication. They are commonly used in secure shell connections for system administration, file transfers (using tools like SCP or SFTP), and other secure communication purposes.

Why SSH Keys?

Before diving into the details, let's understand why SSH keys are crucial. SSH keys provide a secure means of authentication through a pair of cryptographic keys - a public key (shared openly) and a private key (kept confidential). This mechanism not only enhances security but also streamlines the authentication process.

Integrating SSH Keys with SFMC

SFMC leverages FTP for data transfers, and incorporating SSH keys strengthens the security posture during these connections. Additionally, SSH keys play a vital role in securing data imports and exports, ensuring the integrity of your marketing data.

Generating SSH Keys

To kickstart the process, generate SSH keys with the following command:

ssh-keygen -t rsa -b 4096 -m PEM

This command creates an RSA key pair with a length of 4096 bits, ensuring robust security. The keys are then encoded in PEM format, a widely adopted standard for cryptographic key encoding.

Understanding PEM Format

The PEM (Privacy Enhanced Mail) format is a widely used file format designed for secure email but now commonly used for various cryptographic data. It provides a human-readable and easily shareable text-based representation for binary data.

Key Characteristics of PEM Format

  1. Textual Representation:
    • PEM files use Base64 encoding to represent binary data in a text format.
    • The encoded data is organized into lines, typically no longer than 64 or 76 characters.
    • Lines often begin with "-----BEGIN" and end with "-----END" markers to identify boundaries.
  2. Markers:
    • PEM files include markers indicating the type of data encoded within.
    • Common markers include "PRIVATE KEY," "CERTIFICATE," and "PUBLIC KEY."
  3. Variety of Data Types:
    • PEM is versatile and encodes various data types, including keys, certificates, and more.
  4. Common Use Cases:
    • Used in SSH keys, X.509 certificates (TLS/SSL), and other cryptographic scenarios.
  5. File Extensions:
    • Common file extensions include ".pem," ".crt," ".key," ".cer," etc.
    • Extensions do not dictate the internal format; it could still be in PEM format.

Example of PEM-Encoded RSA Private Key


        -----BEGIN RSA PRIVATE KEY-----
        MIIEowIBAAKCAQEA2yNtW5AeqBvCrFBLYzL3+7M4T2yi5m0UsNz/l/OaJf+0pI6e
        ...
        9TBo7k5oX61G02e3XQIDAQABAoIBAQC8J2AqfjNxJU+2nDTj4oskklO0+53bdgmM
        ...
        -----END RSA PRIVATE KEY-----
                

Convert Public Key to SSH2 Format

Before configuring SFMC, it's crucial to convert the public key to the SSH2 format. Run the following command:

ssh-keygen -e -f id_rsa.pub -m ssh2 > ssh2_key.pem

This ensures that the public key is in the expected format for SFMC's FTP configuration.

Differences Between SSH1 and SSH2 Formats

  1. Key Exchange Algorithm:
    • SSH1: Primarily uses the "diffie-hellman-group1-sha1" key exchange algorithm.
    • SSH2: Supports multiple key exchange algorithms, including more secure options.
  2. Encryption Algorithms:
    • SSH1: Uses only the IDEA (International Data Encryption Algorithm) for encryption.
    • SSH2: Provides a broader range of encryption algorithms, including AES, 3DES, Blowfish, and others.
  3. Message Authentication Code (MAC):
    • SSH1: Typically uses HMAC-SHA1 for message authentication.
    • SSH2: Supports multiple MAC algorithms, providing flexibility and stronger options like HMAC-SHA256.
  4. Key Lengths:
    • SSH1: Has fixed key lengths and is considered less secure.
    • SSH2: Supports variable key lengths for improved security.
  5. Security Vulnerabilities:
    • SSH1: Deprecated due to security vulnerabilities.
    • SSH2: Developed to address security issues found in SSH1.
  6. Compatibility:
    • SSH1: Some older systems might support SSH1, but its use is discouraged.
    • SSH2: Widely adopted and supported by modern implementations.
  7. Key Format:
    • SSH1 Key Format: Single file for both public and private keys.
    • SSH2 Key Format: Separate files for public and private keys.
  8. Backward Compatibility:
    • SSH1: Not backward-compatible with SSH2.
    • SSH2: Can be backward-compatible with SSH1, but it might introduce security risks.

Create an SSH Key for Use with Marketing Cloud SFTP

Follow these steps to create an SSH key for authenticating your SFTP account in Marketing Cloud:

  1. Create the SSH key using a third-party tool, such as ssh-keygen or puttygen.
    • Use the following standards when creating your key:
      • 4096-bit strength recommended, 2048-bit strength minimum.
      • RSA Key in an OpenSSH2 PEM format.
      • Passphrase accepted but not required.
    • If you create a public key in PUB format, convert it to PEM format using the following code:
      ssh-keygen -e -f ssh_rsa.pub -m ssh2 > ssh2_key.pem
  2. Hover over your name in Marketing Cloud and click Setup.
  3. Under the Data Management heading, select Key Management.
  4. Click Create.
  5. Click SSH.
  6. Enter the name of your key in the Name field.
  7. Leave the external key field blank. After the first handshake, this field auto-populates with the key from the external provider.
  8. Upload the key value to use.
    • Select Public Key.
    • Click Save.
  9. Click FTP Accounts.
  10. Click Add FTP User.
    • By default, the username is the MID number for your current Marketing Cloud MID, including the current parent account or child business unit.
    • Enter an email address for the new FTP user.
    • Enter an initial password for the user. Password complexity requirements combine Marketing Cloud password policy and server-side FTP password requirements. These policies require a minimum of 12 characters and no reuse of the most recent password.
    • Reenter the initial password for the user.
    • Select Read Only or Full for User Permissions.
    • To restrict account access to specific IP addresses, enter each address in the field, and click Add. This field accepts matching, wildcard, range, and mask values.
    • Click Next.
    • Choose the SSH Key, SSH Key or Password, or SSH Key and Password authentication option for the SFTP account.
    • Choose your SSH key in the SSH Keys field.
    • Save your changes. By default, this process creates an enabled, active user as unlocked with a valid current password.
  11. Open your third-party FTP utility.
    • The FTP utility must support SFTP options for password and SSH private key or password only.
    • The SSH Key and Password option requires that you generate and provide the private value of your encryption key for authentication purposes matching one of the public SSH keys assigned to the FTP user.
  12. To access the enhanced SFTP server, update these areas in your FTP utility.
    • Use the SFTP - SSH File Transfer Protocol.
    • To locate your tenant’s FTP URL, navigate to FTP Accounts under Setup.
  13. Save your updates.

Setting Up the Third-Party Server

The third-party server, your data collaborator, needs to be configured to recognize the SSH key. Utilize an FTP client to associate the private key with the server for secure authentication. Ensure that the server recognizes the FTP credentials provided by SFMC.

Azure Linked Services

SFTP connector

Create the new linked service

Streamlining File Transfers

With SSH keys in place, setting up automated file transfers becomes a breeze in SFMC's Automation Studio. Configure the File Transfer Activity to seamlessly move files between SFMC and the third-party server. Specify the FTP account credentials during this setup for a secure and streamlined process.

For more details, you can refer to the following resources:

Conclusion

Incorporating SSH keys into SFMC not only strengthens the security of your file transfers but also enhances the efficiency of your marketing operations. Embrace this cryptographic solution to safeguard your marketing data and streamline your workflows. Elevate your SFMC experience with the power of SSH keys for secure, seamless, and efficient file transfers.


TOP


Comments


Knowledge Article

Most Viewed

CLOUD PAGE ENABLEMENT - PART 1

EMAIL NOT SENT IN JOURNEY BUILDER

CONSIDERATIONS FOR JOURNEY BUILDER

Journey Builder REST API Documentation

Preference Center Demystified

Popular Posts

CLOUD PAGE ENABLEMENT - PART 1

EMAIL NOT SENT IN JOURNEY BUILDER

CONSIDERATIONS FOR JOURNEY BUILDER

Journey Builder REST API Documentation

Preference Center Demystified

SEND LOG EANBLEMENT

Share with Friends

Disclaimer:

The information provided on this technical blog is for general informational purposes only. As a SFMC (Salesforce Marketing Cloud) Technical Architect, I strive to offer accurate and up-to-date content related to SFMC and its associated technologies. However, please note that technology is constantly evolving, and the information provided may become outdated or inaccurate over time.

The content published on this blog represents my personal views and experiences as a SFMC Technical Architect and does not necessarily reflect the official views or opinions of any organization or employer I may be affiliated with.

While I make every effort to ensure the accuracy and reliability of the information presented, I cannot guarantee its completeness, suitability, or applicability to your specific circumstances. Therefore, it is essential to verify any information provided and make your own independent assessments or seek professional advice if needed.

Furthermore, any actions taken based on the information provided on this blog are at your own risk. I shall not be held liable for any damages, losses, or inconveniences arising from the use of the information presented here.

Please keep in mind that SFMC and its associated technologies are complex and require technical expertise for proper implementation and management. It is recommended to consult with qualified professionals or official SFMC documentation for comprehensive guidance.

Finally, please note that any product or company names mentioned on this blog are trademarks or registered trademarks of their respective owners. The mention of these trademarks or registered trademarks does not imply any endorsement or affiliation with the blog.

By accessing and using this blog, you agree to the terms of this disclaimer. If you do not agree with any part of this disclaimer, please refrain from using this blog.