ISO 27000 is a family of standards focused on information security management systems (ISMS). Within this series, some standards are normative, meaning they define essential requirements, while others are informative, providing guidelines and recommendations.
Difference Between Normative and Informative Standards
Normative standards are mandatory for certification and compliance. They establish requirements that organizations must follow to achieve ISO certification.
Informative standards provide guidance and best practices but are not required for certification. They help organizations understand and implement security measures effectively.
Among the ISO 27000 series, ISO 27001, ISO 27006, and ISO 27009 are normative, making them crucial for compliance and certification. This blog post will explain each of these in detail and provide an overview of the informative standards in the series.
Normative ISO Standards in the 27000 Series
ISO 27001: The Foundation of ISMS
ISO 27001 is the core standard in the ISO 27000 series, specifying requirements for establishing, implementing, maintaining, and continually improving an ISMS. It provides a risk-based approach to information security, requiring organizations to:
Define a risk management process
Establish policies and objectives for information security
Implement controls from Annex A (which maps to ISO 27002)
Monitor, review, and improve the ISMS continually
Organizations that comply with ISO 27001 can achieve certification, demonstrating their commitment to managing information security risks effectively.
ISO 27006: Requirements for Certification Bodies
ISO 27006 sets the requirements for certification bodies that audit and certify organizations for ISO 27001 compliance. It ensures that auditors follow consistent and high-quality assessment methodologies. The key aspects of ISO 27006 include:
Accreditation requirements for certification bodies
Competency criteria for ISMS auditors
Audit process and procedures
Reporting and impartiality principles
By adhering to ISO 27006, certification bodies maintain credibility and ensure that ISO 27001 certifications are valid and trustworthy.
ISO 27009: Sector-Specific Adaptations of ISO 27001
ISO 27009 provides guidance on adapting ISO 27001 for specific industries or sectors. It allows the development of sector-specific information security standards while maintaining alignment with the ISO 27001 framework.
This standard is particularly useful for industries with unique regulatory and operational security requirements, such as healthcare, finance, and telecommunications. It ensures that sector-specific standards remain compatible with ISO 27001 while addressing industry-specific risks.
Informative ISO Standards in the 27000 Series
Unlike the normative standards, the following standards provide guidance rather than mandatory requirements:
ISO 27000: Overview and Vocabulary
ISO 27000 defines key terms and concepts used across the ISO 27000 series. It serves as a reference point for understanding information security principles and the structure of ISMS standards.
ISO 27002: Information Security Controls
ISO 27002 provides detailed guidance on implementing the security controls outlined in Annex A of ISO 27001. It covers best practices for:
Access control
Cryptography
Physical security
Incident management
Although not a certification standard, ISO 27002 helps organizations strengthen their ISMS controls.
ISO 27003: ISMS Implementation Guidance
ISO 27003 offers guidance on implementing an ISMS based on ISO 27001. It covers:
Project planning
Risk assessment methodologies
ISMS documentation requirements
Stakeholder engagement
ISO 27004: ISMS Monitoring and Measurement
ISO 27004 provides guidelines on how to measure and evaluate the effectiveness of an ISMS. It includes:
Metrics for assessing security performance
Continuous improvement techniques
Compliance monitoring strategies
ISO 27005: Risk Management for Information Security
ISO 27005 offers a structured approach to risk management in ISMS, aligning with ISO 27001’s risk-based approach. It guides organizations in:
Identifying and assessing security risks
Selecting appropriate mitigation strategies
Implementing a continuous risk management process
ISO 27007: Guidelines for ISMS Audits
ISO 27007 complements ISO 27006 by providing best practices for conducting ISMS audits. It helps organizations prepare for ISO 27001 certification audits and maintain compliance.
ISO 27008: Security Controls Assessment
ISO 27008 offers guidance on assessing the effectiveness of information security controls. It helps organizations verify whether implemented controls meet their security objectives.
ISO 27010 to ISO 27099: Industry-Specific and Emerging Standards
The ISO 27000 series continues to evolve with additional standards covering:
Information security in inter-organizational communication (ISO 27010)
Cloud security (ISO 27017, ISO 27018)
Privacy management (ISO 27701)
Cybersecurity frameworks (ISO 27032)
Conclusion
ISO 27001, ISO 27006, and ISO 27009 are the key normative standards that define requirements for ISMS implementation, certification, and sector-specific adaptations. The rest of the ISO 27000 series provides informative guidance, helping organizations understand, implement, and improve their ISMS. Understanding these distinctions ensures organizations can effectively navigate compliance, certification, and best practices for information security management.
By following these standards, businesses can strengthen their cybersecurity posture, protect sensitive data, and demonstrate their commitment to information security best practices.
In today’s cybersecurity landscape, having a robust and flexible security information and event management (SIEM) system is crucial. Wazuh, an open-source security platform, offers comprehensive solutions for threat detection, integrity monitoring, incident response, and compliance.
Wazuh has an interesting history. In 2015, the Wazuh team decided to fork OSSEC, an open-source host-based Intrusion Detection System (IDS), to expand its core functionalities with additional features, enhancements, and a user-friendly interface. Wazuh has grown significantly since its inception. It is now a comprehensive, open-source security platform that provides unified XDR (Extended Detection and Response) and SIEM (Security Information and Event Management) capabilities. The platform is designed to monitor infrastructures, detect threats, respond to incidents, and ensure regulatory compliance.
This blog will guide you through setting up Wazuh in a lab environment, focusing on its basic capabilities in Extended Detection and Response (XDR) and SIEM. Whether you’re a cybersecurity professional or an enthusiast, this step-by-step guide will help to get started with Wazuh to secure your systems effectively. We start with the defaults to make the lab-setup not more complex as necessary.
My Lab-env is as follows:
Host
IP
OS
Wazuh-Server
10.50.100.76
Ubuntu 24 LTS
Wazuh-Agent
10.50.100.110
RHEL 9
Wazuh-Agent
10.50.100.111
RHEL 9
Wazuh-Agent
10.50.100.201
Windows
Basic setup of Wazuh-Server
with root rights execute curl -sO https://packages.wazuh.com/4.10/wazuh-install.sh && sudo bash ./wazuh-install.sh -a
Example output:
30/01/2025 08:07:17 INFO: Starting Wazuh installation assistant. Wazuh version: 4.10.1
30/01/2025 08:07:17 INFO: Verbose logging redirected to /var/log/wazuh-install.log
30/01/2025 08:07:22 INFO: Verifying that your system meets the recommended minimum hardware requirements.
30/01/2025 08:07:22 INFO: Wazuh web interface port will be 443.
30/01/2025 08:07:27 INFO: --- Dependencies ----
30/01/2025 08:07:27 INFO: Installing apt-transport-https.
30/01/2025 08:07:30 INFO: Installing debhelper.
30/01/2025 08:07:43 INFO: Wazuh repository added.
30/01/2025 08:07:43 INFO: --- Configuration files ---
30/01/2025 08:07:43 INFO: Generating configuration files.
30/01/2025 08:07:44 INFO: Generating the root certificate.
30/01/2025 08:07:44 INFO: Generating Admin certificates.
30/01/2025 08:07:44 INFO: Generating Wazuh indexer certificates.
30/01/2025 08:07:44 INFO: Generating Filebeat certificates.
30/01/2025 08:07:44 INFO: Generating Wazuh dashboard certificates.
30/01/2025 08:07:45 INFO: Created wazuh-install-files.tar. It contains the Wazuh cluster key, certificates, and passwords necessary for installation.
30/01/2025 08:07:45 INFO: --- Wazuh indexer ---
30/01/2025 08:07:45 INFO: Starting Wazuh indexer installation.
30/01/2025 08:08:23 INFO: Wazuh indexer installation finished.
30/01/2025 08:08:23 INFO: Wazuh indexer post-install configuration finished.
30/01/2025 08:08:23 INFO: Starting service wazuh-indexer.
30/01/2025 08:08:35 INFO: wazuh-indexer service started.
30/01/2025 08:08:35 INFO: Initializing Wazuh indexer cluster security settings.
30/01/2025 08:08:38 INFO: Wazuh indexer cluster security configuration initialized.
30/01/2025 08:08:38 INFO: Wazuh indexer cluster initialized.
30/01/2025 08:08:38 INFO: --- Wazuh server ---
30/01/2025 08:08:38 INFO: Starting the Wazuh manager installation.
30/01/2025 08:10:10 INFO: Wazuh manager installation finished.
30/01/2025 08:10:10 INFO: Wazuh manager vulnerability detection configuration finished.
30/01/2025 08:10:10 INFO: Starting service wazuh-manager.
30/01/2025 08:10:22 INFO: wazuh-manager service started.
30/01/2025 08:10:22 INFO: Starting Filebeat installation.
30/01/2025 08:10:28 INFO: Filebeat installation finished.
30/01/2025 08:10:28 INFO: Filebeat post-install configuration finished.
30/01/2025 08:10:28 INFO: Starting service filebeat.
30/01/2025 08:10:30 INFO: filebeat service started.
30/01/2025 08:10:30 INFO: --- Wazuh dashboard ---
30/01/2025 08:10:30 INFO: Starting Wazuh dashboard installation.
30/01/2025 08:11:22 INFO: Wazuh dashboard installation finished.
30/01/2025 08:11:22 INFO: Wazuh dashboard post-install configuration finished.
30/01/2025 08:11:22 INFO: Starting service wazuh-dashboard.
30/01/2025 08:11:23 INFO: wazuh-dashboard service started.
30/01/2025 08:11:24 INFO: Updating the internal users.
30/01/2025 08:11:27 INFO: A backup of the internal users has been saved in the /etc/wazuh-indexer/internalusers-backup folder.
30/01/2025 08:11:35 INFO: The filebeat.yml file has been updated to use the Filebeat Keystore username and password.
30/01/2025 08:12:00 INFO: Initializing Wazuh dashboard web application.
30/01/2025 08:12:01 INFO: Wazuh dashboard web application initialized.
30/01/2025 08:12:01 INFO: --- Summary ---
30/01/2025 08:12:01 INFO: You can access the web interface https://<wazuh-dashboard-ip>:443
User: admin
Password: PblablablablaB7n3vfwq
30/01/2025 08:12:01 INFO: Installation finished.
Please note the autogenerated User/Password to get later access to the Dashboard.
open a Browser and access: https://10.50.100.76 Don’t be surprised that the connection is interested, we use the default certs.
We see the default Dashboard:
Wazuh is shipped with default rules. In a productive environment the real work would start now: Create/adapt rules that are suitable for the required purposes and environment. We will start with fixing the first (easy) vulnerability finding.
Fix a chrony-finding/vulnerability
Lets pick an RHEL-Agent and check the details of the chrony-finding:
Navigate to Configuration Assesment
Select an Agent
Agent ID 02 looks as a good candidate
filter the findings for chrony
click on the failed check
read carefully the finding and check the settings on the Agent to get it fixed
get the chrony finding fixed
The crony process is not executed by user chrony, let’s get it fixed:
ssh-audit is a powerful tool designed to help you assess the security of your SSH servers (and clients!). It provides detailed information about the server’s configuration, supported algorithms, and potential vulnerabilities. In this guide, I’ll walk you through the steps to install ssh-audit and run your first security tests. Secure SSH configuration made easy.
Installation on Linux
Clone the Repository: Open your terminal and clone the ssh-audit repository from GitHub: git clone https://github.com/jtesta/ssh-audit.git
Navigate to the Directory: Change to the ssh-audit directory: cd ssh-audit
Install Dependencies: Ensure you have Python installed on your system. If not, install it using your package manager. For example, on Ubuntu: sudo apt-get install python3
Installation on macOS
To install ssh-audit , run: brew install ssh-audit (You have already Brew installed, right ?)
Please check the ssh-audit url for many other setup options (Docker,Windows,etc.)
Test the SSH-Server against vulnerabilities
execute ssh-audit <hostname> Replace <hostname> with the IP address or domain name of the SSH server you want to audit.
Example of Ubuntu’s 24.04 LTS default SSHD setup:
(if you add the -l warn switch you just get the vulnerabilities presented)
Interpreting the Results:ssh-audit will provide a detailed report of the server’s configuration, including supported key exchange algorithms, encryption ciphers, and MAC algorithms. Look for any warnings or recommendations to improve your server’s security.
Remediation
After running ssh-audit and identifying potential vulnerabilities or weak configurations in your SSH server, it’s important to take steps to remediate these issues. Below are examples of how to apply them:
Example for Ubuntu 24.04.1 LTS:
(Note: This is just an example. The example eliminates vulnerabilities for the SSH-daemon, but it can well be that this snippet does not fit for your setup. Handle with care)
This snippet creates a configuration file (51-ssh-harden_202412.conf) in directory /etc/ssh/sshd_config.d/ with the specified settings to enhance the security of your SSH server.
(Note: This is just an example. This example eliminates vulnerabilities for the SSH-daemon, but it can well be that this snippet does not fit for your setup. Handle with care)
# Backup the original OpenSSH server configuration file
cp /etc/crypto-policies/back-ends/opensshserver.config /etc/crypto-policies/back-ends/opensshserver.config.orig
# Update the OpenSSH server configuration with specific cryptographic policies
echo -e "
# Ciphers: Specifies the encryption algorithms used to secure the SSH session
Ciphers=aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr
# Message Authentication Codes (MACs): Defines the algorithms used to ensure data integrity and authenticity
MACs=hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,umac-128-etm@openssh.com
# GSSAPI Key Exchange Algorithms: Specifies the algorithms used for GSSAPI key exchange
GSSAPIKexAlgorithms=gss-curve25519-sha256-
# Key Exchange Algorithms (KexAlgorithms): Lists the algorithms used for key exchange during the SSH handshake
KexAlgorithms=curve25519-sha256,curve25519-sha256@libssh.org,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group-exchange-sha256
# Host Key Algorithms: Lists the algorithms used for verifying the server's host key
HostKeyAlgorithms=ssh-ed25519,ssh-ed25519-cert-v01@openssh.com,rsa-sha2-256,rsa-sha2-512
# Public Key Accepted Key Types: Specifies the types of public keys accepted for authentication
PubkeyAcceptedKeyTypes=ssh-ed25519,ssh-ed25519-cert-v01@openssh.com,rsa-sha2-256,rsa-sha2-512
" > /etc/crypto-policies/back-ends/opensshserver.config
(SSHD restart required)
Proof the remediation
run ssh-audit again!
Example-output after remediation:
How can I test if my SSH-Client is not vulnerable ?
If you run ssh-audit with the switch -c it creates an ssh-service on port 2222 and audits every connection attempt:
output after the login-attempt (ssh 127.0.0.1 -p 2222)
➜ ~ ssh-audit -c
# general
(gen) client IP: 127.0.0.1
(gen) banner: SSH-2.0-OpenSSH_9.8
(gen) software: OpenSSH 9.8
(gen) compression: enabled (zlib@openssh.com, zlib)
# key exchange algorithms
(kex) sntrup761x25519-sha512@openssh.com -- [info] available since OpenSSH 8.5
`- [info] default key exchange from OpenSSH 9.0 to 9.8
`- [info] hybrid key exchange based on post-quantum resistant algorithm and proven conventional X25519 algorithm
(kex) curve25519-sha256 -- [info] available since OpenSSH 7.4, Dropbear SSH 2018.76
`- [info] default key exchange from OpenSSH 7.4 to 8.9
(kex) curve25519-sha256@libssh.org -- [info] available since OpenSSH 6.4, Dropbear SSH 2013.62
(kex) diffie-hellman-group-exchange-sha256 -- [info] available since OpenSSH 4.4
(kex) diffie-hellman-group16-sha512 -- [info] available since OpenSSH 7.3, Dropbear SSH 2016.73
(kex) diffie-hellman-group18-sha512 -- [info] available since OpenSSH 7.3
(kex) ext-info-c -- [info] available since OpenSSH 7.2
`- [info] pseudo-algorithm that denotes the peer supports RFC8308 extensions
(kex) kex-strict-c-v00@openssh.com -- [info] pseudo-algorithm that denotes the peer supports a stricter key exchange method as a counter-measure to the Terrapin attack (CVE-2023-48795)
# host-key algorithms
(key) ssh-ed25519-cert-v01@openssh.com -- [info] available since OpenSSH 6.5
(key) sk-ssh-ed25519-cert-v01@openssh.com -- [info] available since OpenSSH 8.2
(key) rsa-sha2-512-cert-v01@openssh.com -- [info] available since OpenSSH 7.8
(key) rsa-sha2-256-cert-v01@openssh.com -- [info] available since OpenSSH 7.8
(key) ssh-ed25519 -- [info] available since OpenSSH 6.5, Dropbear SSH 2020.79
(key) sk-ssh-ed25519@openssh.com -- [info] available since OpenSSH 8.2
(key) rsa-sha2-512 -- [info] available since OpenSSH 7.2
(key) rsa-sha2-256 -- [info] available since OpenSSH 7.2, Dropbear SSH 2020.79
# encryption algorithms (ciphers)
(enc) chacha20-poly1305@openssh.com -- [info] available since OpenSSH 6.5, Dropbear SSH 2020.79
`- [info] default cipher since OpenSSH 6.9
(enc) aes128-ctr -- [info] available since OpenSSH 3.7, Dropbear SSH 0.52
(enc) aes192-ctr -- [info] available since OpenSSH 3.7
(enc) aes256-ctr -- [info] available since OpenSSH 3.7, Dropbear SSH 0.52
(enc) aes128-gcm@openssh.com -- [info] available since OpenSSH 6.2
(enc) aes256-gcm@openssh.com -- [info] available since OpenSSH 6.2
# message authentication code algorithms
(mac) umac-128-etm@openssh.com -- [info] available since OpenSSH 6.2
(mac) hmac-sha2-256-etm@openssh.com -- [info] available since OpenSSH 6.2
(mac) hmac-sha2-512-etm@openssh.com -- [info] available since OpenSSH 6.2
# algorithm recommendations (for OpenSSH 9.8)
(rec) -ecdh-sha2-nistp256 -- kex algorithm to remove
(rec) -ecdh-sha2-nistp384 -- kex algorithm to remove
(rec) -ecdh-sha2-nistp521 -- kex algorithm to remove
(rec) -ecdsa-sha2-nistp256 -- key algorithm to remove
(rec) -ecdsa-sha2-nistp256-cert-v01@openssh.com -- key algorithm to remove
(rec) -ecdsa-sha2-nistp384 -- key algorithm to remove
(rec) -ecdsa-sha2-nistp384-cert-v01@openssh.com -- key algorithm to remove
(rec) -ecdsa-sha2-nistp521 -- key algorithm to remove
(rec) -ecdsa-sha2-nistp521-cert-v01@openssh.com -- key algorithm to remove
(rec) -hmac-sha1 -- mac algorithm to remove
(rec) -hmac-sha1-etm@openssh.com -- mac algorithm to remove
(rec) -sk-ecdsa-sha2-nistp256-cert-v01@openssh.com -- key algorithm to remove
(rec) -sk-ecdsa-sha2-nistp256@openssh.com -- key algorithm to remove
(rec) -diffie-hellman-group14-sha256 -- kex algorithm to remove
(rec) -hmac-sha2-256 -- mac algorithm to remove
(rec) -hmac-sha2-512 -- mac algorithm to remove
(rec) -umac-128@openssh.com -- mac algorithm to remove
(rec) -umac-64-etm@openssh.com -- mac algorithm to remove
(rec) -umac-64@openssh.com -- mac algorithm to remove
Make your SSH-communication more secure, if not the SSH-Service opens an attack surface for uninvited visitors. Secure SSH configuration is Key!
When you Ssh the first time to a host the screen shows something like:
ssh test@10.50.100.110
The authenticity of host '10.50.100.110 (10.50.100.110)' can't be established.
ED25519 key fingerprint is SHA256:jCJ0TIJkKnjgu3RTv5eGER7p4IN5Tb/JpTEVJNMfpMs.
This key is not known by any other names
Are you sure you want to continue connecting (yes/no/[fingerprint])?
Be honest: Do you just accept the shown Fingerprint of the remote host or do you really doublecheck the presented fingerprint before you accept ?
My guess: Most of the time the presented fingerprint gets accepted without any additional check.
This procedure is called TOFU (Trust On First Use). TOFU assumes that the first time you connect to a server, the server’s key is trustworthy. However, this can leave you vulnerable to man-in-the-middle attacks if an attacker intercepts the initial connection. The attacker grabs your user/password credentials and can get access.
Here are some implementations who are using TOFU:
Android Enterprise Networks: Android supports TOFU for enterprise networks by allowing devices to trust an enterprise network by installing the root CA used by the server and setting its domain name in a saved network.
Signal: In Signal, endpoints initially trust the identifier blindly and display non-blocking warnings when it changes. Users can verify the identifier by scanning a QR code or exchanging a Safety Number, which then changes the nature of identifier change warnings from non-blocking to blocking.
WhatsApp: WhatsApp clients initially trust the identifier blindly and, by default, do not display warnings when the identifier changes. Users can enable non-blocking warnings by accessing the key fingerprint (called Security Code) and verifying it.
XMPP Client Conversations: This client uses Blind Trust Before Verification, where all identifiers are blindly trusted until the user authenticates endpoints by scanning a QR code. Once verified, the client displays a shield symbol for authenticated messages.
By using certificates for SSH authentication, you can eliminate the risks associated withTOFU. Key approval (and distribution) is no more necessary with certificate-based Ssh.
Certificates provide a more robust and secure method of verifying identities, ensuring that both the client and server can trust each other without relying on the initial Ssh-connection’s integrity.
Before we dive into the lab, let’s first take a look at some key pros and cons related to this topic.
Advantages when using certificate-based ssh:
Enhanced Security: Certificates provide a higher level of security compared to traditional SSH keys. They are issued by a trusted Certificate Authority (CA), which ensures that both the client and server are who they claim to be.
Elimination of TOFU Risks: By using certificates, you eliminate the Trust On First Use (TOFU) risks associated with traditional SSH key exchanges. This reduces the chances of man-in-the-middle attacks during the initial connection.
Simplified Key Management: Certificates simplify the management of SSH keys. They can be easily issued, renewed, and revoked by the CA, making it easier to manage credentials in large environments.
Scalability: Certificate-based authentication scales well in large environments. Automated tools can be used to handle the issuance, renewal, and revocation of certificates, making it easier to manage a large number of users and systems.
Improved Compliance: Using certificates can help meet regulatory and compliance requirements for secure communications. This provides an added layer of assurance for your organization.
Revocation Capability: If a certificate is compromised, it can be revoked by the CA, rendering it invalid. This provides a way to quickly respond to security incidents and prevent unauthorized access.
Expiration and Renewal: Certificates have a defined validity period, which means they need to be renewed periodically. This ensures that outdated or potentially compromised credentials are regularly updated.
Disadvantages when using certificate-based ssh:
Initial Setup Time: The initial setup of a certificate authority (CA) and the issuance of certificates can be time-consuming. This includes configuring the CA, generating certificates, and distributing them to clients and servers.
Complexity: Setting up and managing a certificate-based SSH infrastructure can be more complex compared to traditional key-based authentication. It requires a good understanding of Public Key Infrastructure (PKI) and certificate management.
Compatibility: Not all systems and applications may support certificate-based SSH authentication out of the box. Additional configuration or software may be required to enable this feature.
Maintenance: Regular maintenance is required to keep the certificate infrastructure secure. This includes renewing certificates before they expire, revoking compromised certificates, and ensuring the CA remains secure.
Dependency on CA: The security of the entire system relies on the integrity and security of the CA. If the CA is compromised, the entire certificate-based authentication system can be at risk.
# install needed packages
wget https://dl.smallstep.com/cli/docs-cli-install/latest/step-cli_amd64.rpm
rpm -i step-cli_amd64.rpm
wget https://dl.smallstep.com/certificates/docs-ca-install/latest/step-ca_amd64.rpm
sudo rpm -i step-ca_amd64.rpm
#check version(s)
[root@step step]# step version
Smallstep CLI/0.27.2 (linux/amd64)
Release Date: 2024-07-18T18:15:09Z
[root@step step]# step-ca version
Smallstep CA/0.27.2 (linux/amd64)
Release Date: 2024-07-18T21:29:11Z
[root@step step]#
#setup step ca
[root@step step]# step ca init -ssh
Use the arrow keys to navigate: ↓ ↑ → ←
? What deployment type would you like to configure?:
▸ Standalone - step-ca instance you run yourself
Linked - standalone, plus cloud configuration, reporting & alerting
Hosted - fully-managed step-ca cloud instance run for you by smallstep
✔ Deployment Type: Standalone
What would you like to name your new PKI?
✔ (e.g. Smallstep): step
What DNS names or IP addresses will clients use to reach your CA?
✔ (e.g. ca.example.com[,10.1.2.3,etc.]): step,10.50.100.110
What IP and port will your new CA bind to? (:443 will bind to 0.0.0.0:443)
✔ (e.g. :443 or 127.0.0.1:443): :443█
What would you like to name the CA's first provisioner?
✔ (e.g. you@smallstep.com): ugu5ma@step
Choose a password for your CA keys and first provisioner.
✔ [leave empty and we'll generate one]:
Generating root certificate... done!
Generating intermediate certificate... done!
Generating user and host SSH certificate signing keys... done!
✔ Root certificate: /root/.step/certs/root_ca.crt
✔ Root private key: /root/.step/secrets/root_ca_key
✔ Root fingerprint: fb31925c37a688d0821420eb25e5f1e6c03ca0c7d51e48516b14bdc13ff5ccdd
✔ Intermediate certificate: /root/.step/certs/intermediate_ca.crt
✔ Intermediate private key: /root/.step/secrets/intermediate_ca_key
✔ SSH user public key: /root/.step/certs/ssh_user_ca_key.pub
✔ SSH user private key: /root/.step/secrets/ssh_user_ca_key
✔ SSH host public key: /root/.step/certs/ssh_host_ca_key.pub
✔ SSH host private key: /root/.step/secrets/ssh_host_ca_key
✔ Database folder: /root/.step/db
✔ Templates folder: /root/.step/templates
✔ Default configuration: /root/.step/config/defaults.json
✔ Certificate Authority configuration: /root/.step/config/ca.json
Your PKI is ready to go. To generate certificates for individual services see 'step help ca'.
FEEDBACK 😍 🍻
The step utility is not instrumented for usage statistics. It does not phone
home. But your feedback is extremely valuable. Any information you can provide
regarding how you’re using `step` helps. Please send us a sentence or two,
good or bad at feedback@smallstep.com or join GitHub Discussions
https://github.com/smallstep/certificates/discussions and our Discord
https://u.step.sm/discord.
[root@step step]#
#run your ssh-ca
[root@step step]# step-ca $(step path)/config/ca.json
badger 2024/09/06 10:50:53 INFO: All 1 tables opened in 1ms
badger 2024/09/06 10:50:53 INFO: Replaying file id: 0 at offset: 7306
badger 2024/09/06 10:50:53 INFO: Replay took: 9.758µs
Please enter the password to decrypt /root/.step/secrets/intermediate_ca_key:
Please enter the password to decrypt /root/.step/secrets/ssh_host_ca_key:
Please enter the password to decrypt /root/.step/secrets/ssh_user_ca_key:
2024/09/06 10:51:00 Building new tls configuration using step-ca x509 Signer Interface
2024/09/06 10:51:00 Starting Smallstep CA/0.27.2 (linux/amd64)
2024/09/06 10:51:00 Documentation: https://u.step.sm/docs/ca
2024/09/06 10:51:00 Community Discord: https://u.step.sm/discord
2024/09/06 10:51:00 Config file: /root/.step/config/ca.json
2024/09/06 10:51:00 The primary server URL is https://step:443
2024/09/06 10:51:00 Root certificates are available at https://step:443/roots.pem
2024/09/06 10:51:00 Additional configured hostnames: 10.50.100.110
2024/09/06 10:51:00 X.509 Root Fingerprint: fb31925c37a688d0821420eb25e5f1e6c03ca0c7d51e48516b14bdc13ff5ccdd
2024/09/06 10:51:00 SSH Host CA Key: ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBKliAvQoL0eRNGMXMUFSSOBzo8fjzsnb1ztakctwFJUnsgzSCCWhXDky5B59CQcw/m8fb/0DDWv0Vyw7YYRkLJM=
2024/09/06 10:51:00 SSH User CA Key: ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBAWRNNWJj9uhoM5PZ4rkQP0yzeW9F2+73UqCmQSAdDcukUzHmMlVet5yDpbOqfkjAVwokW68cS9OfzEXetd41y0=
2024/09/06 10:51:00 Serving HTTPS on 10.50.100.110:443 ...
we need later the shown fingerprint, this is a good time to copy the string (fb319….cdd).
Setup clientstep1 as ssh-daemon who only accept ssh-certificates of our new ssh ca:
wget https://dl.smallstep.com/cli/docs-cli-install/latest/step-cli_amd64.rpm
rpm -i step-cli_amd64.rpm
[root@clientstep1 ugu5ma]# step version
Smallstep CLI/0.27.2 (linux/amd64)
Release Date: 2024-07-18T18:15:09Z
[root@clientstep1 ugu5ma]#
*** To configure step to access your CA from a new host, run step ca bootstrap --ca-url [CA URL] --fingerprint [CA fingerprint] :
[root@clientstep1 ugu5ma]# step ca bootstrap --ca-url https://10.50.100.110:443 --fingerprint fb31925c37a688d0821420eb25e5f1e6c03ca0c7d51e48516b14bdc13ff5ccdd
The root certificate has been saved in /root/.step/certs/root_ca.crt.
The authority configuration has been saved in /root/.step/config/defaults.json.
#### trust your SSH user CA
[root@clientstep1 ugu5ma]# step ssh config --roots > /path/to/ssh_user_key.pub
bash: /path/to/ssh_user_key.pub: No such file or directory
[root@clientstep1 ugu5ma]# step certificate install $(step path)/certs/root_ca.crt
Certificate /root/.step/certs/root_ca.crt has been installed.
X.509v3 Root CA Certificate (ECDSA P-256) [Serial: 1777...5197]
Subject: step Root CA
Issuer: step Root CA
Valid from: 2024-09-06T08:40:14Z
to: 2034-09-04T08:40:14Z
#### let's sign a host-certificate for:
##### principal1 = clientstep1
##### principal2 = clientstep1.fritz.box
##### certificate-id = ubuarmlts
[root@clientstep1 ugu5ma]# sudo -E step ssh certificate ubuarmlts /etc/ssh/ssh_host_ecdsa_key.pub --host --sign --principal clientstep1 --principal clientstep1.fritz.box
Use the arrow keys to navigate: ↓ ↑ → ←
What provisioner key do you want to use?
▸ ugu5ma@step (JWK) [kid: DFYsQuqHCCpjx2uXeDYiZEI0V8aH2tAcK54qGPyHbzA]
sshpop (SSHPOP)
Please enter the password to decrypt the provisioner key:
✔ CA: https://10.50.100.110:443
✔ Certificate: /etc/ssh/ssh_host_ecdsa_key-cert.pub
####
#### run the following command and add the following to your SSHD configuration (vi /etc/ssh/sshd_config)
####
[root@clientstep1 ssh]# step ssh config --roots > /etc/ssh/ssh_user_key.pub
#### add the following to SSHD config(vi /etc/ssh/sshd_config)
# This is our host private key and certificate:
HostKey /etc/ssh/ssh_host_ecdsa_key
HostCertificate /etc/ssh/ssh_host_ecdsa_key-cert.pub
*** Configure SSH clients to trust your host CA
** To view the host key, run: step ssh config --host --roots
Setup clientstep2 as cert-based ssh-client
#
#>>>bootstrap the host as shown on stepclient1<<<
#
#Let's create an SSH user certificate for user ugu5ma
[ugu5ma@clientstep2 ~]$ cd /home/ugu5ma/.ssh
[ugu5ma@clientstep2 ~]$ step ssh certificate ugu5ma@step id_ecdsa
Use the arrow keys to navigate: ↓ ↑ → ←
What provisioner key do you want to use?
▸ ugu5ma@step (JWK) [kid: DFYsQuqHCCpjx2uXeDYiZEI0V8aH2tAcK54qGPyHbzA]
sshpop (SSHPOP)
✔ Provisioner: ugu5ma@step (JWK) [kid: DFYsQuqHCCpjx2uXeDYiZEI0V8aH2tAcK54qGPyHbzA]
Please enter the password to decrypt the provisioner key:
✔ CA: https://10.50.100.110:443
Please enter the password to encrypt the private key: █
✔ Private Key: id_ecdsa
✔ Public Key: id_ecdsa.pub
✔ Certificate: id_ecdsa-cert.pub
### Trust your ssh-CA, run command:
[ugu5ma@clientstep2 .ssh]$ step ssh config --host --roots
ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBKliAvQoL0eRNGMXMUFSSOBzo8fjzsnb1ztakctwFJUnsgzSCCWhXDky5B59CQcw/m8fb/0DDWv0Vyw7YYRkLJM=
### add the output to .ssh/known_hosts (vi /home/ugu5ma/.ssh/known_hosts)
@cert-authority * ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBKliAvQoL0eRNGMXMUFSSOBzo8fjzsnb1ztakctwFJUnsgzSCCWhXDky5B59CQcw/m8fb/0DDWv0Vyw7YYRkLJM=
### verify
[ugu5ma@clientstep2 .ssh]$ cat /home/ugu5ma/.ssh/known_hosts
@cert-authority * ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBKliAvQoL0eRNGMXMUFSSOBzo8fjzsnb1ztakctwFJUnsgzSCCWhXDky5B59CQcw/m8fb/0DDWv0Vyw7YYRkLJM=
next we try to connect from clientstep2 to clientstep1:
### let's ssh to clientstep1 and verify the communication:
[ugu5ma@clientstep2 .ssh]$ ssh ugu5ma@clientstep1 -vv
OpenSSH_8.7p1, OpenSSL 3.0.7 1 Nov 2022
#
# uninteresting output deleted...
#
debug2: resolving "clientstep1.fritz.box" port 22
debug1: Connecting to clientstep1.fritz.box [10.50.100.111] port 22.
debug1: Connection established.
debug1: Local version string SSH-2.0-OpenSSH_8.7
debug1: Remote protocol version 2.0, remote software version OpenSSH_8.7
debug1: compat_banner: match: OpenSSH_8.7 pat OpenSSH* compat 0x04000000
debug2: fd 3 setting O_NONBLOCK
debug1: Authenticating to clientstep1.fritz.box:22 as 'ugu5ma'
debug1: Server host certificate: ecdsa-sha2-nistp256-cert-v01@openssh.com SHA256:5OW2e/VviIjRptZ9L5exCm6xW3jwUI2BEM9Zx8MAb0A, serial 5287235044766806569 ID "ubuarmlts" CA ecdsa-sha2-nistp256 SHA256:jC3GukYmJNtdbqDF0J17DiFU98TW2/TlFNyQ2XG58PE valid from 2024-09-06T11:11:00 to 2024-10-06T11:12:00
debug2: Server host certificate hostname: clientstep1
debug2: Server host certificate hostname: clientstep1.fritz.box
debug1: Host 'clientstep1.fritz.box' is known and matches the ECDSA-CERT host certificate.
debug1: Found CA key in /home/ugu5ma/.ssh/known_hosts:1
debug1: Will attempt key: /home/ugu5ma/.ssh/id_ecdsa ECDSA-CERT SHA256:wBhbhAOlVpUXCKsuuAvN8+LV6ZLZuMpsv7GPySw3874 agent
debug2: pubkey_prepare: done
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Server accepts key: /home/ugu5ma/.ssh/id_ecdsa ECDSA-CERT SHA256:wBhbhAOlVpUXCKsuuAvN8+LV6ZLZuMpsv7GPySw3874 agent
debug2: sign_and_send_pubkey: using private key "/home/ugu5ma/.ssh/id_ecdsa" from agent for certificate
Authenticated to clientstep1 ([10.50.100.111]:22) using "publickey".
[ugu5ma@clientstep1 ~]$
Looks good! No TOFU as well 🙂
Lets try as next an ssh attempt from rogueclient without certificates:
ugu5ma@rogueclient:ssh ugu5ma@10.50.100.111 -vv
debug1: SSH2_MSG_KEX_ECDH_REPLY received
debug1: Server host certificate: ecdsa-sha2-nistp256-cert-v01@openssh.com SHA256:5OW2e/VviIjRptZ9L5exCm6xW3jwUI2BEM9Zx8MAb0A, serial 5287235044766806569 ID "ubuarmlts" CA ecdsa-sha2-nistp256 SHA256:jC3GukYmJNtdbqDF0J17DiFU98TW2/TlFNyQ2XG58PE valid from 2024-09-06T11:11:00 to 2024-10-06T11:12:00
debug2: Server host certificate hostname: clientstep1
debug2: Server host certificate hostname: clientstep1.fritz.box
debug1: Next authentication method: publickey
debug1: Trying private key: /home/ugu5ma/.ssh/id_rsa
debug1: Trying private key: /home/ugu5ma/.ssh/id_ecdsa
debug1: Trying private key: /home/ugu5ma/.ssh/id_ecdsa_sk
debug1: Trying private key: /home/ugu5ma/.ssh/id_ed25519
debug1: Trying private key: /home/ugu5ma/.ssh/id_ed25519_sk
debug1: Trying private key: /home/ugu5ma/.ssh/id_xmss
debug1: Trying private key: /home/ugu5ma/.ssh/id_dsa
debug2: we did not send a packet, disable method
debug1: No more authentication methods to try.
ugu5ma@10.50.100.111: Permission denied (publickey).
any ssh-attempt from rogueclient is denied because the client is not equipped with a valid ssh-certificate (best practice setting of “PasswordAuthentication no” and “PubkeyAuthentication yes“in sshd_config on clientstep1 must be enabled to avoid circumventing the security framework. ).
Is the shown setup suitable for productive use ? NO! Smallstep has a nice overview what topics needs to be considered before going live.
This page is just for setting up a small dev-lab to get handy with ssh-certificates. As always, take backups and redundant console-access before changing anything 🙂
You see the lifetime of the user-certificate ? It is valid for 16 hours. You can tweak the cert-lifetime during the creation with the parameter not-before and not-after, example:
# This certificate will be valid starting 10 minutes from now, until 10 days from now:
[ugu5ma@clientstep2 .ssh]$ step ssh certificate ugu5ma@step id_ecdsa --not-before=10m --not-after=240h
###check
[ugu5ma@clientstep2 .ssh]$ cat /home/ugu5ma/.ssh/id_ecdsa-cert.pub | step ssh inspect
-:
Type: ecdsa-sha2-nistp256-cert-v01@openssh.com user certificate
Public key: ECDSA-CERT SHA256:GOvbmiBstPbiiov0kNF4fApyjeSUhdnvm2xS5QolBFg
Signing CA: ECDSA SHA256:H+rgQ6gIM10MCNti1+tJs7H3nUCzrPQ3P5nCH2BqTJ8 (using ecdsa-sha2-nistp256)
Key ID: "ugu5ma@step"
Serial: 1320427072549296678
Valid: from 2024-09-06T14:20:58 to 2024-09-16T14:10:58
Principals:
ugu5ma
ugu5ma@step
Critical Options: (none)
The maxUserSSHCertDuration is per default set to 24hours. If you want to extent the User-cert lifetime you have to adjust this parameter (vi $(step path)/config/ca.json)
You must be logged in to post a comment.