Remote access management

“Remote access management” centrally manages SSH login credentials and remote connections. It replaces the fleet’s former “Remote connection management” entry and is also available at device level.

Pages and permissions

Page	Content
Fleet → Remote access management → Connection management	View active connections and disconnect them according to permissions
Fleet → Remote access management → Key management	Store shared fleet SSH credentials
Device → Remote access management	Store device-specific SSH credentials, view inherited entries, and confirm host identity; key management only
Device overview → Remote desktop	Select stored credentials or use a password to connect; no upload functionality

Masters and Admins manage credentials and host identities. Credentials default to “Administrators only”; administrators can explicitly grant access to “Members with remote connection permission,” including Developers. Observers can view metadata only, without connecting or modifying it.

Credential usage and management permissions are separate. Permission to use a credential does not permit viewing or downloading its private key. No role has a private key viewing or export interface. Connection operations record the actual user.

Initial setup

1. The device administrator configures the target system account’s user public key, or the issuing CA public key and permitted principals.
2. In fleet or device key management, select “Add SSH credential” and enter a name, device system account, and authentication method.
3. Upload the user private key. Certificate authentication also requires an externally issued user certificate; encrypted private keys require a passphrase. Do not upload CA private keys.
4. Select permitted members, optionally make the credential the default, and save.
5. Register the host public key on the device page and confirm it after verifying the fingerprint through a trusted channel.
6. The connecting user selects the account, authentication method, and stored credential under “Remote desktop,” then validates the connection.

On save, the platform detects algorithms and validates certificate signatures, validity periods, and the match with the user private key. Saving credentials and their usage permissions grants platform connection authorization; no separate public-key or CA authorization is needed. Users still maintain device-side public keys, CA/principal configuration, and authentication restrictions themselves.

Devices do not fetch cloud keys or report versions or application status for this setup. The platform does not edit device files. A successful save means cloud configuration is stored; the device SSH service validates the actual login.

For complete Windows PowerShell/Linux instructions covering key generation, CA issuance, device authorization, cloud upload, and connection validation, see SSH key and certificate authentication. Ordinary key authentication needs no CA. OpenSSH user certificate authentication requires a user certificate and matching private key; the issuer always retains the CA private key.

Device precedence, fleet inheritance, and defaults

Inheritance is determined by the target system account and authentication method:

• When matching device configuration exists, only device credentials can be used; fleet entries are shown as overridden.
• Without matching device configuration, fleet entries apply automatically, without an inheritance switch.
• Expired, disabled, revoked, or unauthorized device entries do not cause automatic fallback to fleet credentials or password authentication.
• Multiple entries and a default can be stored at the same level. A default designation does not bypass availability or permission checks.

Inherited entries are read-only and must be edited at fleet level. Disabling or revoking an entry retains device precedence. Deleting the last matching device configuration may restore fleet inheritance; review the impact shown in the confirmation dialog first.

Credential scope restricts only the JelinaCloud entry point. To isolate fleets or accounts on the device itself, configure distinct public keys, CAs, or certificate principal rules.

Update, disable, revoke, and delete

Operation	Behavior
Edit	Change the name, permitted members, and default designation; private keys and passphrases are never shown
Update key/certificate	Upload a new user private key, optional user certificate, and required passphrase; account, scope, and authentication method remain the same
Disable/enable	Disabling is reversible; new connections are blocked, and existing connections are revalidated and closed
Revoke credential	The stored entry cannot be enabled again, and its encrypted private key is cleared; other separately stored entries and device trust are unaffected
Delete	Clears ciphertext while retaining audit metadata; deleting device entries may restore fleet inheritance

JelinaCloud does not automatically issue or renew user certificates. Request a new certificate from your CA administrator before expiry, then update and validate it on the management page. Changing a displayed validity period cannot extend a certificate.

Platform actions govern only connections through JelinaCloud and do not automatically clean up device authorized_keys, CAs, or local KRLs. To block direct SSH access, device administrators must implement local revocation and remove old authorizations themselves.

Confirm device host identity

Both key and certificate connections require device host identity verification. This identity is separate from user certificates and issuing CAs.

1. On the device or through a trusted channel, run cat /etc/ssh/ssh_host_*_key.pub to obtain existing host public keys.
2. Under device “Remote access management,” expand “Device host identity,” select “Register host public key,” and paste one line at a time.
3. On the device, run ssh-keygen -lf <corresponding-host-public-key-file> -E sha256 and compare the complete fingerprint with the page.
4. If they match, select “Verify and confirm.” Register and verify each algorithm separately.

Only host public keys are accepted, not user public keys, user certificates, CA public keys, or private keys. Supported algorithms are Ed25519, ECDSA nistp256/384/521, and RSA with 2048–8192 bits. Algorithms are detected automatically, and the backend chooses a confirmed key according to actual device negotiation; no guacd changes or user algorithm selection are required.

After device reinstallation or host identity changes, repeat trusted verification. Online status does not automatically establish trust in a new public key.

Connection settings and quotas

The management page maintains only login credentials and host identities. It no longer provides separate public-key authorization, CA authorization, personal certificates, or fleet/device policy editing. Device administrators determine which system accounts may log in with which public keys or CA principals.

Platform administrators centrally maintain the default runtime port and globally permitted authentication methods. The connection page shows currently allowed methods. To restrict direct device SSH authentication sources, such as passwords, change the device’s SSH configuration.

Connection quotas, per-user/device limits, idle timeouts, and maximum durations remain constrained by the platform’s organization plan and server capacity. Tenants can view effective values but cannot raise them.

Live connections and operation records

Connection management lists active connections and permits authorized disconnection. Live sessions reside in service memory; persistent session history is not provided. Operations use the existing operation logs. Old connections cannot be restored after service restarts or session state cleanup; reconnect instead.

Private key protection and device transfers

User private keys and required passphrases are stored encrypted. Metadata lists show only names, system accounts, scopes, algorithms, validity periods, permissions, and status. The user’s issuing authority retains CA private keys, which are not uploaded. The platform does not cache private keys in the browser for repeated login.

After a device moves to a new fleet or organization, old device-specific credentials and authorizations become unusable and their ciphertext is cleared. They are not automatically restored if the device moves back. Configure credentials for the current scope again and verify host identity; device administrators still maintain old device-side trust themselves.