Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more

An OpenSSH certificate authority (CA) lets you authenticate many users and servers through signed certificates instead of distributing every individual public key. Create separate CA key pairs for user and host certificates, sign ordinary SSH public keys with tightly scoped principals and validity periods, configure servers with TrustedUserCAKeys, configure host certificates with HostCertificate, and teach clients to trust the host CA through an @cert-authority entry in known_hosts.

What an OpenSSH CA does

An OpenSSH certificate is a signed wrapper around an ordinary SSH public key. The certificate carries the public key, an identity (the key identifier), zero or more principals, a validity interval, signed options and extensions, and a signature made by a CA private key. A server or client that relies on the certificate needs only the corresponding CA public key and its local policy. It verifies the CA signature and then checks the certificate’s constraints.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

This is a different, simpler format from X.509 certificates. OpenSSH has two distinct certificate roles:

Role What is signed Who verifies it Purpose
User (client) certificate A user’s public key SSH servers Authenticates a person or service account to a server
Host certificate A server’s host public key SSH clients Authenticates the server endpoint to a client

The practical advantage is trust compression. Without a CA, every server needs each user’s public key in authorized_keys, and every client needs each server key in known_hosts. With a CA, a relying party stores one CA public key and accepts certificates that satisfy its principal and policy checks. The CA private key remains the signing authority and must be protected accordingly.

#1 Best Overall
Sale
Compressed Air Duster,130000RPM Super Power Cordless Air Duster,Rechargeable Brushless Blower,3 Gear Adjustable Blower with LED Light,Dust Remover for Computer/House/Outdoor/Car
  • Powerful Turbo Fan:CAGIWIRU Electric Air Duster have reached speed up to 130000RPM,Can efficient remove dust and debris.With LED light and Three Adjustable Speed to meet with different cleaning tasks.
  • With Attached USB C Fasting Charging cable.Charing 3 hours,Enjoy up to 240 minutes of use on the lowest setting, For third speed can use for 25mins.with four charging options to meet with your needs.
  • Wide Application:Upgraded attached 5 different nozzles,making it suitable for a variety of scenes, such as car,pet, pc, keyboards, and other electronic devices. It also serves for office and home clean duster.
  • Handy Design & Portable:Cordless air duster electric nozzle is Light weight and small size, design and comfortable to hold and space saving, convenient to carry around. You can put it in your room or inside the car without taking up space.
  • Warranty & Support: Our Electric air duster comes with 5 years warranty and 24/7 customer service. During this period, if you have any questions,pls kindly feel free to contact us.

Plan the CA layout before generating keys

Use separate user and host CAs

Create one CA key pair for user certificates and another for host certificates, such as ca_user and ca_host. Keeping the roles separate limits what a stolen signing key can issue and makes trust policy easier to understand. A host CA should not also be trusted to authenticate users, and vice versa.

OpenSSH does not support a certification chain in which a root CA delegates to subordinate CAs. Each relying party must therefore trust the CA public key that signs the certificates it accepts. Document the ownership and intended scope of each CA.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

Protect private CA keys

  • Keep CA private keys off ordinary application and SSH servers whenever practical.
  • Use a unique, robust passphrase for each CA private key.
  • Restrict filesystem access and back up encrypted copies according to your incident-recovery policy.
  • Distribute only CA public keys to servers and clients. A CA public key does not permit signing.
  • Record every issuance with an asset or ticket reference. The certificate key identifier supplied with -I is logged when the certificate is used.

For a protected signing workflow, ssh-keygen can use a CA key held by a PKCS#11 token with -D, or a key loaded in an ssh-agent with -U. These integrations are optional; a normal encrypted CA key file also works.

Generate the CA key pairs

Run key generation on a protected administration system. The example uses Ed25519; select an algorithm and file permissions that your OpenSSH version and security policy support.

umask 077
ssh-keygen -t ed25519 -f ca_user -C 'OpenSSH user CA'
ssh-keygen -t ed25519 -f ca_host -C 'OpenSSH host CA'

Each command creates a private key (for example, ca_user) and a public key (for example, ca_user.pub). Keep the private files private. The public files are the trust anchors you will install in server and client configuration.

Issue a user certificate for a client key

Sign the user’s existing public key

You do not need to replace a user’s private key. Start with an existing public key such as id_ed25519.pub and sign it with the user CA:

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.
Rank #2
EVEO® Screen Cleaner Spray Kit (Streak-Free) TV Screen Cleaner for Smart TV, Lcd, LEd, Oled | Computer Screen Cleaner Spray and Wipe Microfiber Cloth - TV, Monitor, Laptop, iPad, Car - 6.7oz 1 Pack
  • Screen Cleaner is Your Screen’s New Bestfriend! - EVEO is proud to present a screen cleaner that’s perfectly suited for your TV. Meet your new screen cleaner, computer screen cleaner, laptop cleaner, iPad cleaner, Macbook,tv cleaner or any other electronic device. Our screen cleaner spray and wipe along with the included plush microfiber cloth, easily removes dust, fingerprints & other smudges on the screen’s surface. Clean effectively for a streak-free screen
  • Gentle on your Screens - Our screen cleaner spray and wipes is compatible to be used even for the most sensitive LCD, LED, CRT, and OLED screens in proper use. Be at ease knowing that this product is compatible with all the major brands: LG, SONY, Samsung, Sharp, iPad, iPhone, Android screens, Kindle, PC monitors - we’ve got you covered! Can be used as LCD screen cleaner, tv cleaner, smart tv screen cleaner, and more
  • Premium Super Soft Plush Microfiber Cloth - Included in this efficient screen cleaning kit. This screen cleaner spray and wipe has our signature plush microfiber cloth specially designed to comply with screens and monitors and leave them streak-free. Has been shown to effectively absorbs stubborn stains, zero streaks, and no fiber shedding. Always use this together with our screen cleaner for the best results
  • Easy-to-Use Screen Cleaner Kit + microfiber cleaning cloth - The EVEO Screen Cleaning Kit will easily be your new favorite tool when it comes to taking care of the things you love most, quick and easy solution for a streak-free screen. Simply screw on the sprayer gun on the screen cleaner bottle. Spray the cleaning liquid onto the microfiber cloth, then wipe the screen until desired cleanliness & shine is achieved.
  • Quality Screen Care Kit Worth Purchasing - Enjoy a convenient Screen Cleaner anytime, anywhere you need it. Your satisfaction is our top priority. We stand behind the quality of our products and that’s why, you shouldn’t be worrying at all. We manufacture the Best Screen Cleaner. and can be used for laptop cleaning kit, laptop screen cleaner, tv screen cleaner for smart tv. MacBook screen cleaner, monitor cleaner or screen cleaner spray for electronic devices with microfiber cleaning cloth
ssh-keygen -s ./ca_user 
  -I alice-laptop-2026-10 
  -V +52w 
  -n alice 
  ./id_ed25519.pub
Option Meaning
-s ./ca_user Selects the CA private key that signs the certificate.
-I alice-laptop-2026-10 Sets the certificate key identifier. Use a unique issuance, user, device or ticket reference; it is recorded in SSH authentication logs.
-V +52w Sets the validity interval. This example creates a certificate valid for 52 weeks from the signing time; choose a lifetime that matches your own risk and reissue capability.
-n alice Restricts the certificate principal to alice.
./id_ed25519.pub The public key being wrapped and signed.

The resulting file is normally id_ed25519-cert.pub. The principal must be a login name that the destination server will accept, or a principal that appears in an explicit authorized-principals policy. Avoid broad principal lists: a certificate should name only the accounts for which it is intended.

Tell the SSH client to offer the certificate

Configure the client to use the ordinary private key and offer the matching certificate alongside it:

Host bastion.example.com
    IdentityFile ~/.ssh/id_ed25519
    CertificateFile ~/.ssh/id_ed25519-cert.pub

The private key proves possession of the public key contained in the certificate. The certificate itself is public and can be copied to the client without exposing the private key.

Make destination servers trust the user CA

Copy ca_user.pub to every destination server through your controlled configuration channel. Install it with restrictive ownership and permissions, for example as /etc/ssh/ca_user.pub, then add this directive to sshd_config:

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.
TrustedUserCAKeys /etc/ssh/ca_user.pub

TrustedUserCAKeys makes certificates signed by that CA eligible for public-key authentication. If you do not configure an authorized-principals file, the username used for login must appear in the certificate’s principal list. In the example above, the certificate can authenticate as the alice account, subject to the server’s other authentication settings.

Use explicit principal mapping when names differ

For centralized role names, service identities or accounts whose accepted principals differ from their Unix login names, configure an explicit principals file:

Rank #3
BladeHawks RGB Gaming Mouse Pad Extra Large Extended 31.5x12 Inch-Black
  • 【Large size】:Measuring 800 x 300 mm/ 31. 5×12 inches, which is wider and taller than others. Large mouse pad can perfectly fit your keyboard and mouse of any size, and there is also ample space for peripherals such as phones, tablets, etc.
  • 【LED backlight mouse pad】:Blade Hawks RGB mouse pad provides 7 static modes and 7 dynamic modes will give you the options you are looking for. Power-off memory function remembers the last lighting mode you selected. The super glow fiber Chroma will give you a colorful gaming setup that you want.
  • 【Anti-slip rubber base】:Made from Natural rubber, this gaming mousepad will firmly grip your desktop, allowing you to enjoy the ultimate precision in the games you are most passionate about. It also comes with a texture that enhances this ability even further.
  • 【Smooth and waterproof surface】: Micro-textured cloth surface, for extremely precise mouse control and a smooth movement. When liquid splashes on the gaming mouse pad, it forms water droplets and slides down. Will not delay your work or gameplay.
  • 【Plug and play】: This mouse and keyboard pad is powered by USB, plug and play, no driver required. One button control light modes. Press one time to change the lighting mode, press twice to change the brightness, press and hold about 3 seconds turn ON/OFF.
TrustedUserCAKeys /etc/ssh/ca_user.pub
AuthorizedPrincipalsFile /etc/ssh/auth_principals/%u

For each account, create the corresponding file (for example, /etc/ssh/auth_principals/alice) and put one accepted principal on each line. This lets a certificate principal such as ops-admin map to an account only where that mapping is deliberately listed. Ensure the files are readable by the SSH daemon and protected from unauthorized edits.

After changing the configuration, validate it before reloading the daemon:

What’s actually slowing this PC down?

Pick the symptom - the matching free tool is one click away.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.
sshd -t

If validation succeeds, reload sshd using the service manager used by the operating system. Keep an existing administrative session open while testing so a configuration error does not lock you out.

Issue a host certificate for a server

Sign the server’s host public key

Use the host public key already paired with the server’s private host key. This example signs an Ed25519 host key and includes both a DNS name and an address that clients may use:

ssh-keygen -s ./ca_host 
  -I web-01-2026-10 
  -V +52w 
  -h 
  -n web-01.example.com,10.0.2.15 
  /etc/ssh/ssh_host_ed25519_key.pub

The -h option marks the result as a host certificate. The output is normally /etc/ssh/ssh_host_ed25519_key-cert.pub. Include every DNS name or address that clients will actually use; a certificate principal for web-01.example.com does not automatically cover an unrelated alias or IP address.

Load the certificate in sshd

OpenSSH does not discover host certificates automatically. Configure the server with both the private host key and its matching certificate:

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.
Rank #4
Sale
Vaydeer Wrist Rest for Keyboard and Mouse, Computer Ergonomic Wrist Support Pad, Soft Memory Foam Arm Cushion for Desk, Palm Hand Office Laptop Typing
  • 【Softer and More Comfortable】Vaydeer wrist rest has unique diamond pattern, which is the combination of softness and aesthetics. The materials of wrist rest are improved into higher quality memory foam and covered with silky smooth lycra. The computer wrist rest makes you as comfortable and cushiony as like rest your wrists on clouds.
  • 【Ergonomic Wrist Saver】The wrist rests for keyboard and mouse comes with a 17.32×3.15×0.83 inch keyboard wrist pad and a 5.94×3.15×0.83 inch mouse wrist support. Based on ergonomic design, the unique concave shape is the perfect fit for your wrist joints. The wrist rest pad fits most computer keyboards and laptops, improve hand and wrist posture, release your wrist and arm stress.
  • 【Non-Slip Rubber Bottom】Featuring an anti-skid silicone base on the bottom, this wrist keyboard support stays firmly in place on your desk, preventing the padding from sliding around, ensuring stable and consistent wrist support during extended computer sessions.
  • 【Better Experience & Pain Relief】Our keyboard arm rest is beneficial to alleviate the soreness caused by direct contact and friction between your arm and a hard desk surface, reducing the risk of wrist fatigue or carpal tunnel. The soft texture of memory foam can evenly distribute the pressure around your wrists and provide good support with just enough give.
  • 【Helpful in Multiple Scenarios】Whether you're working, studying, writing, typing, gaming, this keyboard and mouse rest combo is an essential accessory to add comfort and support to your hands and wrists. It’s also a great gift for men, women, family, friend, coworker, gamer, teacher, etc.
HostKey /etc/ssh/ssh_host_ed25519_key
HostCertificate /etc/ssh/ssh_host_ed25519_key-cert.pub

HostCertificate must point to a certificate whose public key matches a private key configured by HostKey. A mismatch prevents the certificate from being used. Validate with sshd -t, then reload the daemon through the host’s service manager.

Make clients trust the host CA

Add an @cert-authority known_hosts entry

Distribute ca_host.pub to clients through authenticated configuration management. Add an @cert-authority marker to a user’s ~/.ssh/known_hosts or to a system-wide ssh_known_hosts file:

@cert-authority *.example.com ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAA... host-ca

The host pattern determines which names this CA entry applies to. Verify the CA fingerprint through an authenticated channel before distributing it; receiving a public key does not by itself prove that it belongs to the intended authority.

Match the name used in the connection

When a client connects, the host certificate must contain a principal matching the hostname or address in the connection. If users connect to web-01.example.com, that exact name must be among the certificate principals. If they connect to 10.0.2.15, the address must also be listed. Make the client connection names, DNS aliases and certificate principal list agree before deployment.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

Inspect and test certificates before rollout

Inspect each certificate with ssh-keygen -L before copying it widely:

ssh-keygen -L -f id_ed25519-cert.pub
ssh-keygen -L -f /etc/ssh/ssh_host_ed25519_key-cert.pub

Check all of the following:

  • The signing CA fingerprint is the expected fingerprint for the role.
  • The certificate key type and public key match the intended private key.
  • User principals contain only the required account or role names.
  • Host principals include every DNS name and address clients will use, and no unintended names.
  • Validity start and end times match the issuance record and the clocks on participating systems.
  • The user principal maps to the intended login account or to an entry in AuthorizedPrincipalsFile.
  • Signed options and extensions do not grant capabilities that the role does not need.
  • The server accepts its configuration with sshd -t.
  • A test connection succeeds with verbose logging before broad deployment.

For client-side troubleshooting, run an individual test with ssh -vvv and confirm that the client offers the certificate, the server accepts the CA signature, and the principal is authorized. For server-side troubleshooting, inspect the SSH authentication log for the certificate key identifier and the reason a principal or validity check was rejected.

Best Value
Sale
Under Desk Cable Management Tray No Drill, Metal Mesh Cable Management Under Desk with Clamp Mount, 2 Hole Cable Tray with Wire Management and Cord Organizer for Home Office Standing Desk
  • 【No Drill Mounted】Cable management tray can be assembled in as little as 3 minutes or less-simply. Side clips easily clampe the edge of desk, pass through the holes on the sides, and secure excess cables with baskets. Desk cable management supports inward or outward installation to meet your needs in different scenarios, and provides you with great convenience when collecting and organizing wires.
  • 【Rubber Pad Protects Desk】Wire organizer under desk built-in soft rubber pads on the clamp protect your desk from scratches, so you will not damage your furniture or office.
  • 【Sturdy and Beautiful】Cord management under desk is made of high-quality carbon steel and holds about 15 lbs. The wire basket has 2 holes on each side of the tray to enable your cables to pass freely. Cable baskets are suitable for desk thickness use from 0.4" to 2.4".
  • 【Space Saving & Keep Organized】Desk cable management tray holds all your power cords, outlet strips, USB hubs and computer transformers hidden from your feet, and the data cables will not enter the vacuum cleaner to keep your desk clean and tidy. Desk wire organizer is also suitable for use in the kitchen and outdoors.
  • 【Reduce Safety Risks】Cable tray under desk keeps all plugs away from your kids, no more worry about tripping. Using 2 holes wire tray saves extra space, helps you easily cabling and wire protection. The mesh design is not easy to accumulate dust, but avoids safety accidents caused by messy wires.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Support on Ko-Fi

Validity, principals and audit policy

Choose validity periods deliberately

The signing command can express a relative interval such as +52w or an explicit start and end. There is no universal lifetime mandated by OpenSSH. Short-lived certificates reduce the window in which a stolen private key or certificate remains useful, but they require reliable issuance and renewal. Longer periods reduce operational overhead but leave more time for misuse. Set the interval according to your threat model, device lifecycle and ability to reissue.

Make principals narrow

A principal is an authorization name, not merely a comment. For users, it normally corresponds to a login name or an entry in an authorized-principals file. For hosts, it must correspond to a name or address used by clients. Do not rely on a certificate’s key identifier as an authorization control; use principals and server policy for that purpose.

Free tools Windows power users keep installed

One-click scans. No signup required.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

Use identifiers for auditing

Give every issuance a unique -I value that includes a person, asset, ticket or issuance date. OpenSSH logs this identifier when the certificate is used, allowing an authentication event to be tied back to an issuance record even when the underlying public key is reused.

Rotation and incident response

Certificates make routine rotation practical because you can issue a replacement while the CA trust anchor remains unchanged. Reissue user certificates as people, devices or roles change, and reissue host certificates when host keys, names or infrastructure assignments change. Schedule renewal before expiry and monitor for certificates approaching their end time.

If a CA private key is suspected or confirmed compromised, stop issuing from it immediately. Remove or replace that CA public key from every TrustedUserCAKeys configuration and every client @cert-authority entry, then reissue affected user and host certificates under a new CA. A CA key has a broad blast radius: every certificate it could sign is potentially affected. Because OpenSSH does not provide a delegated CA chain, plan replacement of the trust anchor itself rather than attempting to revoke only a subordinate signer.

Document who can authorize issuance, where private keys are stored, how fingerprints are verified, how certificates are renewed, and how a compromised CA is removed from servers and clients. Those operational decisions are local policy; OpenSSH does not prescribe one lifetime, revocation schedule or physical key-storage product.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

OpenSSH CA versus per-key management

Deployment concern OpenSSH CA Individual authorized_keys and known_hosts
Trust entries One trusted CA public key can cover many signed users or hosts. Each user public key and each host key must be distributed separately.
Issuance and rotation Issue a certificate from an existing key with a defined validity period; renew without editing every relying party. Add, replace and remove individual keys on every affected server or client.
Principal policy Principals and validity are signed constraints, optionally mapped through AuthorizedPrincipalsFile. Authorization is controlled by the location and options of each key entry.
Auditability A unique -I identifier is logged when the certificate is used. Logs identify the public key or account, but there is no certificate issuance identifier.
Compromise impact Compromise of a CA private key can affect every certificate that CA could issue; the trust anchor must be replaced. Compromise is usually limited to the individual key, though many scattered keys increase management risk.
Compatibility Uses OpenSSH certificate support on clients and servers, plus the relevant directives and known-hosts marker. Works with the basic public-key and host-key mechanisms already present in OpenSSH.

A CA is most valuable when the number of hosts, users or short-lived credentials makes per-key distribution cumbersome. For a very small, static environment, individual keys may be simpler. In either model, protect private keys and remove trust promptly when an identity or host is no longer authorized.

Common failure modes

The client says the host is unknown or untrusted

  • Confirm the host CA public key is present in the correct user’s known_hosts or the system-wide file.
  • Check that the entry uses the @cert-authority marker and a host pattern matching the name used in the connection.
  • Verify the CA fingerprint through an authenticated channel and compare it with the certificate’s signer.
  • Ensure the host certificate includes the exact DNS name or address used by the client.

The server rejects a user certificate

  • Verify TrustedUserCAKeys points to the intended CA public key and that the daemon was reloaded after the change.
  • Check that the login username appears in the certificate principals, or that the principal appears in the correct AuthorizedPrincipalsFile.
  • Check the certificate’s validity interval and system clocks.
  • Confirm the client offers both the private key and its matching CertificateFile.

sshd refuses a host certificate

  • Confirm HostCertificate names the certificate file and HostKey names the matching private key.
  • Inspect both files with ssh-keygen -L and compare the embedded public key with the configured host key.
  • Run sshd -t to identify syntax, path or permission errors before reloading.

A repeatable deployment sequence

  1. Define separate user and host CA ownership, key-protection rules, principal policy and renewal responsibilities.
  2. Generate encrypted CA key pairs on a protected system and distribute only their public keys.
  3. Sign a test user’s public key with a narrow principal, explicit validity interval and unique -I identifier.
  4. Install the user CA public key on a test server, configure TrustedUserCAKeys (and, if needed, AuthorizedPrincipalsFile), run sshd -t, reload and test.
  5. Sign a test server host key with every name and address clients will use, then configure HostCertificate.
  6. Install an authenticated @cert-authority entry on a test client and verify the CA fingerprint.
  7. Inspect both certificates with ssh-keygen -L, test with verbose SSH logging, and confirm the expected certificate identifier appears in logs.
  8. Automate issuance, renewal and trust-file distribution only after the manual path and recovery procedure are proven.

With those two trust directions configured independently, servers can verify client identities through the user CA while clients verify server identities through the host CA, without maintaining a separate trust entry for every key.

Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.