SSH key and certificate authentication

Complete four steps: generate keys/certificates → configure the device → upload to the cloud → verify the connection.

Configuration notes

The following examples can be adapted using existing materials and device authorizations. Files generated by commands are saved in the current directory. The platform does not automatically issue or renew certificates.

Prerequisites: the device is activated, Online, and running OpenSSH Server; a fleet Master/Admin configures JelinaCloud over HTTPS.

Step 1: Generate SSH keys / OpenSSH user certificates

Ordinary key login requires only a user key pair. Certificate login requires generating a user key pair first, then issuing a user certificate.

Generate user keys

Create and open an empty folder, such as JelinaSSH, on your computer. Open a terminal for your operating system and run:

Windows

Type powershell in the folder address bar, press Enter, and run:

ssh-keygen -t ed25519 -a 64 -f jelina_operator -C "JelinaCloud-operator"

If the command is unavailable, install “OpenSSH Client” through Windows “Optional features,” then reopen PowerShell.

Linux

Right-click an empty area in the folder, choose “Open in Terminal,” and run:

ssh-keygen -t ed25519 -a 64 -f jelina_operator -C "JelinaCloud-operator"

If the command is unavailable, install the OpenSSH client: openssh-client on Ubuntu/Debian or openssh-clients on Fedora/RHEL.

At Enter passphrase, set a private key passphrase, then repeat it at Enter same passphrase again. Input is not displayed. To omit a passphrase, press Enter twice. If prompted Overwrite (y/n)?, enter n to preserve existing files.

The current folder now contains:

File	Purpose and destination
jelina_operator (no extension)	User private key for login; upload to the cloud private key field
jelina_operator.pub	User public key; add its contents to the device for ordinary key login, or give it to the CA for certificate issuance

If the device requires RSA keys

Use this command on Windows or Linux instead:

ssh-keygen -t rsa -b 3072 -a 64 -f jelina_operator_rsa -C "JelinaCloud-operator"

It creates jelina_operator_rsa and jelina_operator_rsa.pub. Use those filenames throughout subsequent steps.

Issue a user certificate

Give jelina_operator.pub to your existing CA administrator for issuance. To issue it yourself, place the public key in the current folder on the management computer and run these commands in order.

Windows

1. Generate CA keys and set and confirm a passphrase. Skip this if you already have a CA, and use its actual files below.

ssh-keygen -t ed25519 -a 64 -f ca_ed25519 -C "JelinaCloud-customer-CA"

2. Issue the user certificate, entering the CA private key passphrase when prompted:

ssh-keygen -s ca_ed25519 -I operator-access-001 -z 1 -n ops-alice -V "-1m:+8h" jelina_operator.pub

Linux

1. Generate CA keys and set and confirm a passphrase. Skip this if you already have a CA, and use its actual files below.

ssh-keygen -t ed25519 -a 64 -f ca_ed25519 -C "JelinaCloud-customer-CA"

2. Issue the user certificate, entering the CA private key passphrase when prompted:

ssh-keygen -s ca_ed25519 -I operator-access-001 -z 1 -n ops-alice -V "-1m:+8h" jelina_operator.pub

Signed user key indicates completion. The files involved are:

File	Purpose and destination
ca_ed25519	CA private key for issuance; retained only by the issuer, never uploaded to the cloud or device
ca_ed25519.pub	CA public key used to establish device trust; add its contents in step 2
jelina_operator-cert.pub	User certificate; upload with the user private key

This example uses principal ops-alice, and the certificate expires eight hours after issuance. Change -V "-1m:+8h" to another finite period, such as -V "-1m:+7d", if needed. The issuer allocates and records serial number -z 1. Inspect the certificate with:

ssh-keygen -L -f jelina_operator-cert.pub

Step 2: Configure the device

On the JelinaOS (Linux) device, edit authorized_keys for the actual login account. This example uses operator; replace it with an existing device account:

Login account	Authorization file
operator, with home directory /home/operator	/home/operator/.ssh/authorized_keys
root	/root/.ssh/authorized_keys

Create the file if absent. Set .ssh permissions to 700, file permissions to 600, and ownership to the target account. Preserve existing contents and append authorization on a new line. The certificate file does not need to be copied to the device.

SSH key

Open jelina_operator.pub on your computer in a text editor, copy the entire line, and append it to the authorization file:

ssh-ed25519 <用户公钥Base64> JelinaCloud-operator

Use the actual file contents, not the placeholder. RSA public keys begin with ssh-rsa; copy the entire line in the same way.

OpenSSH user certificate

Open ca_ed25519.pub in a text editor and copy its entire line. At the end of the authorization file, enter this prefix, add one space, and paste the CA public key:

cert-authority,principals="ops-alice",no-agent-forwarding

The final result must occupy one line:

cert-authority,principals="ops-alice",no-agent-forwarding ssh-ed25519 <CA-public-key-Base64> JelinaCloud-customer-CA

Replace the placeholder with the actual CA public key. ops-alice must match -n used during issuance. The device receives the CA public key and authorization prefix; the user certificate and private key are uploaded to the cloud in the next step.

On Windows, right-click a public key file and choose “Open with → Notepad.” Editing only authorized_keys usually requires no SSH restart. Custom authorization paths follow the device’s configuration.

Step 3: Configure JelinaCloud and upload credentials

Upload credentials

1. Open fleet “Remote access management → Key management” or device “Remote access management,” then select “Add SSH credential.”
2. Enter a name and device system account, such as operator or root, select an authentication method, and upload files:

Authentication	Uploads
SSH key	Private key field: jelina_operator
OpenSSH user certificate	Private key field: jelina_operator; user certificate field: jelina_operator-cert.pub

3. If the private key is encrypted, enter the user private key passphrase. Set permitted members and defaults, then save.

Store shared credentials at fleet level and single-device credentials at device level. Do not upload CA private keys. After saving, confirm the host identity.

Confirm device host identity

Host public keys identify the target device and are separate from user keys and CAs. Read existing keys on the device:

cat /etc/ssh/ssh_host_*_key.pub

Register them one line at a time under device “Remote access management → Device host identity.” Compare the complete corresponding SHA256: fingerprint and select “Verify and confirm” if it matches. Register and verify each supported algorithm separately.

View device host public key fingerprints

On the device or through a trusted management channel, run each command for files that exist; skip missing files:

ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub -E sha256

ssh-keygen -lf /etc/ssh/ssh_host_ecdsa_key.pub -E sha256

ssh-keygen -lf /etc/ssh/ssh_host_rsa_key.pub -E sha256

Verify fingerprints again after reinstalling the device or changing host keys.

Step 4: Select credentials and verify login

1. Open device overview → “Remote desktop,” select “SSH,” and enter the system account.
2. Select “SSH key” or “OpenSSH user certificate,” then a stored credential.
3. Review idle and maximum connection durations and select “Connect.” No repeat upload or private key passphrase entry is needed.
4. When the terminal appears, run the following and confirm that it returns the expected device account:

whoami

For the same account and authentication method, device credentials take precedence. Fleet entries apply only when no device configuration exists. Expired, disabled, revoked, or unauthorized device credentials do not trigger automatic fallback.

After a certificate expires, obtain a newly issued certificate and select “Update key/certificate” in key management. The platform does not renew certificates automatically or modify device authorization.

Supported formats and common issues

• User keys and issuing CAs support Ed25519 and RSA with 2048–8192 bits. User private keys must use OpenSSH-v1; each private key or user certificate is limited to 64 KiB.
• User certificates require explicit validity periods and nonempty principals. Signatures support Ed25519 and RSA SHA-256/SHA-512. SHA-1, critical options, ECDSA user keys, X.509, and SSH host certificates are not accepted.
• Host public keys support Ed25519, ECDSA nistp256/384/521, and RSA with 2048–8192 bits. RDP and VNC continue to use password authentication.

Issue	Check
No available credentials	System account, authentication method, usage permissions, and device overrides
Incorrect private key or passphrase	Upload the matching user private key and its passphrase; a CA private key is not a substitute
Device rejects a certificate	CA authorization prefix, certificate principal, validity period, device clock, and SSH account restrictions
Host identity unconfirmed or changed	Reverify the device host public key for the actually negotiated algorithm
Connection closes automatically	Displayed idle/maximum duration, certificate validity, and device status

For additional administration details, see remote access management.