{"id":4562,"date":"2026-09-18T21:02:43","date_gmt":"2026-09-18T15:32:43","guid":{"rendered":"https:\/\/cpanelfree.com\/blog\/hardening-openssh-98-with-fido2-webauthn-keys-and-short-lived-certificates\/"},"modified":"2026-09-18T21:02:43","modified_gmt":"2026-09-18T15:32:43","slug":"hardening-openssh-98-with-fido2-webauthn-keys-and-short-lived-certificates","status":"publish","type":"post","link":"https:\/\/cpanelfree.com\/blog\/hardening-openssh-98-with-fido2-webauthn-keys-and-short-lived-certificates\/","title":{"rendered":"Hardening OpenSSH 9.8 with FIDO2 WebAuthn Keys and Short-Lived Certificates"},"content":{"rendered":"

Securing administrative access across modern distributed cloud infrastructure has reached a critical turning point as conventional, long-lived SSH keypairs become prime targets for infostealers and lateral adversary movement. Relying on static public keys scattered across thousands of remote ~\/.ssh\/authorized_keys<\/code> files creates untracked access sprawl, renders immediate revocation operationally impossible, and exposes sensitive production nodes to workstation compromise. Modern bare-metal and cloud environments hosted on CpanelFree<\/a> demand an uncompromised zero-trust paradigm: pairing OpenSSH 9.8 hardware-bound FIDO2\/WebAuthn keys with an automated Certificate Authority (CA) delivering short-lived, cryptographically signed certificates.<\/p>\n

<\/p>\n

Understanding OpenSSH FIDO2 Hardware Security Keys and Ephemeral CA Infrastructure<\/h2>\n
\n Direct Architecture Answer:<\/strong> OpenSSH 9.8 hardening with FIDO2 WebAuthn and short-lived certificates couples physical hardware authenticators (sk-ssh-ed25519@openssh.com<\/code>) with a centralized SSH Certificate Authority. Private keys never leave the hardware token’s tamper-resistant secure enclave, while the CA issues cryptographically signed user certificates valid for mere hours. This eliminates static authorized keys, stops credential theft, and automates access revocation across your entire Linux fleet.\n<\/div>\n

For more than two decades, the standard pattern for Linux server administration was straightforward: developers generated an RSA or standard Ed25519 keypair on their local laptops, copied the public key to target servers via ssh-copy-id<\/code>, and left it there indefinitely. Over time, enterprise fleets accumulated thousands of orphaned public keys belonging to former employees, contractors, and forgotten deployment scripts. When a developer’s workstation is compromised by malware or memory-scraping infostealers, standard private keys stored in ~\/.ssh\/id_rsa<\/code> or loaded into standard ssh-agent sockets are instantly extracted and used to pivot across the enterprise perimeter.<\/p>\n

OpenSSH 9.8 fundamentally eliminates this threat vector by integrating native support for FIDO2 \/ U2F (Universal 2nd Factor) authenticators<\/strong> via the Client-to-Authenticator Protocol (CTAP2) and OpenSSH’s robust public key infrastructure (PKI) certificate framework. By moving from static file-based keys to hardware-anchored credentials verified by short-lived certificates, organizations achieve true hardware-backed identity verification with zero maintenance of distributed authorized key lists.<\/p>\n

Cryptographic Deep Dive: FIDO2 WebAuthn Keys (sk-ssh-ed25519)<\/h2>\n

Unlike standard SSH keys, where the private key consists of a byte array stored on the host’s filesystem, an OpenSSH FIDO2 key (sk-ssh-ed25519@openssh.com<\/code> or sk-ecdsa-sha2-nistp256@openssh.com<\/code>) leverages an external hardware security module\u2014such as a YubiKey, Nitrokey, or SoloKey. During key generation, the secure enclave on the physical token creates the elliptic curve keypair internally.<\/p>\n

What gets written to the client’s local drive (e.g., ~\/.ssh\/id_ed25519_sk<\/code>) is not a private key. Instead, it is an opaque Key Handle<\/strong> accompanied by a public key. The private key cannot be extracted, cloned, or dumped from RAM by root-level malware on the client machine. When an SSH authentication handshake occurs, the OpenSSH client communicates with the security key via libfido2<\/code>, sending the cryptographic server challenge to the hardware token. The token only signs the challenge after two criteria are satisfied:<\/p>\n

    \n
  • User Presence (UP):<\/strong> The token requires a physical capacitive touch or button press on the hardware authenticator, proving an active human is physically sitting at the terminal. Background processes and remote Trojan horse scripts cannot spoof this signal.<\/li>\n
  • User Verification (UV):<\/strong> The token enforces an on-chip alphanumeric PIN or biometric fingerprint check before unlocking the cryptographic enclave. Even if the physical USB key is stolen from an engineer’s bag, the attacker cannot sign SSH challenges without the biometric match or PIN.<\/li>\n<\/ul>\n
    \n Architecture Note:<\/strong> OpenSSH 9.8 supports both non-discoverable and discoverable credentials (resident keys). With resident keys (ssh-keygen -K<\/code>), the key handle and metadata are stored directly within the security token’s internal EEPROM. An engineer can plug their hardware key into any clean, authorized administrative bastion, run ssh-add -K<\/code>, and immediately authenticate without needing to transfer key files across machines.<\/div>\n

    Architectural Matrix: Static Keys vs. Standalone FIDO2 vs. Ephemeral CA Certificates<\/h2>\n

    To understand the operational and security trade-offs, review the comparative matrix below analyzing key management architectures across enterprise Linux infrastructures.<\/p>\n\n\n\n\n\n\n\n\n\n\n\n
    Security & Operational Dimension<\/th>\nLegacy Static SSH Keys<\/th>\nStandalone FIDO2 Hardware Keys<\/th>\nFIDO2 + Ephemeral OpenSSH CA (Production)<\/th>\n<\/tr>\n<\/thead>\n
    Private Key Exfiltration Surface<\/td>\nFilesystem disk, RAM dumps, CI logs<\/td>\nZero (anchored in hardware secure enclave)<\/td>\nZero (hardware token + ephemeral token handle)<\/td>\n<\/tr>\n
    Credential Lifetime<\/td>\nIndefinite (months to years)<\/td>\nIndefinite (requires manual file deletion)<\/td>\nShort-lived (15 minutes to 8 hours maximum)<\/td>\n<\/tr>\n
    Server-Side State Management<\/td>\nIndividual keys per user in ~\/.ssh\/authorized_keys<\/td>\nFIDO2 public keys deployed to all servers<\/td>\nStateless: Single Trusted CA Public Key in sshd_config<\/td>\n<\/tr>\n
    Revocation Latency & Effort<\/td>\nHigh: Must push configuration updates to all hosts<\/td>\nHigh: Must purge public keys across server fleet<\/td>\nInstant: Certificate naturally expires without action<\/td>\n<\/tr>\n
    Physical Touch (UP) & PIN (UV)<\/td>\nNone (passphrase cached in ssh-agent)<\/td>\nEnforced per connection or key session<\/td>\nMandated by both client token and server policy<\/td>\n<\/tr>\n
    Role & Principal Enforcement<\/td>\nCoarse (tied to fixed Unix user accounts)<\/td>\nCoarse (tied to fixed Unix user accounts)<\/td>\nGranular: Cryptographic principals baked into cert<\/td>\n<\/tr>\n
    Handshake Cryptographic Latency<\/td>\n< 5 ms<\/td>\n~15 ms + human touch delay<\/td>\n< 20 ms + human touch delay<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

    Designing the Ephemeral OpenSSH Certificate Authority Pipeline<\/h2>\n

    While standalone FIDO2 keys protect the private key from exfiltration, they do not solve the problem of server-side key management. Target servers still need to hold the public key in ~\/.ssh\/authorized_keys<\/code>. If an engineer departs the company, operations teams must crawl across every single cluster, container, and bare-metal instance to delete that key.<\/p>\n

    The solution is an OpenSSH Certificate Authority (CA)<\/strong>. In this architecture:<\/p>\n

      \n
    1. Target Linux servers do not know or care about individual engineer public keys. Each server is configured with exactly one trusted key: TrustedUserCAKeys \/etc\/ssh\/ssh_ca_user_key.pub<\/code>.<\/li>\n
    2. When an engineer initiates their work shift, they authenticate against the organization’s central identity provider (IdP) via single sign-on (SSO) and WebAuthn.<\/li>\n
    3. The internal CA signs the engineer’s FIDO2 public key (id_ed25519_sk.pub<\/code>) and returns an ephemeral certificate (id_ed25519_sk-cert.pub<\/code>) valid for a strictly bounded window (e.g., 4 hours).<\/li>\n
    4. The certificate encodes the user’s allowed system accounts (principals, e.g., sysadmin<\/code>, deployer<\/code>, root<\/code>), serial number, and security extensions.<\/li>\n
    5. When the engineer connects to any server in the fleet, OpenSSH 9.8 inspects the certificate’s cryptographic signature against the local CA public key, verifies that the certificate has not expired, checks that the requested Unix account is listed in the certificate’s authorized principals, and verifies the hardware token challenge response.<\/li>\n
    6. At the end of the 4-hour window, the certificate expires automatically. Even if a bad actor copies the certificate, it is useless without both the physical FIDO2 key and a valid validity timestamp.<\/li>\n<\/ol>\n
      \n Security Hardening:<\/strong> In OpenSSH 9.8, the daemon introduces defense-in-depth privilege separation enhancements alongside support for post-quantum hybrid key exchange algorithms (such as sntrup761x25519-sha512@openssh.com<\/code> and ML-KEM hybrid modes). Combining quantum-safe key exchange with hardware-bound FIDO2 certificates neutralizes both immediate infostealer threats and long-term Harvest Now, Decrypt Later (HNDL) surveillance risks.<\/div>\n

      Step-by-Step Implementation and Production Configuration Files<\/h2>\n

      1. Client Workstation Hardware Access: Udev Rules<\/h3>\n

      On Linux client workstations, standard unprivileged users cannot interact directly with USB HID devices without proper udev rules. Create \/etc\/udev\/rules.d\/70-u2f.rules<\/code> to permit your local administrative user group to communicate with FIDO2 authenticators via libfido2<\/code>:<\/p>\n

      # \/etc\/udev\/rules.d\/70-u2f.rules\n# Allow unprivileged plugdev\/wheel access to FIDO2 \/ U2F USB devices\nACTION!=\"add|change\", GOTO=\"u2f_end\"\n\n# Yubico YubiKey 5 \/ FIDO devices\nKERNEL==\"hidraw*\", SUBSYSTEM==\"hidraw\", ATTRS{idVendor}==\"1050\", ATTRS{idProduct}==\"0407|0402|0403|0406|0410\", TAG+=\"uaccess\", GROUP=\"plugdev\", MODE=\"0660\"\n\n# SoloKeys, Nitrokey, and Generic FIDO2 Authenticators\nKERNEL==\"hidraw*\", SUBSYSTEM==\"hidraw\", ATTRS{idVendor}==\"1209|20a0\", TAG+=\"uaccess\", GROUP=\"plugdev\", MODE=\"0660\"\n\nLABEL=\"u2f_end\"<\/code><\/pre>\n
      Reload and trigger the udev daemon: udevadm control --reload-rules && udevadm trigger<\/code>.<\/p>\n
      2. Generating the Hardware-Bound FIDO2 Keypair<\/h3>\n
      Generate a non-extractable, PIN-enforced Ed25519 FIDO2 resident key on the engineer’s workstation. The verify-required<\/code> option mandates that the hardware key prompt for the token PIN or biometric check on every authentication session:<\/p>\n
      ssh-keygen -t ed25519-sk \\\n  -O resident \\\n  -O application=ssh:cpanelfree-prod \\\n  -O verify-required \\\n  -f ~\/.ssh\/id_ed25519_sk \\\n  -C \"engineer-alice@cpanelfree.internal (YubiKey 5C)\"<\/code><\/pre>\n
      3. Central Certificate Authority (CA) Generation<\/h3>\n
      On a dedicated, isolated CA server (or offline signing machine), generate the enterprise root SSH CA key. Keep this private key strictly protected behind hardware HSMs or encrypted storage:<\/p>\n
      # Generate dedicated ed25519 CA root signing key\nssh-keygen -t ed25519 -a 100 -f \/etc\/ssh\/ca\/ssh_ca_user_key -C \"cpanelfree-production-ssh-ca-2026\"\nchmod 600 \/etc\/ssh\/ca\/ssh_ca_user_key\nchmod 644 \/etc\/ssh\/ca\/ssh_ca_user_key.pub<\/code><\/pre>\n
      4. Production Automated Certificate Signing Script<\/h3>\n
      Deploy this automated signing script on your CA service to issue time-boxed certificates with granular principals. In this production example, certificates are bounded to a maximum validity window of 4 hours:<\/p>\n
      #!\/usr\/bin\/env bash\n# \/usr\/local\/bin\/issue-shortlived-ssh-cert.sh\n# Production OpenSSH Ephemeral Certificate Issuance Utility\nset -euo pipefail\n\nCA_KEY=\"\/etc\/ssh\/ca\/ssh_ca_user_key\"\nUSER_PUBKEY=\"$1\"       # Path to received public key (e.g. alice_id_ed25519_sk.pub)\nKEY_IDENTITY=\"$2\"      # Identity string for audit logs (e.g. alice@cpanelfree.com)\nPRINCIPALS=\"$3\"        # Comma-separated list of allowed system accounts (e.g. sysadmin,deployer)\nTTL=\"+4h\"              # Strict 4-hour lifespan\nSERIAL_NUM=$(date +%s%N | cut -b1-16)\n\nif [[ ! -f \"${CA_KEY}\" ]]; then\n  echo \"CRITICAL: CA Private Key not found at ${CA_KEY}\" >&2\n  exit 1\nfi\n\necho \"Signing ephemeral SSH certificate for ${KEY_IDENTITY} with principals: ${PRINCIPALS}...\"\n\n# Execute certificate signing with OpenSSH 9.8\nssh-keygen -s \"${CA_KEY}\" \\\n  -I \"${KEY_IDENTITY}\" \\\n  -n \"${PRINCIPALS}\" \\\n  -V \"-5m:${TTL}\" \\\n  -z \"${SERIAL_NUM}\" \\\n  -O permit-pty \\\n  -O permit-user-rc \\\n  -O permit-port-forwarding \\\n  \"${USER_PUBKEY}\"\n\necho \"SUCCESS: Certificate generated at ${USER_PUBKEY%.pub}-cert.pub (Valid for 4 hours)\"<\/code><\/pre>\n
      Grant execution privileges: chmod 750 \/usr\/local\/bin\/issue-shortlived-ssh-cert.sh<\/code>. To inspect the cryptographic attributes, validity window, and principals of the issued certificate, execute:<\/p>\n
      ssh-keygen -L -f ~\/.ssh\/id_ed25519_sk-cert.pub<\/code><\/pre>\n
      5. Target Host OpenSSH 9.8 Hardened Daemon Configuration<\/h3>\n
      On all target servers across your fleet, deploy the CA public key to \/etc\/ssh\/ssh_ca_user_key.pub<\/code>. Then configure the hardened OpenSSH 9.8 daemon drop-in under \/etc\/ssh\/sshd_config.d\/99-hardened-fido2.conf<\/code>. This configuration disables password authentication, restricts allowed algorithms exclusively to modern curves and post-quantum hybrids, and validates incoming certificates against the CA:<\/p>\n
      # \/etc\/ssh\/sshd_config.d\/99-hardened-fido2.conf\n# Enterprise OpenSSH 9.8 Daemon Hardening Configuration\n\n# 1. Ephemeral Certificate Authority & Principals Mapping\nTrustedUserCAKeys \/etc\/ssh\/ssh_ca_user_key.pub\nAuthorizedPrincipalsFile \/etc\/ssh\/auth_principals\/%u\n\n# 2. Strict Authentication Guardrails\nPasswordAuthentication no\nKbdInteractiveAuthentication no\nPermitEmptyPasswords no\nPermitRootLogin prohibit-password\nPubkeyAuthentication yes\nAuthenticationMethods publickey\nMaxAuthTries 3\nLoginGraceTime 30s\n\n# 3. Restrict Accepted Public Key and Certificate Algorithms\nPubkeyAcceptedAlgorithms sk-ssh-ed25519-cert-v01@openssh.com,sk-ssh-ed25519@openssh.com,ssh-ed25519-cert-v01@openssh.com,ssh-ed25519\n\n# 4. Modern Post-Quantum Hybrid Key Exchange & Cryptographic Ciphers\nKexAlgorithms sntrup761x25519-sha512@openssh.com,curve25519-sha256,curve25519-sha256@libssh.org,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512\nCiphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com\nMACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com\n\n# 5. Session Isolation and Privilege Hardening\nClientAliveInterval 300\nClientAliveCountMax 2\nX11Forwarding no\nAllowAgentForwarding no\nTCPKeepAlive yes\nCompression no<\/code><\/pre>\n
      6. Principal Access Mapping Configuration<\/h3>\n
      OpenSSH uses the AuthorizedPrincipalsFile<\/code> directive to map certificate principals to local Unix accounts. Create the principals directory and define which certificate roles can log in as the target system user:<\/p>\n
      mkdir -p \/etc\/ssh\/auth_principals\nchmod 755 \/etc\/ssh\/auth_principals\n\n# \/etc\/ssh\/auth_principals\/sysadmin\n# Only certificates containing one of these signed principals may log in as 'sysadmin'\necho -e \"core-infrastructure\\nplatform-admin\\nsite-reliability-engineer\" > \/etc\/ssh\/auth_principals\/sysadmin\nchmod 644 \/etc\/ssh\/auth_principals\/sysadmin<\/code><\/pre>\n
      Validate the OpenSSH daemon configuration syntax before reloading the systemd service: sshd -t<\/code>. Once verified without errors, reload OpenSSH: systemctl reload sshd<\/code>.<\/p>\n
      7. Hardened Client SSH Configuration<\/h3>\n
      On the administrator workstation, configure ~\/.ssh\/config<\/code> to automatically associate the FIDO2 key handle and its corresponding short-lived certificate:<\/p>\n
      # ~\/.ssh\/config\n# Client-side configuration for OpenSSH 9.8 FIDO2 + Certificate authentication\n\nHost *.cpanelfree.internal *.cpanelfree.net\n    User sysadmin\n    Port 22\n    IdentityFile ~\/.ssh\/id_ed25519_sk\n    CertificateFile ~\/.ssh\/id_ed25519_sk-cert.pub\n    IdentitiesOnly yes\n    PasswordAuthentication no\n    PubkeyAuthentication yes\n    ForwardAgent no\n    ServerAliveInterval 60\n    ServerAliveCountMax 3\n    VerifyHostKeyDNS yes<\/code><\/pre>\n
      \n  Production Advisory:<\/strong> Always keep a secondary backup FIDO2 hardware token registered and stored in a secure physical safe. If an engineer loses their primary security key, the CA will refuse to issue certificates against the lost key handle. The engineer simply retrieves the backup hardware token, requests a new short-lived certificate, and resumes operations without modifying a single target server.<\/div>\n
      Operational Runbook, Auditing, and Failure Modes<\/h2>\n
      Maintaining an enterprise OpenSSH PKI deployment requires continuous observability. Because static authorized keys are no longer present, access logs generated by OpenSSH 9.8 provide rich, tamper-evident forensic trails.<\/p>\n
      When an engineer connects using a certificate, OpenSSH writes the full certificate identity, serial number, and signing CA fingerprint to the system journal:<\/p>\n
      journalctl -u sshd -g \"Accepted publickey\" -f<\/code><\/pre>\n
      A typical production log entry will output:<\/p>\n
      Accepted publickey for sysadmin from 198.51.100.45 port 52310 ssh2: ED25519-SK-CERT SHA256:7mP... ID engineer-alice@cpanelfree.internal (serial 1789745403001) CA ED25519 SHA256:aX9...<\/code><\/pre>\n
      If an engineer presents an expired certificate or attempts to log in as a principal not listed in \/etc\/ssh\/auth_principals\/<\/code>, OpenSSH rejects the connection instantly before any shell or session pty is allocated:<\/p>\n
      error: Certificate has expired\nfatal: user sysadmin not authorized to log in with given certificate principals<\/code><\/pre>\n
      Frequently Asked Questions<\/h2>\n
      \nWhat happens if an engineer loses their physical FIDO2 hardware token?<\/summary>\n
      Because access relies on short-lived certificates, the lost hardware key becomes completely useless the moment the current certificate expires (typically within 1 to 4 hours). Furthermore, the finder cannot use the key without knowing the user verification PIN. In the central IdP\/CA directory, the administrator marks the lost token ID as revoked, preventing any future certificates from being signed for that hardware serial number. Zero changes are needed across your fleet of target production servers.<\/p>\n<\/details>\n
      \nCan FIDO2 keys and ephemeral certificates work in automated CI\/CD deployment pipelines?<\/summary>\n
      Yes, through OpenID Connect (OIDC) workload identity federation. Instead of storing a static SSH private key in GitHub Actions or GitLab CI secrets, the runner exchanges an ephemeral OIDC JWT token with your internal CA service. The CA verifies the repository name, branch, and commit hash, and issues a 10-minute short-lived SSH certificate with the deployer<\/code> principal. CI jobs achieve fully passwordless, keyless server deployment with zero persistent credentials.<\/p>\n<\/details>\n
      \nWhy is Ed25519-SK preferred over ECDSA-SK for production FIDO2 authenticators?<\/summary>\n
      Ed25519-SK provides superior cryptographic properties compared to ECDSA (NIST P-256). It is immune to timing side-channel attacks, eliminates dependence on dubious NIST random number generation constants, computes signatures faster with lower CPU overhead, and generates shorter public keys. Unless you are constrained by legacy FIDO1\/U2F tokens that only support NIST P-256, Ed25519-SK is the industry gold standard.<\/p>\n<\/details>\n
      \nHow does OpenSSH 9.8 protect against server-side impersonation and Man-in-the-Middle (MITM) attacks?<\/summary>\n
      OpenSSH certificates work symmetrically for both users and hosts. Just as the server trusts an authority for user authentication via TrustedUserCAKeys<\/code>, client workstations can trust an authority for host authentication via @cert-authority *.cpanelfree.internal ssh-ed25519 AAAAC3NzaC1lZDI1NTE5...<\/code> in ~\/.ssh\/known_hosts<\/code>. This eliminates the infamous “The authenticity of host can’t be established” prompt, guarantees host identity cryptographically, and eliminates Man-in-the-Middle attacks across ephemeral cloud fleets.<\/p>\n<\/details>\n
      \n
      Ready to Deploy High-Performance Infrastructure?<\/h3>\n
      Experience blazing-fast NVMe storage, unmetered bandwidth, and enterprise LiteSpeed caching on CpanelFree.<\/p>\n
      Get Started with Free Cloud Hosting →<\/a><\/div>\n","protected":false},"excerpt":{"rendered":"
      Eliminate static SSH key sprawl and prevent credential theft with OpenSSH 9.8 FIDO2 hardware tokens and ephemeral CA certificates. Secure your infrastructure.<\/p>\n","protected":false},"author":1,"featured_media":4561,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[172],"tags":[57,177,87,173,101],"class_list":["post-4562","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-security-hardening","tag-almalinux","tag-databases-performance","tag-devops","tag-security-hardening","tag-sysadmin"],"_links":{"self":[{"href":"https:\/\/cpanelfree.com\/blog\/wp-json\/wp\/v2\/posts\/4562","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/cpanelfree.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/cpanelfree.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/cpanelfree.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/cpanelfree.com\/blog\/wp-json\/wp\/v2\/comments?post=4562"}],"version-history":[{"count":0,"href":"https:\/\/cpanelfree.com\/blog\/wp-json\/wp\/v2\/posts\/4562\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/cpanelfree.com\/blog\/wp-json\/wp\/v2\/media\/4561"}],"wp:attachment":[{"href":"https:\/\/cpanelfree.com\/blog\/wp-json\/wp\/v2\/media?parent=4562"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/cpanelfree.com\/blog\/wp-json\/wp\/v2\/categories?post=4562"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/cpanelfree.com\/blog\/wp-json\/wp\/v2\/tags?post=4562"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}