This guide describes the features and interface in TianShanOS 0.6.1. It may remain useful for later versions where those features are unchanged. A different version number does not automatically make the guide obsolete. If the interface, steps, or result messages differ, check the release notes for your installed version before proceeding.
Use this guide to change device passwords, set up SSH access, check server identities, and manage certificates. For first-time setup, start with Chapters 1, 2, and 3. Certificate and Config Pack procedures are intended for administrators responsible for those features.
admin can open Security and see keys, hosts, certificates, and Config Pack controls, but not Account Security.
root can also set the root and admin passwords or reset admin to its default password. These password-management operations check root authorization.
A Developer device is identified by the organizational unit (OU) in its device certificate. This is a device identity. Only these devices can currently export Config Packs and SSH host configurations; signing in as root does not change it.
A visible button does not establish that its API enforces access permissions. Apart from operations such as password management that check authorization themselves, access must currently be limited through a trusted management network.
Check that the browser's IP address belongs to the intended device and that your computer is on a trusted management network.
Confirm the SSH address, port, and username with the server administrator.
Deploying or revoking a public key through the page requires the remote account's password and password authentication. The server administrator decides whether to leave password authentication enabled afterward.
Before revoking access, deleting keys, or replacing certificates, make sure another management connection works: a server console, another administrator key, or the device's HTTP interface.
If an account is still marked as having an unchanged password, a password-change prompt appears after sign-in. Set a long, unique password. Choosing to change it later dismisses the prompt without changing the password.
The prompt is not an account-settings screen that you can reopen at any time. If admin has already changed its password and needs another change, root can set it from Security.
Sign in as root and open Security in the navigation bar.
Find the root or admin password controls under Account Security. Fill in the new password and its confirmation.
Select Set root password or Set admin password. The interface accepts 4-64 characters; four characters is a technical minimum. Use a long, unique password.
Check the result: sign in with the new password in a private browsing window before signing out of the original session. Setting a new password does not automatically end existing sessions.
If sign-in fails: check the account and device address first. Five consecutive failed attempts trigger a lockout of about five minutes. Avoid repeated guesses.
Root can select Reset admin to default to restore the password to rm01 and clear the login lockout. Sign in as admin in a new session and set a unique password immediately afterward.
For initial setup, create an RSA key, deploy its public key, review the result, and test the connection. Check the server fingerprint as part of this process. When retiring a key, revoke access on every server first, confirm that the old key no longer works, and only then delete it from the device.
Choose an unused key ID, such as backup01. Use a short combination of English letters and numbers, no more than 10 characters, with no commas. The actual limit is 10 UTF-8 bytes; non-ASCII characters can use more than one byte each.
Choose RSA 2048 or RSA 4096. RSA 2048 is the default. ECDSA options are shown, but the current SSH workflow does not support them; choose RSA for SSH.
Add a comment or alias if useful. Turn on Exportable only if you need to back up or migrate the private key. There is no page control for changing this option later.
Set Hidden if needed, then select Generate. This option affects list display; it does not keep the actual key ID secret.
Check the result: after completion, the window closes and the list refreshes. Find the intended ID and RSA type, then open Public Key. Check that the complete text starts with ssh-rsa.
While you wait: do not submit again. Closing the window does not cancel generation on the device.
Message or situation
What to do
The ID is already in use
Choose another ID. The new-key workflow now rejects existing IDs rather than overwriting their keys
The key count limit has been reached
The SSH key store holds eight keys. Retire an unused key through the revocation process first
Storage or memory is insufficient
Resolve the device resource issue before trying again. Do not treat the failure as successful creation
The key was generated, but the list could not be refreshed
Refresh manually and check the key; do not generate it again
Generation has not been confirmed
The device may still be working. Wait and check the record; do not resubmit the same ID
Cleanup did not complete
Check device storage, involve an administrator if needed, and pause further key creation
Finding a record with the same ID proves only that a record exists. If the result is unconfirmed, check that it is the intended key before treating the operation as complete.
Deployment appends the public key to the remote account's ~/.ssh/authorized_keys, allowing that account to accept the matching private key. It does not change the server password.
Select Deploy on the intended key's row.
Enter the server address, username, SSH port, and SSH login password.
Review the address and account, then select Start Deploy.
Read the result and check the corresponding record under Deployed Hosts.
The key was deployed, the host registered, and public-key sign-in verified
Check the host details, then test the actual task you need to run
The key was deployed and the host registered, but sign-in is unconfirmed
Select Test. If it fails, check remote authorization and account settings through another management connection
The key was deployed, but registration failed or is unconfirmed
Check the local list and remote authorization before deploying again
Deployment completed, but the list could not be refreshed
Refresh manually. A failed list refresh does not mean the remote key was not installed
Do not repeatedly deploy because the result is incomplete. Each deployment appends the key and may create duplicate entries. Use another management connection to inspect authorized_keys when you need to confirm the remote result.
Under Deployed Hosts, check the address, port, username, and key ID, then select Test.
If a Host fingerprint confirmation appears, obtain and compare a trusted fingerprint as described in Section 4.3 before choosing Trust & connect.
After connecting, the device attempts the fixed echo command echo "TianshanOS SSH Test OK".
What success means: the test page still checks whether the request succeeded, not the remote command's exit status or output. Use it as a basic connection check. For an important task, verify the actual output, exit status, and permissions. This test also does not establish that sudo or other application commands will work.
If it fails: check connectivity, the SSH service, the account, and remote public-key authorization. Stop retrying if the fingerprint changes or the server's identity is uncertain.
Confirm that another server-management connection works and that the original key remains on the device.
Select Revoke on the host row, enter the server password, and confirm Revoke & Remove. You can also start from the key row and enter the target details.
Read the result, then use a trusted connection to check that the public key and any duplicates are gone from authorized_keys. Confirm that the old key no longer works.
Revocation leaves an authorized_keys.bak backup. Handle it under the server's backup policy so old authorization is not restored later.
Check that the local host record was removed. The page now checks this request. If remote revocation succeeded but local removal failed, refresh and handle the local cleanup separately.
Only after every target server has been handled should you delete the old key and unneeded private-key copies.
If no matching public key is found: confirm that the account is correct and the key is absent on the server before choosing to remove only the local record.
If the host cannot be removed: a service may be using or protecting the record. Check service status and references under SSH Commands or the relevant automation settings. Finish stopping the service or resolving its references before trying again. Ask an administrator to check an uncertain state.
If revocation reports failure: identify which step failed. The remote key may already be gone even though local cleanup failed. Use the server's authorization and an actual sign-in check to establish the remote result. Keep the local key until this is resolved.
Public key: select Public Key and copy the complete, single-line value for the server administrator. This is public material; sending it to the wrong person does not expose the private key. Access is granted when an administrator adds it to an account's authorization list.
Private key: export is available only if Exportable was enabled during creation. Select Private Key on a trusted computer and isolated management network. Store it in an approved secret store and clear temporary clipboard and download copies. Never paste it into chat, tickets, or logs.
If Copy does nothing: browsers may restrict clipboard access on an HTTP page. Select and copy the text manually, then check its boundary markers and completeness. Do not weaken browser security settings to enable copying.
Attempts to remove server authorization; requires the remote password
Remove a host
Deletes a local connection record without revoking server access
Delete a key
Deletes local key material without contacting the server or revoking access
Remove a host fingerprint
Deletes a saved server-identity record, not its connection record or remote authorization
Deployed Hosts is a local list, not a live view of server authorization. An empty list does not prove that access has been removed, and a listed host is not guaranteed to be reachable.
A fingerprint identifies the server you are connecting to. This page stores a SHA-256 digest as 64 hexadecimal characters. OpenSSH tools commonly display SHA256:base64. Ask the administrator for the same format before comparing; the strings cannot be compared directly.
After initial deployment: select View under Known Host Fingerprints and compare the full value with one obtained from a server console, asset inventory, or another trusted channel. The table shows only the first 32 characters, which is not enough for a complete check.
When Test asks for confirmation: the dialog shows the current full fingerprint. Verify it independently before selecting Trust & connect. If it has changed, also check the server identity, IP, port, and maintenance record. Do not approve simply because the dialog appeared.
If the fingerprint differs or its source is unclear: cancel the connection and investigate. If you previously used a password over an untrusted connection, treat it as potentially exposed. Change it through a trusted connection, review sign-in logs, and remove unwanted authorization. Do not send a password through the suspicious connection to revoke access.
After an authorized rebuild or host-key change: check the new full fingerprint and maintenance record first. Once verified, accept it in the Test confirmation dialog. Alternatively, remove the old entry, test again, and confirm the verified fingerprint. The Test path now requires explicit confirmation; do not assume reconnecting will automatically trust the new key.
Protect the SD card: known-host fingerprints are synchronized to plaintext JSON on the card. At startup, available SD fingerprint configurations replace the corresponding local records. These files are not signed; do not allow untrusted changes to them.
This dedicated .tscfg workflow stores the address, port, username, authentication type, and key ID. It contains no SSH password or private key and does not grant remote access. It is separate from the unfinished general application in Chapter 6.
To export: on a Developer device, select Export on the host row. For another device, supply and verify its certificate, generate the package, and select Download. Check that the file was saved. An ordinary device may show the control, but its export request is rejected.
To import:
Confirm that the package was made for this device, the SD card is writable, and the source has been verified through a trusted channel.
Make sure this device has the correct referenced key. A matching ID alone is insufficient; the key material must match the server's authorization.
Select Import Host, choose the file, and review the preview. Enable overwrite only when you intend to replace a configuration with the same name.
Confirm and restart as prompted. Import first saves the package to the SD card; loading and decryption are attempted at restart.
Allow startup loading to finish, refresh the host list, check the address, account, port, and key, then test.
A successful preview establishes neither signer trust nor that this device is the recipient. The recipient fingerprint is checked during loading. Startup now merges host configurations and keeps unrelated local records; importing one package does not clear the entire previous list.
Remove an incorrect record and check that its corresponding SD configuration has been cleared. A remaining package can load again after restart. Resolve service references if the record is in use. Also read Section 5.6 before replacing the device certificate.
The current service on port 443 provides health, identity, and permission-test endpoints, not the full web interface. Default startup requires a device key, device certificate, client CA chain, and a valid device clock.
The device certificate and private key let the device prove its identity to clients.
A client certificate and private key, held by a computer or service, let the client prove its identity to the device.
The client verification CA on the device validates client certificates. It does not automatically make a computer or browser trust the device certificate.
This two-way authentication is called mutual TLS, or mTLS. Clients must still trust the device certificate's issuing CA and check its access name, permitted uses, and validity.
Saved, Within validity period, and HTTPS: Running describe storage, time validity, and service operation separately. One does not establish the others.
Status or situation
What to do
The device certificate, private key, or client verification CA is missing
Install the missing credentials using the following sections
Awaiting device time
Check that your computer's clock is correct, then select Set device time from this computer (browser source)
Not yet valid or Expired
Check the device clock and certificate dates; arrange renewal if it has expired
Within validity period, but HTTPS is not running
Read the displayed missing-credential, key-mismatch, or startup error; resolve it and refresh
The running service still uses previous credentials
Save other work and restart the device. Confirm the new credentials meet startup requirements and are in use
Storage or status is unconfirmed
Refresh and check. Restart if instructed; avoid repeated installation or deletion
After setting the time, check the displayed device time and synchronization status. When the service is not running, the system attempts startup once credential and time requirements are met. If it stays stopped, investigate the displayed reason rather than treating installation as proof that it is ready.
Select Generate Key Pair. This creates a separate ECDSA P-256 private key, unrelated to SSH keys. It cannot be exported through this interface.
If a key already exists, read Section 5.6 first. Proceeding overwrites it.
Select Generate CSR. Enter the device ID (CN), Organization, and Department, or leave all fields blank. Department corresponds to the certificate's organizational unit (OU).
Select Generate Certificate Signing Request and send the complete CSR text to your CA administrator.
Use a short, stable device ID. English letters and numbers are easiest to keep within the 63-byte UTF-8 limit. Non-ASCII characters can use multiple bytes. Shorten fields if the interface reports a length error.
Check names before issuance: the custom-field path does not generate a SAN. With all fields blank, CN is fixed at TIANSHAN-DEVICE-001; the current IP is added as an IP SAN only if available. No DNS SAN is added. Have the CA administrator use a controlled issuance process to include the actual IP or DNS names and required authentication purposes in the final certificate. This form cannot edit SANs.
A CSR contains no private key and does not install a certificate. Have the CA administrator inspect its public key, subject, and SAN before issuance.
Obtain a PEM certificate that matches the current device private key.
Select Install Cert, paste the complete text including its boundary markers, and select Install.
Check the saved result, certificate validity, and actual HTTPS status. Review the subject, issuer, and dates.
Installation checks the format and key pair. The new status display also reports time validity and startup requirements, but clients must still validate the trust chain, access name, and permitted uses.
If the key does not match, locate the certificate issued for the current CSR. Do not regenerate a private key to clear the error. If the result is unconfirmed, refresh and check what was saved before deciding whether to retry.
Select Install CA, paste one or more PEM CA certificates used to trust your clients, and select Install.
Check the status. A stopped service will attempt startup when credentials and time are ready. If a running service reports changed credentials, restart as instructed to apply them.
Access the appropriate test endpoints using a trusted client certificate with the correct purpose and role.
Repeat with an untrusted certificate or no certificate, and confirm rejection.
Check the result: HTTPS is running and uses the intended certificate. If Active certificate SHA-256 is displayed, compare its fingerprint. Trusted clients should access only the endpoints their roles permit; untrusted clients should not connect. Verify these outcomes on the actual device.
Certificate expiry: reuse an uncompromised key to request a new certificate, install it, follow the status instructions to apply it, and test again. Config Packs are tied to the recipient certificate fingerprint. Even with the same key, an old package may be rejected after reinitialization or restart because the certificate has changed. Arrange replacement packages beforehand.
Private-key replacement: the old CSR and certificate no longer match the new key. This does not revoke the old certificate at the CA. Handle an exposed key with the CA administrator separately. Packages that depend on a lost key may be unrecoverable.
Delete all credentials: Delete Credentials removes the device key, device certificate, and client CA chain together. Check that HTTP management access works and arrange replacement packages first. A public-certificate backup cannot restore a private key.
After deletion, check for No device certificate and missing credentials. A running HTTPS service may still hold the previous credentials; deleting stored data is not immediate revocation. Restart as instructed and confirm that the old credentials are no longer used. Restore the service with a new key, issued device certificate, client CA chain, and connection tests.
A Config Pack is an encrypted, signed .tscfg package. Packages can currently be created and inspected, but general configuration application is unfinished. Do not rely on it for production fleet configuration, disaster recovery, or acceptance checks that settings have changed.
Verification currently uses the signer certificate included in the package without establishing its certificate-chain trust. The signature covers ciphertext; do not assume every displayed field is authenticated. An Official label is not proof of a trusted source.
Use an asset system or an independent trusted channel to confirm the signer fingerprint, target-device certificate, and package purpose. The preview's target name does not replace a certificate fingerprint check. Receiving a certificate and fingerprint in the same message is not an independent check.
To provide this device's certificate: select Export Device Cert and copy the complete PEM and displayed fingerprint. Send the public certificate to the sender and confirm its fingerprint through another trusted channel.
To inspect a received package: open Import Config Pack, select or paste the .tscfg file, then select Verify Only. Review signer details and confirm the source. Verification neither applies settings nor proves that this device is the recipient. Stop if the source, target, or purpose is unclear.
Even after verification passes, the current general Import and Apply controls cannot be relied on to configure the device. Use supported controls on the relevant feature pages and check the resulting settings.
Prepare valid JSON configuration files on the SD card and obtain a verified target certificate.
Select Export Config Pack, choose files, enter a name and description, and paste the recipient-device certificate.
Generate the package, select Download, and check that the browser saved the .tscfg file.
Check the download and the file under /sdcard/output_config/ separately. The package may remain available for download even if the SD write fails.
Export does not change source settings. Regenerate a package made for the wrong recipient or a replaced recipient certificate. Successful export does not establish that general application on the receiving device is working.
Restrict access to the device and affected material; keep the records needed for investigation.
For an exposed SSH private key, revoke its public key on every affected server through trusted connections. Check backups and confirm that the old key no longer works.
Create and deploy a new RSA key under a new ID. Verify it, then remove the old key and exported copies.
For an exposed SSH password, change it through a trusted management connection and review sign-in records.
For an exposed HTTPS key, replace credentials as described in Section 5.6 and work with the CA administrator on revocation and old packages.
The local host list may not cover every server that granted access; also check server and asset records. Before sharing logs, review them for passwords, keys, or other sensitive content entered by users.
Account for HTTP management, incomplete centralized authorization, automatic trust on initial deployment, and Config Pack limitations. Hidden is not an access-control mechanism.
The reviewed build configuration does not enable NVS Encryption, Flash Encryption, or Secure Boot. Do not assume these protect stored keys or startup integrity. The flashed firmware configuration and hardware security settings require separate checks. Ask the security owner to arrange isolation or a fix if the intended environment cannot tolerate these limits.
This guide is based on the TianShanOS 0.6.1 code and Chinese and English interfaces, reviewed on October 9, 2026. Unchanged features may still be used as described in later versions. If controls, steps, or messages differ, check the release notes for your installed version before proceeding.
The review covered source code and a local simulated interface. Simulation was not treated as acceptance testing on hardware. Check SSH access, TLS handshakes, restarts, and remote authorization in your own environment as described here.
Public key / private key: share the public key with the administrator who grants access; keep the private key secret. Authentication uses the matching pair.
Fingerprint: a digest used to compare server or certificate identities. Convert differing display formats before comparing.
CSR / CA: a certificate signing request, and a certificate authority or its certificate.
CN / O / OU: common name, organization, and organizational unit in a certificate subject. Department in the form corresponds to OU.
SAN / EKU: the access names or IP addresses a certificate covers, and its permitted authentication purposes.
PEM: a text format with BEGIN/END markers for certificates, CSRs, and keys.
mTLS / PKI: mutual certificate authentication, and the certificate and trust-management system.
NVS: a Flash storage area for device settings and keys; its name does not imply encryption.
[CSR の生成] を選択します。デバイス ID (CN)、組織、部門を入力するか、すべてのフィールドを空白のままにします。部門は、証明書の組織単位 (OU) に対応します。
[証明書署名要求の生成] を選択し、完全な CSR テキストを CA 管理者に送信します。
短く安定したデバイス ID を使用してください。 英語の文字と数字を 63 バイトの UTF-8 制限内に収めるのが最も簡単です。非 ASCII 文字は複数バイトを使用できます。インターフェイスが長さエラーを報告する場合は、フィールドを短くします。
発行前に名前を確認してください: カスタム フィールドのパスは SAN を生成しません。すべてのフィールドが空白の場合、CN は TIANSHAN-DEVICE-001 に固定されます。現在の IP は、利用可能な場合にのみ IP SAN として追加されます。 DNS SAN は追加されません。 CA 管理者に、制御された発行プロセスを使用して、実際の IP 名または DNS 名と必要な認証目的を最終証明書に含めるよう依頼します。このフォームでは SAN を編集できません。
CSR には秘密キーが含まれておらず、証明書もインストールされません。発行前に CA 管理者に公開キー、サブジェクト、および SAN を検査してもらいます。
秘密キーの交換: 古い CSR と証明書は新しいキーと一致しなくなります。これにより、CA で古い証明書が取り消されることはありません。公開されたキーは CA 管理者と個別に処理してください。紛失したキーに依存するパッケージは回復できない場合があります。
すべての資格情報を削除: 資格情報を削除すると、デバイス キー、デバイス証明書、およびクライアント CA チェーンが一緒に削除されます。 HTTP 管理アクセスが機能することを確認し、最初に交換パッケージを手配します。公開証明書のバックアップでは秘密キーを復元できません。
削除後、デバイス証明書がないか、資格情報が欠落していないかを確認します。実行中の HTTPS サービスは、以前の資格情報を保持している可能性があります。保存されたデータを削除しても、すぐに取り消されるわけではありません。指示に従って再起動し、古い認証情報が使用されていないことを確認します。新しいキー、発行されたデバイス証明書、クライアント CA チェーン、および接続テストを使用してサービスを復元します。
이 가이드에서는 TianShanOS 0.6.1의 기능과 인터페이스에 대해 설명합니다. 해당 기능이 변경되지 않은 이후 버전에서는 여전히 유용할 수 있습니다. 버전 번호가 다르다고 해서 가이드가 자동으로 쓸모 없게 되는 것은 아닙니다. 인터페이스, 단계 또는 결과 메시지가 다른 경우 계속하기 전에 설치된 버전의 릴리스 노트를 확인하세요.
이 가이드를 사용하여 장치 비밀번호를 변경하고, SSH 액세스를 설정하고, 서버 ID를 확인하고, 인증서를 관리하세요. 처음 설정하는 경우 1, 2 및 3 장부터 시작하세요. 인증서 및 Config Pack 절차는 해당 기능을 담당하는 관리자를 위한 것입니다.
초기 설정을 위해 RSA 키를 생성하고, 공개 키를 배포하고, 결과를 검토하고, 연결을 테스트합니다. 이 프로세스의 일부로 서버 지문을 확인하십시오. 키를 폐기하는 경우 먼저 모든 서버에서 액세스 권한을 취소하고 이전 키가 더 이상 작동하지 않는지 확인한 후 기기에서 삭제하세요.
호스트 지문 확인이 나타나면 신뢰 및 연결을 선택하기 전에 4.3 섹션에 설명된 대로 신뢰할 수 있는 지문을 얻고 비교하십시오.
연결 후 장치는 고정 에코 명령 echo "TianshanOS SSH Test OK"를 시도합니다.
성공의 의미: 테스트 페이지에서는 원격 명령의 종료 상태나 출력이 아니라 요청 성공 여부를 계속 확인합니다. 기본적인 연결 확인으로 활용하세요. 중요한 작업의 경우 실제 출력, 종료 상태 및 권한을 확인합니다. 또한 이 테스트에서는 sudo 또는 기타 애플리케이션 명령이 작동하는지 확인하지 않습니다.
실패할 경우: 연결, SSH 서비스, 계정 및 원격 공개 키 인증을 확인하세요. 지문이 변경되거나 서버의 ID가 확실하지 않은 경우 재시도를 중지하세요.
호스트 행에서 취소를 선택하고 서버 비밀번호를 입력한 후 취소 및 제거를 확인합니다. 키 행에서 시작하여 대상 세부정보를 입력할 수도 있습니다.
결과를 읽은 다음 신뢰할 수 있는 연결을 사용하여 공개 키와 모든 중복 항목이 authorized_keys에서 사라졌는지 확인하세요. 이전 키가 더 이상 작동하지 않는지 확인하세요.
취소는 authorized_keys.bak 백업을 남깁니다. 나중에 이전 인증이 복원되지 않도록 서버의 백업 정책에 따라 처리하십시오.
로컬 호스트 레코드가 제거되었는지 확인하십시오. 이제 페이지에서 이 요청을 확인합니다. 원격 취소에 성공했지만 로컬 제거에 실패한 경우 로컬 정리를 별도로 새로 고치고 처리합니다.
모든 대상 서버가 처리된 후에만 이전 키와 불필요한 개인 키 복사본을 삭제해야 합니다.
일치하는 공개 키가 없는 경우: 로컬 레코드만 제거하도록 선택하기 전에 계정이 정확하고 서버에 키가 없는지 확인하세요.
호스트를 제거할 수 없는 경우: 서비스가 기록을 사용하거나 보호하고 있을 수 있습니다. SSH 명령 또는 관련 자동화 설정에서 서비스 상태 및 참조를 확인하세요. 다시 시도하기 전에 서비스 중지 또는 참조 확인을 완료하세요. 불확실한 상태를 확인하려면 관리자에게 문의하세요.
해지가 실패로 보고되는 경우: 실패한 단계를 식별합니다. 로컬 정리에 실패하더라도 원격 키가 이미 사라졌을 수 있습니다. 서버의 인증과 실제 로그인 확인을 사용하여 원격 결과를 설정합니다. 이 문제가 해결될 때까지 로컬 키를 보관하십시오.
공개 키: 공개 키를 선택하고 서버 관리자를 위한 전체 한 줄 값을 복사합니다. 이것은 공개 자료입니다. 잘못된 사람에게 보내면 개인 키가 노출되지 않습니다. 관리자가 계정의 인증 목록에 이를 추가하면 접근 권한이 부여됩니다.
개인 키: 내보내기는 생성 중에 내보내기 가능이 활성화된 경우에만 사용할 수 있습니다. 신뢰할 수 있는 컴퓨터와 격리된 관리 네트워크에서 개인 키를 선택하세요. 승인된 비밀 저장소에 저장하고 임시 클립보드를 지우고 사본을 다운로드하세요. 절대로 채팅, 티켓, 로그에 붙여넣지 마세요.
복사가 아무 작업도 수행되지 않는 경우: 브라우저는 HTTP 페이지에서 클립보드 액세스를 제한할 수 있습니다. 텍스트를 수동으로 선택하고 복사한 다음 경계 표시와 완전성을 확인하세요. 복사를 활성화하기 위해 브라우저 보안 설정을 약화시키지 마십시오.
지문은 연결 중인 서버를 식별합니다. 이 페이지는 SHA-256 다이제스트를 64 16진수 문자로 저장합니다. OpenSSH 도구는 일반적으로 SHA256:base64를 표시합니다. 비교하기 전에 동일한 형식에 대해 관리자에게 문의하십시오. 문자열은 직접 비교할 수 없습니다.
초기 배포 후: 알려진 호스트 지문 아래에서 보기를 선택하고 전체 값을 서버 콘솔, 자산 인벤토리 또는 다른 신뢰할 수 있는 채널에서 얻은 값과 비교합니다. 표에는 첫 번째 32 문자만 표시되어 있어 전체 확인에는 충분하지 않습니다.
테스트에서 확인을 요청하는 경우: 대화 상자에 현재 전체 지문이 표시됩니다. 신뢰 및 연결을 선택하기 전에 독립적으로 확인하세요. 변경된 경우 서버 ID, IP, 포트, 유지 관리 기록도 확인하세요. 단순히 대화 상자가 나타났다는 이유로 승인하지 마십시오.
지문이 다르거나 출처가 불분명한 경우: 연결을 취소하고 조사해 보세요. 이전에 신뢰할 수 없는 연결을 통해 비밀번호를 사용한 경우 잠재적으로 노출된 것으로 간주하십시오. 신뢰할 수 있는 연결을 통해 변경하고, 로그인 로그를 검토하고, 원치 않는 인증을 제거하세요. 접근 권한을 취소하기 위해 의심스러운 연결을 통해 비밀번호를 보내지 마세요.
승인된 재구축 또는 호스트 키 변경 후: 먼저 새로운 전체 지문 및 유지 관리 기록을 확인하세요. 확인되면 테스트 확인 대화 상자에서 이를 수락합니다. 또는 이전 항목을 제거하고 다시 테스트한 후 확인된 지문을 확인하세요. 이제 테스트 경로에는 명시적인 확인이 필요합니다. 다시 연결하면 새 키가 자동으로 신뢰될 것이라고 가정하지 마십시오.
SD 카드 보호: 알려진 호스트 지문은 카드의 일반 텍스트 JSON와 동기화됩니다. 시작 시 사용 가능한 SD 지문 구성이 해당 로컬 레코드를 대체합니다. 이 파일은 서명되지 않았습니다. 신뢰할 수 없는 변경을 허용하지 마십시오.
이 전용 .tscfg 워크플로는 주소, 포트, 사용자 이름, 인증 유형 및 키 ID를 저장합니다. SSH 비밀번호나 개인 키가 포함되어 있지 않으며 원격 액세스를 허용하지 않습니다. 6 장의 미완성 일반 응용 프로그램과 별개입니다.
내보내려면: Developer 장치에서 호스트 행에서 내보내기를 선택합니다. 다른 장치의 경우 해당 인증서를 제공 및 확인하고, 패키지를 생성하고, 다운로드를 선택합니다. 파일이 저장되었는지 확인하세요. 일반 장치에서는 컨트롤이 표시될 수 있지만 내보내기 요청이 거부됩니다.
가져오려면:
패키지가 이 장치용으로 제작되었는지, SD 카드에 쓰기 가능하고 소스가 신뢰할 수 있는 채널을 통해 확인되었는지 확인하세요.
이 장치에 올바른 참조 키가 있는지 확인하세요. 일치하는 ID만으로는 충분하지 않습니다. 키 자료는 서버의 인증과 일치해야 합니다.
호스트 가져오기를 선택하고 파일을 선택한 다음 미리보기를 검토합니다. 동일한 이름의 구성을 대체하려는 경우에만 덮어쓰기를 활성화하십시오.
메시지가 나타나면 확인하고 다시 시작하세요. 가져오기는 먼저 패키지를 SD 카드에 저장합니다. 다시 시작할 때 로드 및 암호 해독이 시도됩니다.
시작 로딩이 완료되도록 허용하고, 호스트 목록을 새로 고치고, 주소, 계정, 포트 및 키를 확인한 다음 테스트합니다.
미리보기에 성공해도 서명자를 신뢰할 수 있는지, 이 장치가 수신 대상인지는 확인되지 않습니다. 수신 대상 지문은 로드할 때 확인합니다. 시작 시 호스트 설정을 병합하고 관계없는 로컬 기록은 유지합니다. 패키지 하나를 가져와도 기존 목록 전체가 삭제되지는 않습니다.
잘못된 레코드를 제거하고 해당 SD 구성이 지워졌는지 확인하세요. 다시 시작한 후에 나머지 패키지를 다시 로드할 수 있습니다. 레코드가 사용 중인 경우 서비스 참조를 확인합니다. 장치 인증서를 교체하기 전에 5.6 섹션도 읽어보세요.
키 쌍 생성을 선택합니다. 이렇게 하면 SSH 키와 관련되지 않은 별도의 ECDSA P-256 개인 키가 생성됩니다. 이 인터페이스를 통해 내보낼 수 없습니다.
키가 이미 존재하는 경우 먼저 5.6 섹션을 읽으십시오. 계속하면 덮어쓰게 됩니다.
CSR 생성을 선택합니다. 장치 ID(CN), 조직, 부서를 입력하거나 모든 필드를 비워 둡니다. 부서는 인증서의 조직 단위(OU)에 해당합니다.
인증서 서명 요청 생성을 선택하고 전체 CSR 텍스트를 CA 관리자에게 보냅니다.
짧고 안정적인 장치 ID를 사용하세요. 영문자와 숫자는 63바이트 UTF-8 제한 내에서 유지하는 것이 가장 쉽습니다. ASCII가 아닌 문자는 여러 바이트를 사용할 수 있습니다. 인터페이스가 길이 오류를 보고하는 경우 필드를 줄이십시오.
발급 전 이름 확인: 사용자 정의 필드 경로는 SAN을 생성하지 않습니다. 모든 필드가 비어 있으면 CN은 TIANSHAN-DEVICE-001로 고정됩니다. 현재 IP는 사용 가능한 경우에만 IP SAN으로 추가됩니다. DNS SAN이 추가되지 않습니다. CA 관리자가 제어된 발급 프로세스를 사용하여 최종 인증서에 실제 IP 또는 DNS 이름과 필요한 인증 목적을 포함하도록 하십시오. 이 양식에서는 SAN을 편집할 수 없습니다.
CSR에는 개인 키가 없으며 인증서를 설치하지 않습니다. 발급 전에 CA 관리자에게 공개 키, 주제, SAN을 검사하도록 하세요.
CA 설치를 선택하고 클라이언트를 신뢰하는 데 사용되는 하나 이상의 PEM CA 인증서를 붙여넣은 다음 설치를 선택합니다.
상태를 확인하세요. 중지된 서비스는 자격 증명과 시간이 준비되면 시작을 시도합니다. 실행 중인 서비스가 변경된 자격 증명을 보고하는 경우 이를 적용하라는 지침에 따라 다시 시작하세요.
올바른 목적과 역할을 가진 신뢰할 수 있는 클라이언트 인증서를 사용하여 적절한 테스트 엔드포인트에 액세스합니다.
신뢰할 수 없는 인증서 또는 인증서 없음을 사용하여 반복하고 거부를 확인합니다.
결과 확인: HTTPS가 실행 중이며 원하는 인증서를 사용합니다. 활성 인증서 SHA-256가 표시되면 해당 지문을 비교하세요. 신뢰할 수 있는 클라이언트는 자신의 역할이 허용하는 엔드포인트에만 액세스해야 합니다. 신뢰할 수 없는 클라이언트는 연결하면 안 됩니다. 실제 장치에서 이러한 결과를 확인하십시오.
인증서 만료: 손상되지 않은 키를 재사용하여 새 인증서를 요청하고 설치한 후 상태 지침에 따라 적용하고 다시 테스트합니다. 구성 팩은 수신자 인증서 지문과 연결되어 있습니다. 동일한 키를 사용하더라도 인증서가 변경되었기 때문에 다시 초기화하거나 다시 시작한 후에 이전 패키지가 거부될 수 있습니다. 교체 패키지를 미리 준비하십시오.
개인 키 교체: 기존 CSR 및 인증서가 더 이상 새 키와 일치하지 않습니다. 이는 CA의 이전 인증서를 취소하지 않습니다. 노출된 키는 CA 관리자와 별도로 처리하세요. 분실된 키에 의존하는 패키지는 복구가 불가능할 수 있습니다.
모든 자격 증명 삭제: 자격 증명 삭제는 장치 키, 장치 인증서 및 클라이언트 CA 체인을 함께 제거합니다. HTTP 관리 액세스가 작동하는지 확인하고 먼저 교체 패키지를 준비하세요. 공개 인증서 백업은 개인 키를 복원할 수 없습니다.
삭제 후 장치 인증서 없음 및 자격 증명 누락을 확인하십시오. 실행 중인 HTTPS 서비스는 여전히 이전 자격 증명을 보유할 수 있습니다. 저장된 데이터를 삭제하는 것은 즉시 취소되는 것이 아닙니다. 지시에 따라 다시 시작하고 이전 자격 증명이 더 이상 사용되지 않는지 확인합니다. 새 키, 발급된 장치 인증서, 클라이언트 CA 체인 및 연결 테스트를 통해 서비스를 복원합니다.
이 장치의 인증서를 제공하려면 장치 인증서 내보내기를 선택하고 전체 PEM 및 표시된 지문을 복사합니다. 공개 인증서를 보낸 사람에게 보내고 다른 신뢰할 수 있는 채널을 통해 지문을 확인합니다.
수신된 패키지를 검사하려면 Config Pack 가져오기를 열고 .tscfg 파일을 선택하거나 붙여넣은 다음 확인만을 선택합니다. 서명자 세부정보를 검토하고 출처를 확인하세요. 확인을 통해 설정이 적용되거나 이 장치가 수신자인지 확인되지 않습니다. 출처, 대상, 목적이 불분명하면 중지하세요.
검증을 통과한 후에도 현재의 일반 가져오기 및 적용 컨트롤을 사용하여 장치를 구성할 수 없습니다. 관련 기능 페이지에서 지원되는 컨트롤을 사용하고 결과 설정을 확인하세요.
HTTP 관리, 불완전한 중앙 집중식 인증, 초기 배포 시 자동 신뢰 및 Config Pack 제한 사항을 위한 계정입니다. Hidden은 액세스 제어 메커니즘이 아닙니다.
검토된 빌드 구성은 NVS 암호화, 플래시 암호화 또는 보안 부팅을 활성화하지 않습니다. 이것이 저장된 키나 시작 무결성을 보호한다고 가정하지 마십시오. 플래시된 펌웨어 구성 및 하드웨어 보안 설정에는 별도의 확인이 필요합니다. 의도한 환경에서 이러한 제한을 허용할 수 없는 경우 보안 소유자에게 격리 또는 수정을 요청하세요.
이 가이드는 2026년 10월 9일에 확인한 TianShanOS 0.6.1 코드와 중국어·영어 화면을 기준으로 작성했습니다. 이후 버전에서도 기능이 바뀌지 않았다면 참고할 수 있습니다. 화면, 절차, 메시지가 다르면 사용 중인 버전의 릴리스 설명을 확인한 뒤 진행하세요.
검토에서는 소스 코드와 로컬 시뮬레이션 인터페이스를 다루었습니다. 시뮬레이션은 하드웨어에 대한 승인 테스트로 처리되지 않았습니다. 여기에 설명된 대로 사용자 환경에서 SSH 액세스, TLS 핸드셰이크, 다시 시작 및 원격 인증을 확인하세요.
공개 키/개인 키: 액세스 권한을 부여한 관리자와 공개 키를 공유합니다. 개인 키를 비밀로 유지하십시오. 인증은 일치하는 쌍을 사용합니다.
지문: 서버 또는 인증서 ID를 비교하는 데 사용되는 다이제스트입니다. 비교하기 전에 다양한 디스플레이 형식을 변환하세요.
CSR / CA: 인증서 서명 요청 및 인증 기관 또는 해당 인증서.
CN / O / OU: 인증서 주체의 일반 이름, 조직 및 조직 단위입니다. 양식의 부서는 OU에 해당합니다.
SAN / EKU: 인증서에 포함된 액세스 이름 또는 IP 주소와 허용된 인증 목적입니다.
PEM: 인증서, CSR 및 키에 대한 BEGIN/END 표시가 있는 텍스트 형식입니다.
mTLS / PKI: 상호 인증서 인증, 인증서 및 신뢰 관리 시스템.
NVS: 장치 설정 및 키를 위한 플래시 저장 영역입니다. 그 이름은 암호화를 의미하지 않습니다.
Esta guía describe las características y la interfaz de TianShanOS 0.6.1. Puede seguir siendo útil para versiones posteriores en las que esas características no hayan cambiado. Un número de versión diferente no hace que la guía quede obsoleta automáticamente. Si la interfaz, los pasos o los mensajes de resultados difieren, consulte las notas de la versión de su versión instalada antes de continuar.
Utilice esta guía para cambiar las contraseñas del dispositivo, configurar el acceso al SSH, verificar las identidades del servidor y administrar certificados. Para la configuración inicial, comience con los capítulos 1, 2 y 3. Los procedimientos de certificado y Config Pack están destinados a los administradores responsables de esas funciones.
admin puede abrir Seguridad y ver claves, hosts, certificados y controles Config Pack, pero no Seguridad de cuenta.
root también puede configurar las contraseñas de root y admin o restablecer admin a su contraseña predeterminada. Estas operaciones de administración de contraseñas verifican la autorización root.
Un dispositivo Developer se identifica mediante la unidad organizativa (OU) en su certificado de dispositivo. Esta es una identidad de dispositivo. Actualmente, solo estos dispositivos pueden exportar paquetes de configuración y configuraciones de host SSH; iniciar sesión como root no lo cambia.
Un botón visible no establece que su API aplique permisos de acceso. Aparte de operaciones como la gestión de contraseñas que comprueban por sí mismas la autorización, actualmente el acceso debe limitarse a través de una red de gestión fiable.
Verifique que la dirección IP del navegador pertenezca al dispositivo deseado y que su computadora esté en una red de administración confiable.
Confirme la dirección, el puerto y el nombre de usuario de SSH con el administrador del servidor.
La implementación o revocación de una clave pública a través de la página requiere la contraseña de la cuenta remota y la autenticación de contraseña. El administrador del servidor decide si deja habilitada la autenticación de contraseña después.
Antes de revocar el acceso, eliminar claves o reemplazar certificados, asegúrese de que funcione otra conexión de administración: una consola del servidor, otra clave de administrador o la interfaz HTTP del dispositivo.
Si una cuenta todavía está marcada con una contraseña sin cambios, aparece un mensaje de cambio de contraseña después de iniciar sesión. Establezca una contraseña larga y única. Si elige cambiarlo más tarde, se descarta el mensaje sin cambiar la contraseña.
El mensaje no es una pantalla de configuración de cuenta que pueda volver a abrir en cualquier momento. Si admin ya cambió su contraseña y necesita otro cambio, root puede configurarla desde Seguridad.
Inicie sesión como root y abra Seguridad en la barra de navegación.
Busque los controles de contraseña root o admin en Seguridad de la cuenta. Complete la nueva contraseña y su confirmación.
Seleccione Establecer contraseña root o Establecer contraseña admin. La interfaz acepta caracteres 4-64; cuatro caracteres es un mínimo técnico. Utilice una contraseña larga y única.
Compruebe el resultado: inicie sesión con la nueva contraseña en una ventana de navegación privada antes de cerrar sesión en la sesión original. Establecer una nueva contraseña no finaliza automáticamente las sesiones existentes.
Si falla el inicio de sesión: verifique primero la cuenta y la dirección del dispositivo. Cinco intentos fallidos consecutivos provocan un bloqueo de unos cinco minutos. Evite conjeturas repetidas.
Root puede seleccionar Restablecer admin a los valores predeterminados para restaurar la contraseña a rm01 y borrar el bloqueo de inicio de sesión. Inicie sesión como admin en una nueva sesión y establezca una contraseña única inmediatamente después.
Para la configuración inicial, cree una clave RSA, implemente su clave pública, revise el resultado y pruebe la conexión. Verifique la huella digital del servidor como parte de este proceso. Al retirar una clave, primero revoque el acceso a todos los servidores, confirme que la clave anterior ya no funciona y solo luego elimínela del dispositivo.
En Administración de claves, seleccione Generar nueva clave.
Elija una ID de clave no utilizada, como backup01. Utilice una combinación corta de letras y números en inglés, no más de caracteres 10, sin comas. El límite real es 10 UTF-8 bytes; Los caracteres que no son ASCII pueden utilizar más de un byte cada uno.
Elija RSA 2048 o RSA 4096. RSA 2048 es el valor predeterminado. Se muestran las opciones de ECDSA, pero el flujo de trabajo actual de SSH no las admite; Elija RSA para SSH.
Agregue un comentario o alias si es útil. Active Exportable solo si necesita realizar una copia de seguridad o migrar la clave privada. No hay ningún control de página para cambiar esta opción más adelante.
Establezca Oculto si es necesario, luego seleccione Generar. Esta opción afecta la visualización de la lista; no mantiene en secreto el ID de la clave real.
Compruebe el resultado: una vez finalizado, la ventana se cierra y la lista se actualiza. Busque el ID deseado y el tipo de RSA, luego abra la clave pública. Compruebe que el texto completo comience por ssh-rsa.
Mientras espera: no vuelva a enviar la solicitud. Cerrar la ventana no cancela la generación en el dispositivo.
Mensaje o situación
Qué hacer
El ID ya está en uso
Elija otra ID. El flujo de trabajo de clave nueva ahora rechaza las identificaciones existentes en lugar de sobrescribir sus claves.
Se ha alcanzado el límite de recuento de claves.
Se pueden guardar hasta ocho claves SSH. Antes de retirar una clave que ya no use, revoque su acceso siguiendo el procedimiento.
El almacenamiento o la memoria son insuficientes
Resuelva el problema de recursos del dispositivo antes de volver a intentarlo. No trates el fracaso como una creación exitosa.
Se generó la clave, pero la lista no se pudo actualizar
Actualice manualmente y verifique la clave; no lo vuelvas a generar La generación
La generación no está confirmada
Es posible que el dispositivo aún esté funcionando. Espere y verifique el registro; no vuelva a enviar la misma identificación La limpieza de
La limpieza no se completó
Verifique el almacenamiento del dispositivo, involucre a un administrador si es necesario y detenga la creación de claves adicionales
Encontrar un registro con el mismo ID solo prueba que existe un registro. Si el resultado no está confirmado, verifique que sea la clave deseada antes de considerar la operación como completa.
El despliegue añade la clave pública a ~/.ssh/authorized_keys de la cuenta remota. Esa cuenta podrá aceptar la clave privada correspondiente. La contraseña del servidor no cambia.
Seleccione Implementar en la fila de la clave deseada.
Ingrese la dirección del servidor, el nombre de usuario, el puerto SSH y la contraseña de inicio de sesión de SSH.
Revise la dirección y la cuenta, luego seleccione Iniciar implementación.
Lea el resultado y verifique el registro correspondiente en Hosts implementados.
Se implementó la clave, se registró el host y se verificó el inicio de sesión con clave pública
Verifique los detalles del host y luego pruebe la tarea real que necesita ejecutar
Se implementó la clave y se registró el host, pero el inicio de sesión no está confirmado
Seleccione Prueba. Si falla, verifique la autorización remota y la configuración de la cuenta a través de otra conexión de administración
La clave se implementó, pero el registro falló o no está confirmado
Verifique la lista local y la autorización remota antes de implementar nuevamente
Implementación completada, pero la lista no se pudo actualizar
Actualizar manualmente. Una actualización fallida de la lista no significa que la clave remota no se haya instalado
No implementar repetidamente porque el resultado está incompleto. Cada implementación agrega la clave y puede crear entradas duplicadas. Utilice otra conexión de administración para inspeccionar authorized_keys cuando necesite confirmar el resultado remoto.
En Hosts implementados, verifique la dirección, el puerto, el nombre de usuario y la ID de clave, luego seleccione Probar.
Si aparece una confirmación de la huella digital del Host, obtenga y compare una huella digital confiable como se describe en la Sección 4.3 antes de elegir Confiar y conectar.
Después de conectarse, el dispositivo intenta el comando de eco fijo echo "TianshanOS SSH Test OK".
Qué significa éxito: la página de prueba aún verifica si la solicitud se realizó correctamente, no el estado de salida o la salida del comando remoto. Úselo como verificación de conexión básica. Para una tarea importante, verifique la salida real, el estado de salida y los permisos. Esta prueba tampoco establece que sudo u otros comandos de la aplicación funcionarán.
Si falla: verifique la conectividad, el servicio SSH, la cuenta y la autorización remota de clave pública. Deje de volver a intentarlo si la huella digital cambia o la identidad del servidor es incierta.
Confirme que otra conexión de administración del servidor funcione y que la clave original permanezca en el dispositivo.
Seleccione Revocar en la fila del host, ingrese la contraseña del servidor y confirme Revocar y eliminar. También puede comenzar desde la fila de claves e ingresar los detalles del objetivo.
Lea el resultado, luego use una conexión confiable para verificar que la clave pública y cualquier duplicado desaparezcan de authorized_keys. Confirme que la clave anterior ya no funciona.
La revocación deja una copia de seguridad authorized_keys.bak. Gestiónela según la política de copias de seguridad del servidor para evitar restaurar una autorización antigua.
Compruebe que se haya eliminado el registro del host local. La página ahora verifica esta solicitud. Si la revocación remota tuvo éxito pero la eliminación local falló, actualice y realice la limpieza local por separado.
Solo después de que se haya manejado cada servidor de destino se debe eliminar la clave antigua y las copias de clave privada innecesarias.
Si no se encuentra ninguna clave pública coincidente: confirme que la cuenta sea correcta y que la clave no esté en el servidor antes de elegir eliminar solo el registro local.
Si no se puede eliminar el host: es posible que un servicio esté usando o protegiendo el registro. Verifique el estado del servicio y las referencias en Comandos SSH o las configuraciones de automatización relevantes. Termina de detener el servicio o de resolver sus referencias antes de volver a intentarlo. Pídale a un administrador que verifique un estado incierto.
Si la revocación informa un error: identifique qué paso falló. Es posible que la clave remota ya haya desaparecido aunque haya fallado la limpieza local. Utilice la autorización del servidor y una verificación de inicio de sesión real para establecer el resultado remoto. Conserve la clave local hasta que esto se resuelva.
Clave pública: seleccione Clave pública y copie el valor completo de una sola línea para el administrador del servidor. Este es material público; enviarlo a la persona equivocada no expone la clave privada. El acceso se otorga cuando un administrador lo agrega a la lista de autorización de una cuenta.
Clave privada: la exportación está disponible solo si se habilitó Exportable durante la creación. Seleccione Clave privada en una computadora confiable y una red de administración aislada. Guárdelo en un almacén secreto aprobado, borre el portapapeles temporal y descargue copias. Nunca lo pegues en chats, tickets o registros.
Si Copiar no hace nada: los navegadores pueden restringir el acceso al portapapeles en una página HTTP. Seleccione y copie el texto manualmente, luego verifique sus marcadores de límites y su integridad. No debilite la configuración de seguridad del navegador para permitir la copia.
Intenta eliminar la autorización del servidor; requiere la contraseña remota
Eliminar un host
Elimina un registro de conexión local sin revocar el acceso al servidor
Eliminar una clave
Elimina el material de claves local sin contactar al servidor ni revocar el acceso.
Eliminar una huella digital del host
Elimina un registro de identidad del servidor guardado, no su registro de conexión o autorización remota Los hosts implementados de
«Hosts con claves desplegadas» es una lista local; no muestra en directo las autorizaciones del servidor. Que esté vacía no confirma que se haya retirado el acceso. Que un host aparezca tampoco garantiza que pueda conectarse a él.
Una huella digital identifica el servidor al que se está conectando. Esta página almacena un resumen SHA-256 como caracteres hexadecimales 64. Las herramientas OpenSSH suelen mostrar SHA256:base64. Solicite al administrador el mismo formato antes de comparar; las cadenas no se pueden comparar directamente.
Después de la implementación inicial: seleccione Ver en Huellas digitales de host conocidas y compare el valor total con uno obtenido de una consola de servidor, inventario de activos u otro canal confiable. La tabla muestra solo los primeros caracteres 32, lo que no es suficiente para una verificación completa.
Cuando la prueba solicita confirmación: el cuadro de diálogo muestra la huella digital completa actual. Verifíquelo de forma independiente antes de seleccionar Confiar y conectar. Si ha cambiado, verifique también la identidad del servidor, IP, puerto y registro de mantenimiento. No lo apruebe simplemente porque apareció el cuadro de diálogo.
Si la huella digital difiere o su origen no está claro: cancele la conexión e investigue. Si anteriormente utilizó una contraseña en una conexión que no es de confianza, trátela como potencialmente expuesta. Cámbielo a través de una conexión confiable, revise los registros de inicio de sesión y elimine la autorización no deseada. No envíe una contraseña a través de la conexión sospechosa para revocar el acceso.
Después de una reconstrucción autorizada o un cambio de clave de host: verifique primero la nueva huella digital completa y el registro de mantenimiento. Una vez verificado, acéptelo en el cuadro de diálogo de confirmación de prueba. Alternativamente, elimine la entrada anterior, pruebe nuevamente y confirme la huella digital verificada. La ruta de prueba ahora requiere confirmación explícita; No asuma que la reconexión confiará automáticamente en la nueva clave.
Proteja la tarjeta SD: las huellas digitales del host conocido se sincronizan con el texto sin formato JSON en la tarjeta. Al inicio, las configuraciones de huellas digitales SD disponibles reemplazan los registros locales correspondientes. Estos archivos no están firmados; no permita cambios que no sean de confianza en ellos.
Este flujo de trabajo dedicado .tscfg almacena la dirección, el puerto, el nombre de usuario, el tipo de autenticación y la ID de clave. No contiene contraseña SSH ni clave privada y no otorga acceso remoto. Está separada de la solicitud general inacabada del Capítulo 6.
Para exportar: en un dispositivo Developer, seleccione Exportar en la fila del host. Para otro dispositivo, proporcione y verifique su certificado, genere el paquete y seleccione Descargar. Compruebe que el archivo se haya guardado. Un dispositivo normal puede mostrar el control, pero se rechaza su solicitud de exportación.
Para importar:
Confirme que el paquete se creó para este dispositivo, que se puede escribir en la tarjeta SD y que la fuente se ha verificado a través de un canal confiable.
Asegúrese de que este dispositivo tenga la clave de referencia correcta. Una identificación coincidente por sí sola no es suficiente; el material clave debe coincidir con la autorización del servidor.
Seleccione Importar host, elija el archivo y revise la vista previa. Habilite la sobrescritura solo cuando desee reemplazar una configuración con el mismo nombre.
Confirme y reinicie según se le solicite. La importación primero guarda el paquete en la tarjeta SD; La carga y el descifrado se intentan al reiniciar.
Permita que finalice la carga de inicio, actualice la lista de hosts, verifique la dirección, la cuenta, el puerto y la clave, luego pruebe.
Que la vista previa se complete no confirma que el firmante sea de confianza ni que el paquete esté destinado a este dispositivo. La huella del destinatario se comprueba al cargarlo. Al iniciar, se combinan las configuraciones de host y se conservan los registros locales ajenos al paquete. Importar un paquete no borra toda la lista anterior.
Elimine un registro incorrecto y verifique que se haya borrado su configuración SD correspondiente. Un paquete restante se puede cargar nuevamente después del reinicio. Resolver referencias de servicios si el registro está en uso. Lea también la sección 5.6 antes de reemplazar el certificado del dispositivo.
El servicio actual en el puerto 443 proporciona puntos finales de prueba de permisos, identidad y estado, no la interfaz web completa. El inicio predeterminado requiere una clave de dispositivo, un certificado de dispositivo, una cadena de CA de cliente y un reloj de dispositivo válido.
El certificado del dispositivo y la clave privada permiten que el dispositivo demuestre su identidad a los clientes.
Un certificado de cliente y clave privada, mantenidos por una computadora o servicio, permiten al cliente probar su identidad en el dispositivo.
La CA de verificación del cliente en el dispositivo valida los certificados del cliente. No hace que una computadora o un navegador confíen automáticamente en el certificado del dispositivo.
Esta autenticación bidireccional se llama TLS mutua o mTLS. Los clientes aún deben confiar en la CA emisora del certificado del dispositivo y verificar su nombre de acceso, usos permitidos y validez.
Guardado, Dentro del período de validez y HTTPS: En ejecución describen el almacenamiento, la validez del tiempo y la operación del servicio por separado. Uno no establece los demás.
Estado o situación
Qué hacer
Falta el certificado del dispositivo, la clave privada o la CA de verificación del cliente
Instale las credenciales que faltan utilizando las siguientes secciones
Esperando la hora del dispositivo
Verifique que el reloj de su computadora sea correcto, luego seleccione Establecer la hora del dispositivo desde esta computadora (fuente del navegador)
Aún no válido o caducado
Verifique el reloj del dispositivo y las fechas del certificado; concertar la renovación si ha caducado
Dentro del período de validez, pero HTTPS no se está ejecutando
Lea el error de inicio, falta de coincidencia de clave o credencial que se muestra; resolverlo y actualizar
El servicio en ejecución todavía usa credenciales anteriores
Guarde otros trabajos y reinicie el dispositivo. Confirme que las nuevas credenciales cumplan con los requisitos de inicio y estén en uso
El almacenamiento o el estado no están confirmados
Actualizar y comprobar. Reinicie si se le indica; evitar la instalación o eliminación repetida
Después de configurar la hora, verifique la hora del dispositivo que se muestra y el estado de sincronización. Cuando el servicio no se está ejecutando, el sistema intenta iniciarse una vez que se cumplen los requisitos de tiempo y credenciales. Si permanece detenido, investigue el motivo que se muestra en lugar de tratar la instalación como prueba de que está lista.
Seleccione Generar par de claves. Esto crea una clave privada ECDSA P-256 separada, no relacionada con las claves SSH. No se puede exportar a través de esta interfaz.
Si ya existe una clave, lea primero la sección 5.6. El procedimiento lo sobrescribe.
Seleccione Generar CSR. Ingrese el ID del dispositivo (CN), la organización y el departamento, o deje todos los campos en blanco. El departamento corresponde a la unidad organizativa (OU) del certificado.
Seleccione Generar solicitud de firma de certificado y envíe el texto CSR completo a su administrador de CA.
Utilice una ID de dispositivo breve y estable. Las letras y números en inglés son más fáciles de mantener dentro del límite UTF-8 de 63 bytes. Los caracteres que no son ASCII pueden utilizar varios bytes. Acorte los campos si la interfaz informa un error de longitud.
Verifique los nombres antes de la emisión: la ruta del campo personalizado no genera un SAN. Con todos los campos en blanco, CN se fija en TIANSHAN-DEVICE-001; la IP actual se agrega como IP SAN solo si está disponible. No se agrega ningún SAN DNS. Haga que el administrador de la CA utilice un proceso de emisión controlado para incluir los nombres reales de IP o DNS y los propósitos de autenticación requeridos en el certificado final. Este formulario no puede editar SAN.
Una CSR no contiene ninguna clave privada y no instala un certificado. Haga que el administrador de la CA inspeccione su clave pública, asunto y SAN antes de la emisión.
Obtenga un certificado PEM que coincida con la clave privada del dispositivo actual.
Seleccione Instalar certificado, pegue el texto completo, incluidos sus marcadores de límites, y seleccione Instalar.
Verifique el resultado guardado, la validez del certificado y el estado real de HTTPS. Revise el tema, el emisor y las fechas.
La instalación comprueba el formato y el par de claves. El estado también informa de la vigencia y de lo necesario para iniciar el servicio. Los clientes deben verificar la cadena de confianza, el nombre usado para conectarse y los usos permitidos.
Si la clave no coincide, busque el certificado emitido para el CSR actual. No vuelva a generar una clave privada para eliminar el error. Si el resultado no está confirmado, actualice y verifique lo que se guardó antes de decidir si desea volver a intentarlo.
Seleccione Instalar CA, pegue uno o más certificados de CA PEM utilizados para confiar en sus clientes y seleccione Instalar.
Verifique el estado. Un servicio detenido intentará iniciarse cuando las credenciales y la hora estén listas. Si un servicio en ejecución informa cambios de credenciales, reinicie según las instrucciones para aplicarlas.
Acceda a los puntos finales de prueba adecuados utilizando un certificado de cliente confiable con el propósito y la función correctos.
Repita con un certificado que no sea de confianza o sin certificado y confirme el rechazo.
Compruebe el resultado: HTTPS se está ejecutando y utiliza el certificado previsto. Si se muestra el certificado activo SHA-256, compare su huella digital. Los clientes confiables deben acceder solo a los puntos finales que sus roles permitan; Los clientes que no son de confianza no deben conectarse. Verifique estos resultados en el dispositivo real.
Caducidad del certificado: reutilice una clave no comprometida para solicitar un nuevo certificado, instálelo, siga las instrucciones de estado para aplicarlo y vuelva a realizar la prueba. Los paquetes de configuración están vinculados a la huella digital del certificado del destinatario. Incluso con la misma clave, un paquete antiguo puede rechazarse después de la reinicialización o reinicio porque el certificado ha cambiado. Organice paquetes de reemplazo de antemano.
Reemplazo de clave privada: la CSR y el certificado antiguos ya no coinciden con la nueva clave. Esto no revoca el certificado antiguo en la CA. Maneje una clave expuesta con el administrador de CA por separado. Los paquetes que dependen de una clave perdida pueden ser irrecuperables.
Eliminar todas las credenciales: Eliminar credenciales elimina la clave del dispositivo, el certificado del dispositivo y la cadena de CA del cliente juntos. Verifique que el acceso de administración HTTP funcione y organice primero los paquetes de reemplazo. Una copia de seguridad de un certificado público no puede restaurar una clave privada.
Después de la eliminación, verifique que no haya certificado de dispositivo y que falten credenciales. Es posible que un servicio HTTPS en ejecución aún contenga las credenciales anteriores; La eliminación de los datos almacenados no constituye una revocación inmediata. Reinicie según las instrucciones y confirme que las credenciales antiguas ya no se utilizan. Restaure el servicio con una nueva clave, un certificado de dispositivo emitido, una cadena de CA del cliente y pruebas de conexión.
A Config Pack es un paquete .tscfg cifrado y firmado. Actualmente se pueden crear e inspeccionar paquetes, pero la aplicación de configuración general no está terminada. No confíe en él para la configuración de la flota de producción, la recuperación ante desastres o las comprobaciones de aceptación de cambios en la configuración.
Resultado actual Certificado de dispositivo de exportación
Exportar certificado del dispositivo
Proporciona el certificado público para que un remitente pueda crear un paquete para este dispositivo; no exporta su clave privada
Verificar solo
Comprueba la estructura y la firma del texto cifrado con el certificado incluido; no establece la confianza del firmante ni la identidad del destinatario
Importar después de seleccionar o pegar un paquete
Los parámetros de la página y los del dispositivo todavía no coinciden. Este procedimiento no puede completarse.
Importar desde la lista de paquetes
Valida un archivo de dispositivo existente sin copiarlo, descifrarlo ni aplicarlo
Aplicar
Descifra y enumera los nombres de los módulos sin escribir su configuración; todavía puede reportar éxito
Exportar Config Pack en un dispositivo Developer
Crea un paquete descargable e intenta guardarlo en la tarjeta SD.
La verificación utiliza el certificado del firmante incluido en el paquete, pero no establece la confianza de su cadena de certificados. La firma cubre el texto cifrado; no dé por autenticados todos los campos mostrados. Una etiqueta «Official» no demuestra que el origen sea fiable.
Utilice un sistema de activos o un canal confiable independiente para confirmar la huella digital del firmante, el certificado del dispositivo de destino y el propósito del paquete. El nombre de destino de la vista previa no reemplaza la verificación de huellas digitales del certificado. Recibir un certificado y una huella digital en el mismo mensaje no es una verificación independiente.
Para proporcionar el certificado de este dispositivo: seleccione Exportar certificado de dispositivo y copie el PEM completo y la huella digital que se muestra. Envía el certificado público al remitente y confirma su huella digital a través de otro canal confiable.
Para inspeccionar un paquete recibido: abra Importar Config Pack, seleccione o pegue el archivo .tscfg, luego seleccione Verificar únicamente. Revise los detalles del firmante y confirme la fuente. La verificación no aplica la configuración ni prueba que este dispositivo sea el destinatario. Deténgase si la fuente, el objetivo o el propósito no están claros.
Incluso después de pasar la verificación, no se puede confiar en los controles generales actuales de Importar y Aplicar para configurar el dispositivo. Utilice los controles compatibles en las páginas de funciones relevantes y verifique la configuración resultante.
Prepare archivos de configuración JSON válidos en la tarjeta SD y obtenga un certificado de destino verificado.
Seleccione Exportar Config Pack, elija archivos, ingrese un nombre y una descripción y pegue el certificado del dispositivo del destinatario.
Genere el paquete, seleccione Descargar y verifique que el navegador haya guardado el archivo .tscfg.
Verifique la descarga y el archivo en /sdcard/output_config/ por separado. El paquete puede permanecer disponible para su descarga incluso si falla la escritura en SD.
Exportar no modifica los ajustes de origen. Genere de nuevo un paquete si se creó para otro destinatario o si cambió el certificado del destinatario. Una exportación correcta no confirma que la aplicación general funcione en el dispositivo receptor.
Restringir el acceso al dispositivo y al material afectado; mantener los registros necesarios para la investigación.
Para una clave privada SSH expuesta, revoque su clave pública en cada servidor afectado a través de conexiones confiables. Verifique las copias de seguridad y confirme que la clave anterior ya no funciona.
Cree e implemente una nueva clave RSA con una nueva ID. Verifíquelo, luego elimine la clave anterior y las copias exportadas.
Para una contraseña SSH expuesta, cámbiela a través de una conexión de administración confiable y revise los registros de inicio de sesión.
Para una clave HTTPS expuesta, reemplace las credenciales como se describe en la sección 5.6 y trabaje con el administrador de CA en la revocación y los paquetes antiguos.
Es posible que la lista de hosts locales no cubra todos los servidores que otorgaron acceso; También verifique los registros del servidor y de los activos. Antes de compartir registros, revíselos en busca de contraseñas, claves u otro contenido confidencial ingresado por los usuarios.
Tenga en cuenta la gestión por HTTP, las limitaciones de autorización centralizada, la confianza automática en el primer despliegue y las limitaciones de Config Pack. «Oculto» no controla el acceso.
La configuración de compilación revisada no habilita el cifrado NVS, el cifrado Flash ni el arranque seguro. No asuma que esto protege las claves almacenadas o la integridad del inicio. La configuración del firmware actualizado y la configuración de seguridad del hardware requieren comprobaciones por separado. Solicite al propietario de la seguridad que disponga un aislamiento o una solución si el entorno previsto no puede tolerar estos límites.
Esta guía se basa en el código y las interfaces en chino e inglés de TianShanOS 0.6.1, revisados el 9 de octubre de 2026. Puede seguir consultándola en versiones posteriores para las funciones que no hayan cambiado. Si los controles, pasos o mensajes difieren, revise las notas de su versión antes de continuar.
La revisión cubrió el código fuente y una interfaz simulada local. La simulación no se trató como una prueba de aceptación del hardware. Verifique el acceso a SSH, los protocolos de enlace TLS, los reinicios y la autorización remota en su propio entorno como se describe aquí.
Clave pública/clave privada: comparte la clave pública con el administrador que otorga acceso; mantener la clave privada en secreto. La autenticación utiliza el par coincidente.
Huella digital: un resumen utilizado para comparar identidades de servidores o certificados. Convierta diferentes formatos de visualización antes de comparar.
CSR/CA: una solicitud de firma de certificado y una autoridad de certificación o su certificado.
CN/O/OU: nombre común, organización y unidad organizativa en un asunto de certificado. El departamento en forma corresponde a OU.
SAN / EKU: los nombres de acceso o direcciones IP que cubre un certificado y sus propósitos de autenticación permitidos.
PEM: un formato de texto con marcadores de INICIO/FIN para certificados, CSR y claves.
mTLS / PKI: autenticación de certificados mutuos y el sistema de gestión de confianza y certificados.
NVS: un área de almacenamiento Flash para configuraciones y claves del dispositivo; su nombre no implica cifrado.
Ce guide décrit les fonctionnalités et l'interface de TianShanOS 0.6.1. Cela peut rester utile pour les versions ultérieures où ces fonctionnalités restent inchangées. Un numéro de version différent ne rend pas automatiquement le guide obsolète. Si l'interface, les étapes ou les messages de résultat diffèrent, consultez les notes de version de votre version installée avant de continuer.
Utilisez ce guide pour modifier les mots de passe des appareils, configurer l'accès à SSH, vérifier les identités des serveurs et gérer les certificats. Pour une première configuration, commencez par les chapitres 1, 2 et 3. Les procédures de certificat et Config Pack sont destinées aux administrateurs responsables de ces fonctionnalités.
admin peut ouvrir la sécurité et voir les clés, les hôtes, les certificats et les contrôles Config Pack, mais pas la sécurité du compte.
root peut également définir les mots de passe root et admin ou réinitialiser admin à son mot de passe par défaut. Ces opérations de gestion des mots de passe vérifient l'autorisation root.
Un appareil Developer est identifié par l'unité organisationnelle (UO) dans son certificat d'appareil. Il s'agit d'une identité d'appareil. Seuls ces appareils peuvent actuellement exporter des packs de configuration et des configurations d'hôte SSH ; la connexion en tant que root ne le change pas.
Un bouton visible n'établit pas que son API applique les autorisations d'accès. Outre les opérations telles que la gestion des mots de passe qui vérifient elles-mêmes l'autorisation, l'accès doit actuellement être limité via un réseau de gestion de confiance.
Vérifiez que l'adresse IP du navigateur appartient à l'appareil prévu et que votre ordinateur se trouve sur un réseau de gestion de confiance.
Confirmez l'adresse, le port et le nom d'utilisateur SSH auprès de l'administrateur du serveur.
Le déploiement ou la révocation d'une clé publique via la page nécessite le mot de passe du compte distant et l'authentification par mot de passe. L'administrateur du serveur décide s'il doit laisser l'authentification par mot de passe activée par la suite.
Avant de révoquer l'accès, de supprimer des clés ou de remplacer des certificats, assurez-vous qu'une autre connexion de gestion fonctionne : une console serveur, une autre clé d'administrateur ou l'interface HTTP de l'appareil.
Si un compte est toujours marqué comme ayant un mot de passe inchangé, une invite de changement de mot de passe apparaît après la connexion. Définissez un mot de passe long et unique. Choisir de le modifier ultérieurement rejette l'invite sans modifier le mot de passe.
L'invite n'est pas un écran de paramètres de compte que vous pouvez rouvrir à tout moment. Si admin a déjà modifié son mot de passe et nécessite une autre modification, root peut le définir depuis la sécurité.
Connectez-vous en tant que root et ouvrez Sécurité dans la barre de navigation.
Recherchez les contrôles de mot de passe root ou admin sous Sécurité du compte. Remplissez le nouveau mot de passe et sa confirmation.
Sélectionnez Définir le mot de passe root ou Définir le mot de passe admin. L'interface accepte les caractères 4-64 ; quatre caractères est un minimum technique. Utilisez un mot de passe long et unique.
Vérifiez le résultat : connectez-vous avec le nouveau mot de passe dans une fenêtre de navigation privée avant de vous déconnecter de la session d'origine. La définition d'un nouveau mot de passe ne met pas automatiquement fin aux sessions existantes.
Si la connexion échoue : vérifiez d'abord le compte et l'adresse de l'appareil. Cinq tentatives consécutives infructueuses déclenchent un verrouillage d'environ cinq minutes. Évitez les suppositions répétées.
Root peut sélectionner Réinitialiser admin par défaut pour restaurer le mot de passe sur rm01 et effacer le verrouillage de connexion. Connectez-vous en tant que admin dans une nouvelle session et définissez un mot de passe unique immédiatement après.
Pour la configuration initiale, créez une clé RSA, déployez sa clé publique, examinez le résultat et testez la connexion. Vérifiez l'empreinte du serveur dans le cadre de ce processus. Lorsque vous retirez une clé, révoquez d'abord l'accès à chaque serveur, confirmez que l'ancienne clé ne fonctionne plus, puis supprimez-la seulement de l'appareil.
Dans Gestion des clés, sélectionnez Générer une nouvelle clé.
Choisissez un ID de clé inutilisé, tel que backup01. Utilisez une courte combinaison de lettres et de chiffres anglais, pas plus de caractères 10, sans virgules. La limite réelle est de 10 UTF-8 octets ; les caractères non-ASCII peuvent utiliser plus d'un octet chacun.
Choisissez RSA 2048 ou RSA 4096. RSA 2048 est la valeur par défaut. Les options ECDSA sont affichées, mais le flux de travail SSH actuel ne les prend pas en charge ; choisissez RSA pour SSH.
Ajoutez un commentaire ou un alias si utile. Activez Exportable uniquement si vous devez sauvegarder ou migrer la clé privée. Il n'existe aucun contrôle de page permettant de modifier cette option ultérieurement.
Définissez Masqué si nécessaire, puis sélectionnez Générer. Cette option affecte l'affichage de la liste ; il ne garde pas secret l’ID de clé réel.
Vérifiez le résultat : une fois terminé, la fenêtre se ferme et la liste s'actualise. Recherchez l'ID et le type RSA souhaités, puis ouvrez la clé publique. Vérifiez que le texte complet commence par ssh-rsa.
Pendant l’attente : ne renvoyez pas la demande. Fermer la fenêtre n’annule pas la génération sur l’appareil.
Message ou situation
Que faire
L'ID est déjà utilisé
Choisissez un autre ID. Le workflow de création de nouvelles clés rejette désormais les identifiants existants plutôt que d'écraser leurs clés.
La limite du nombre de clés a été atteinte
Vous pouvez enregistrer jusqu’à huit clés SSH. Avant de retirer une clé inutilisée, suivez la procédure de révocation de son accès.
Le stockage ou la mémoire est insuffisant
Résolvez le problème de ressources du périphérique avant de réessayer. Ne traitez pas l’échec comme une création réussie
La clé a été générée, mais la liste n'a pas pu être actualisée
Actualisez manuellement et vérifiez la clé ; ne le génère plus La génération
La génération n’est pas confirmée
L'appareil fonctionne peut-être encore. Attendez et vérifiez le dossier ; ne soumettez pas à nouveau le même identifiant Le nettoyage de
Le nettoyage n’est pas terminé
Vérifiez le stockage de l'appareil, impliquez un administrateur si nécessaire et suspendez la création de clés.
La recherche d'un enregistrement avec le même ID prouve uniquement qu'un enregistrement existe. Si le résultat n'est pas confirmé, vérifiez qu'il s'agit bien de la clé prévue avant de considérer l'opération comme terminée.
Le déploiement ajoute la clé publique au fichier ~/.ssh/authorized_keys du compte distant. Ce compte peut ensuite accepter la clé privée correspondante. Le mot de passe du serveur ne change pas.
Sélectionnez Déployer sur la ligne de la clé souhaitée.
Saisissez l'adresse du serveur, le nom d'utilisateur, le port SSH et le mot de passe de connexion SSH.
Vérifiez l'adresse et le compte, puis sélectionnez Démarrer le déploiement.
Lisez le résultat et vérifiez l'enregistrement correspondant sous Hôtes déployés.
La clé a été déployée, l'hôte enregistré et la connexion par clé publique vérifiée
Vérifiez les détails de l'hôte, puis testez la tâche réelle que vous devez exécuter
La clé a été déployée et l'hôte enregistré, mais la connexion n'est pas confirmée
Sélectionnez Test. En cas d'échec, vérifiez l'autorisation à distance et les paramètres du compte via une autre connexion de gestion.
La clé a été déployée, mais l'enregistrement a échoué ou n'est pas confirmé
Vérifiez la liste locale et l'autorisation à distance avant de procéder à un nouveau déploiement
Déploiement terminé, mais la liste n'a pas pu être actualisée
Actualiser manuellement. Un échec d'actualisation de la liste ne signifie pas que la clé distante n'a pas été installée
Ne déployez pas à plusieurs reprises car le résultat est incomplet. Chaque déploiement ajoute la clé et peut créer des entrées en double. Utilisez une autre connexion de gestion pour inspecter authorized_keys lorsque vous devez confirmer le résultat à distance.
Sous Hôtes déployés, vérifiez l'adresse, le port, le nom d'utilisateur et l'ID de clé, puis sélectionnez Test.
Si une confirmation d'empreinte de l'hôte apparaît, obtenez et comparez une empreinte fiable comme décrit dans la section 4.3 avant de choisir Confiance et connexion.
Après la connexion, l'appareil tente la commande d'écho fixe echo "TianshanOS SSH Test OK".
Ce que signifie le succès : la page de test vérifie toujours si la requête a réussi, et non l'état de sortie ou la sortie de la commande à distance. Utilisez-le comme vérification de connexion de base. Pour une tâche importante, vérifiez la sortie réelle, l’état de sortie et les autorisations. Ce test ne permet pas non plus d'établir que sudo ou d'autres commandes d'application fonctionneront.
En cas d'échec : vérifiez la connectivité, le service SSH, le compte et l'autorisation de clé publique à distance. Arrêtez de réessayer si l'empreinte change ou si l'identité du serveur est incertaine.
Confirmez qu'une autre connexion de gestion du serveur fonctionne et que la clé d'origine reste sur l'appareil.
Sélectionnez Révoquer sur la ligne de l'hôte, entrez le mot de passe du serveur et confirmez Révoquer et supprimer. Vous pouvez également partir de la ligne clé et saisir les détails de la cible.
Lisez le résultat, puis utilisez une connexion fiable pour vérifier que la clé publique et tous les doublons ont disparu de authorized_keys. Confirmez que l'ancienne clé ne fonctionne plus.
La révocation laisse une sauvegarde authorized_keys.bak. Gérez-la selon la politique de sauvegarde du serveur pour éviter de rétablir une ancienne autorisation.
Vérifiez que l'enregistrement de l'hôte local a été supprimé. La page vérifie maintenant cette demande. Si la révocation à distance a réussi mais que la suppression locale a échoué, actualisez et gérez le nettoyage local séparément.
Ce n'est qu'après la gestion de chaque serveur cible que vous devez supprimer l'ancienne clé et les copies de clé privée inutiles.
Si aucune clé publique correspondante n'est trouvée : confirmez que le compte est correct et que la clé est absente sur le serveur avant de choisir de supprimer uniquement l'enregistrement local.
Si l'hôte ne peut pas être supprimé : il se peut qu'un service utilise ou protège l'enregistrement. Vérifiez l'état du service et les références sous Commandes SSH ou les paramètres d'automatisation pertinents. Terminez d'arrêter le service ou de résoudre ses références avant de réessayer. Demandez à un administrateur de vérifier un état incertain.
Si la révocation signale un échec : identifiez quelle étape a échoué. La clé distante a peut-être déjà disparu même si le nettoyage local a échoué. Utilisez l'autorisation du serveur et une vérification de connexion réelle pour établir le résultat à distance. Conservez la clé locale jusqu'à ce que le problème soit résolu.
Clé publique : sélectionnez la clé publique et copiez la valeur complète sur une seule ligne pour l'administrateur du serveur. Il s'agit d'un matériel public ; l'envoyer à la mauvaise personne n'expose pas la clé privée. L'accès est accordé lorsqu'un administrateur l'ajoute à la liste d'autorisation d'un compte.
Clé privée : l'exportation est disponible uniquement si Exportable a été activé lors de la création. Sélectionnez Clé privée sur un ordinateur de confiance et un réseau de gestion isolé. Stockez-le dans un magasin secret approuvé, effacez le presse-papiers temporaire et téléchargez des copies. Ne le collez jamais dans le chat, les tickets ou les journaux.
Si Copier ne fait rien : les navigateurs peuvent restreindre l'accès au presse-papiers sur une page HTTP. Sélectionnez et copiez le texte manuellement, puis vérifiez ses limites et son exhaustivité. N'affaiblissez pas les paramètres de sécurité du navigateur pour permettre la copie.
Tentatives de suppression de l'autorisation du serveur ; nécessite le mot de passe distant
Supprimer un hôte
Supprime un enregistrement de connexion locale sans révoquer l'accès au serveur
Supprimer une clé
Supprime les éléments de clé locale sans contacter le serveur ni révoquer l'accès
Supprimer une empreinte d'hôte
Supprime un enregistrement d'identité de serveur enregistré, pas son enregistrement de connexion ou son autorisation à distance Les hôtes déployés
« Hôtes avec clé déployée » est une liste locale ; elle ne reflète pas en direct les autorisations du serveur. Une liste vide ne confirme pas la suppression de l’accès. La présence d’un hôte ne garantit pas non plus qu’il soit joignable.
Une empreinte identifie le serveur auquel vous vous connectez. Cette page stocke un résumé SHA-256 sous forme de caractères hexadécimaux 64. Les outils OpenSSH affichent généralement SHA256:base64. Demandez à l'administrateur le même format avant de comparer ; les chaînes ne peuvent pas être comparées directement.
Après le déploiement initial : sélectionnez Afficher sous Empreintes digitales d'hôte connues et comparez la valeur complète avec celle obtenue à partir d'une console de serveur, d'un inventaire d'actifs ou d'un autre canal approuvé. Le tableau ne montre que les premiers caractères 32, ce qui n'est pas suffisant pour une vérification complète.
Lorsque le test demande une confirmation : la boîte de dialogue affiche l'empreinte complète actuelle. Vérifiez-le indépendamment avant de sélectionner Faire confiance et se connecter. S'il a changé, vérifiez également l'identité du serveur, l'adresse IP, le port et l'enregistrement de maintenance. N'approuvez pas simplement parce que la boîte de dialogue est apparue.
Si l'empreinte diffère ou si sa source n'est pas claire : annulez la connexion et enquêtez. Si vous avez déjà utilisé un mot de passe sur une connexion non fiable, considérez-le comme potentiellement exposé. Modifiez-le via une connexion approuvée, examinez les journaux de connexion et supprimez les autorisations indésirables. N'envoyez pas de mot de passe via la connexion suspecte pour révoquer l'accès.
Après une reconstruction autorisée ou un changement de clé d'hôte : vérifiez d'abord la nouvelle empreinte complète et l'enregistrement de maintenance. Une fois vérifié, acceptez-le dans la boîte de dialogue Confirmation du test. Vous pouvez également supprimer l’ancienne entrée, tester à nouveau et confirmer l’empreinte vérifiée. Le chemin de test nécessite désormais une confirmation explicite ; ne supposez pas que la reconnexion fera automatiquement confiance à la nouvelle clé.
Protégez la carte SD : les empreintes de l'hôte connu sont synchronisées avec le texte en clair JSON sur la carte. Au démarrage, les configurations d'empreintes SD disponibles remplacent les enregistrements locaux correspondants. Ces fichiers ne sont pas signés ; n'autorisez pas les modifications non fiables.
Ce flux de travail .tscfg dédié stocke l'adresse, le port, le nom d'utilisateur, le type d'authentification et l'ID de clé. Il ne contient ni mot de passe SSH ni clé privée et n'accorde pas d'accès à distance. Il est distinct de l'application générale inachevée du chapitre 6.
Pour exporter : sur un appareil Developer, sélectionnez Exporter sur la ligne hôte. Pour un autre appareil, fournissez et vérifiez son certificat, générez le package et sélectionnez Télécharger. Vérifiez que le fichier a été enregistré. Un appareil ordinaire peut afficher le contrôle, mais sa demande d'exportation est rejetée.
Pour importer :
Confirmez que le package a été conçu pour cet appareil, que la carte SD est inscriptible et que la source a été vérifiée via un canal de confiance.
Assurez-vous que cet appareil dispose de la clé référencée correcte. Un identifiant correspondant à lui seul ne suffit pas ; le matériel de clé doit correspondre à l'autorisation du serveur.
Sélectionnez Importer l'hôte, choisissez le fichier et examinez l'aperçu. Activez le remplacement uniquement lorsque vous avez l'intention de remplacer une configuration portant le même nom.
Confirmez et redémarrez lorsque vous y êtes invité. L'importation enregistre d'abord le package sur la carte SD ; le chargement et le décryptage sont tentés au redémarrage.
Autorisez le chargement au démarrage, actualisez la liste des hôtes, vérifiez l'adresse, le compte, le port et la clé, puis testez.
Une prévisualisation réussie ne confirme ni la confiance du signataire ni que ce paquet est destiné à cet appareil. L’empreinte du destinataire est vérifiée au chargement. Au démarrage, les configurations d’hôtes sont fusionnées et les autres enregistrements locaux sont conservés. Importer un paquet ne supprime pas toute la liste précédente.
Supprimez un enregistrement incorrect et vérifiez que sa configuration SD correspondante a été effacée. Un package restant peut se charger à nouveau après le redémarrage. Résolvez les références de service si l’enregistrement est en cours d’utilisation. Lisez également la section 5.6 avant de remplacer le certificat de l'appareil.
Le service actuel sur le port 443 fournit des points de terminaison de test d'intégrité, d'identité et d'autorisation, et non l'interface Web complète. Le démarrage par défaut nécessite une clé de périphérique, un certificat de périphérique, une chaîne d'autorité de certification client et une horloge de périphérique valide.
Le certificat d'appareil et la clé privée permettent à l'appareil de prouver son identité aux clients.
Un certificat client et une clé privée, détenus par un ordinateur ou un service, permettent au client de prouver son identité à l'appareil.
L'autorité de certification de vérification client sur l'appareil valide les certificats clients. Cela n’oblige pas automatiquement un ordinateur ou un navigateur à faire confiance au certificat de l’appareil.
Cette authentification bidirectionnelle est appelée TLS mutuel, ou mTLS. Les clients doivent toujours faire confiance à l'autorité de certification émettrice du certificat de périphérique et vérifier son nom d'accès, ses utilisations autorisées et sa validité.
Enregistré, Pendant la période de validité et HTTPS : En cours d'exécution décrivent séparément le stockage, la validité temporelle et le fonctionnement du service. L'un n'établit pas les autres.
Statut ou situation
Que faire
Le certificat de périphérique, la clé privée ou l'autorité de certification de vérification du client sont manquants
Installez les informations d'identification manquantes à l'aide des sections suivantes
En attente de l'heure de l'appareil
Vérifiez que l'horloge de votre ordinateur est correcte, puis sélectionnez Définir l'heure de l'appareil à partir de cet ordinateur (source du navigateur)
Pas encore valide ou expiré
Vérifiez l'horloge de l'appareil et les dates du certificat ; organiser le renouvellement s'il a expiré
Pendant la période de validité, mais HTTPS n'est pas en cours d'exécution
Lire l'erreur d'informations d'identification manquantes, de clé incompatible ou de démarrage affichée ; résolvez-le et actualisez
Le service en cours d'exécution utilise toujours les informations d'identification précédentes
Enregistrez d'autres travaux et redémarrez l'appareil. Confirmez que les nouvelles informations d'identification répondent aux exigences de démarrage et sont en cours d'utilisation
Le stockage ou l'état n'est pas confirmé
Actualiser et vérifier. Redémarrez si vous y êtes invité ; éviter les installations ou suppressions répétées
Après avoir réglé l'heure, vérifiez l'heure affichée de l'appareil et l'état de synchronisation. Lorsque le service n'est pas en cours d'exécution, le système tente de démarrer une fois que les exigences d'identification et de temps sont remplies. S'il reste arrêté, recherchez la raison affichée plutôt que de considérer l'installation comme une preuve qu'elle est prête.
Sélectionnez Générer une paire de clés. Cela crée une clé privée ECDSA P-256 distincte, sans rapport avec les clés SSH. Il ne peut pas être exporté via cette interface.
Si une clé existe déjà, lisez d'abord la section 5.6. Continuer l'écrase.
Sélectionnez Générer CSR. Saisissez l'ID de l'appareil (CN), l'organisation et le service, ou laissez tous les champs vides. Le département correspond à l'unité organisationnelle (UO) du certificat.
Sélectionnez Générer une demande de signature de certificat et envoyez le texte CSR complet à votre administrateur d'autorité de certification.
Utilisez un identifiant d'appareil court et stable. Les lettres et chiffres anglais sont plus faciles à conserver dans la limite UTF-8 d'octets 63. Les caractères non-ASCII peuvent utiliser plusieurs octets. Raccourcissez les champs si l'interface signale une erreur de longueur.
Vérifiez les noms avant l'émission : le chemin du champ personnalisé ne génère pas de SAN. Avec tous les champs vides, CN est fixé à TIANSHAN-DEVICE-001 ; l'adresse IP actuelle est ajoutée en tant que SAN IP uniquement si elle est disponible. Aucun SAN DNS n’est ajouté. Demandez à l'administrateur de l'autorité de certification d'utiliser un processus d'émission contrôlé pour inclure les noms IP ou DNS réels et les objectifs d'authentification requis dans le certificat final. Ce formulaire ne peut pas modifier les SAN.
Un CSR ne contient aucune clé privée et n'installe pas de certificat. Demandez à l'administrateur de l'autorité de certification d'inspecter sa clé publique, son sujet et son SAN avant son émission.
Obtenez un certificat PEM qui correspond à la clé privée actuelle de l'appareil.
Sélectionnez Installer le certificat, collez le texte complet, y compris ses limites, puis sélectionnez Installer.
Vérifiez le résultat enregistré, la validité du certificat et l'état actuel du HTTPS. Vérifiez le sujet, l'émetteur et les dates.
L’installation vérifie le format et la paire de clés. L’état indique aussi la validité dans le temps et les conditions de démarrage. Les clients doivent vérifier la chaîne de confiance, le nom utilisé pour la connexion et les usages autorisés.
Si la clé ne correspond pas, recherchez le certificat émis pour la CSR actuelle. Ne régénérez pas une clé privée pour effacer l’erreur. Si le résultat n'est pas confirmé, actualisez et vérifiez ce qui a été enregistré avant de décider de réessayer.
Sélectionnez Installer l'autorité de certification, collez un ou plusieurs certificats d'autorité de certification PEM utilisés pour approuver vos clients, puis sélectionnez Installer.
Vérifiez l'état. Un service arrêté tentera de démarrer lorsque les informations d'identification et l'heure seront prêtes. Si un service en cours d'exécution signale des informations d'identification modifiées, redémarrez comme indiqué pour les appliquer.
Accédez aux points de terminaison de test appropriés à l'aide d'un certificat client approuvé avec l'objectif et le rôle corrects.
Répétez l'opération avec un certificat non fiable ou sans certificat, puis confirmez le rejet.
Vérifiez le résultat : HTTPS est en cours d'exécution et utilise le certificat prévu. Si le certificat actif SHA-256 s'affiche, comparez son empreinte. Les clients de confiance doivent accéder uniquement aux points de terminaison autorisés par leurs rôles ; les clients non fiables ne doivent pas se connecter. Vérifiez ces résultats sur l’appareil réel.
Expiration du certificat : réutilisez une clé non compromise pour demander un nouveau certificat, installez-le, suivez les instructions d'état pour l'appliquer et testez à nouveau. Les packs de configuration sont liés à l’empreinte du certificat du destinataire. Même avec la même clé, un ancien package peut être rejeté après réinitialisation ou redémarrage car le certificat a changé. Organisez à l’avance des colis de remplacement.
Remplacement de clé privée : l'ancienne CSR et le certificat ne correspondent plus à la nouvelle clé. Cela ne révoque pas l'ancien certificat auprès de l'autorité de certification. Gérez séparément une clé exposée avec l’administrateur de l’autorité de certification. Les packages qui dépendent d'une clé perdue peuvent être irrécupérables.
Supprimer toutes les informations d'identification : Supprimer les informations d'identification supprime ensemble la clé de périphérique, le certificat de périphérique et la chaîne d'autorité de certification client. Vérifiez que l'accès à la gestion HTTP fonctionne et organisez d'abord les packages de remplacement. Une sauvegarde de certificat public ne peut pas restaurer une clé privée.
Après la suppression, recherchez Aucun certificat de périphérique et les informations d'identification manquantes. Un service HTTPS en cours d'exécution peut toujours conserver les informations d'identification précédentes ; la suppression des données stockées ne constitue pas une révocation immédiate. Redémarrez comme indiqué et confirmez que les anciennes informations d'identification ne sont plus utilisées. Restaurez le service avec une nouvelle clé, un certificat de périphérique émis, une chaîne d'autorité de certification client et des tests de connexion.
Un Config Pack est un package .tscfg crypté et signé. Les packages peuvent actuellement être créés et inspectés, mais l'application de configuration générale n'est pas terminée. Ne comptez pas sur lui pour la configuration du parc de production, la reprise après sinistre ou les vérifications d'acceptation des modifications des paramètres.
Résultat actuel Certificat de périphérique d'exportation
Exporter le certificat de l’appareil
Fournit le certificat public afin qu'un expéditeur puisse créer un package pour cet appareil ; n'exporte pas sa clé privée
Vérifier uniquement
Vérifie la structure et la signature chiffrée par rapport au certificat inclus ; n'établit pas la confiance du signataire ni l'identité du destinataire
Importer après avoir sélectionné ou collé un package Les paramètres frontend et backend
Les paramètres de la page et ceux de l’appareil ne correspondent pas encore. Cette procédure ne peut pas aboutir.
Importer depuis la liste des packages
Valide un fichier de périphérique existant sans le copier, le déchiffrer ou l'appliquer
Appliquer
Déchiffre et répertorie les noms de modules sans écrire leurs paramètres ; peut encore signaler un succès
Exporter Config Pack sur un appareil Developer
Crée un package téléchargeable et tente de l'enregistrer sur la carte SD
La vérification utilise le certificat du signataire inclus dans le paquet, sans établir la confiance de sa chaîne de certificats. La signature couvre le texte chiffré ; ne considérez pas tous les champs affichés comme authentifiés. Une étiquette « Official » ne prouve pas que l’origine est fiable.
Utilisez un système d'actifs ou un canal de confiance indépendant pour confirmer l'empreinte du signataire, le certificat du périphérique cible et l'objectif du package. Le nom cible de l’aperçu ne remplace pas une vérification des empreintes du certificat. Recevoir un certificat et une empreinte dans le même message ne constitue pas une vérification indépendante.
Pour fournir le certificat de cet appareil : sélectionnez Exporter le certificat de l'appareil et copiez le PEM complet et l'empreinte affichée. Envoyez le certificat public à l'expéditeur et confirmez son empreinte via un autre canal de confiance.
Pour inspecter un colis reçu : ouvrez Importer Config Pack, sélectionnez ou collez le fichier .tscfg, puis sélectionnez Vérifier uniquement. Vérifiez les détails du signataire et confirmez la source. La vérification n'applique pas les paramètres et ne prouve pas que cet appareil est le destinataire. Arrêtez-vous si la source, la cible ou le but n'est pas clair.
Même une fois la vérification réussie, les contrôles généraux d'importation et d'application actuels ne peuvent pas être utilisés pour configurer le périphérique. Utilisez les contrôles pris en charge sur les pages de fonctionnalités pertinentes et vérifiez les paramètres résultants.
Préparez des fichiers de configuration JSON valides sur la carte SD et obtenez un certificat cible vérifié.
Sélectionnez Exporter Config Pack, choisissez les fichiers, entrez un nom et une description, puis collez le certificat de l'appareil destinataire.
Générez le package, sélectionnez Télécharger et vérifiez que le navigateur a enregistré le fichier .tscfg.
Vérifiez séparément le téléchargement et le fichier sous /sdcard/output_config/. Le package peut rester disponible au téléchargement même si l'écriture du SD échoue.
L’exportation ne modifie pas les réglages d’origine. Régénérez le paquet s’il a été créé pour un autre destinataire ou si son certificat a changé. Une exportation réussie ne confirme pas le fonctionnement de l’application générale sur l’appareil destinataire.
Restreindre l'accès à l'appareil et au matériel concerné ; conserver les dossiers nécessaires à l’enquête.
Pour une clé privée SSH exposée, révoquez sa clé publique sur chaque serveur concerné via des connexions approuvées. Vérifiez les sauvegardes et confirmez que l'ancienne clé ne fonctionne plus.
Créez et déployez une nouvelle clé RSA sous un nouvel ID. Vérifiez-le, puis supprimez l'ancienne clé et les copies exportées.
Pour un mot de passe SSH exposé, modifiez-le via une connexion de gestion approuvée et examinez les enregistrements de connexion.
Pour une clé HTTPS exposée, remplacez les informations d'identification comme décrit dans la section 5.6 et travaillez avec l'administrateur de l'autorité de certification sur la révocation et les anciens packages.
La liste d'hôtes locaux peut ne pas couvrir tous les serveurs ayant accordé l'accès ; vérifiez également les enregistrements du serveur et des actifs. Avant de partager des journaux, examinez-les pour rechercher les mots de passe, les clés ou tout autre contenu sensible saisi par les utilisateurs.
Tenez compte de la gestion en HTTP, de l’autorisation centralisée incomplète, de la confiance automatique au premier déploiement et des limites de Config Pack. « Masqué » ne contrôle pas l’accès.
La configuration de build révisée n'active pas le chiffrement NVS, le chiffrement Flash ou le démarrage sécurisé. Ne présumez pas que ceux-ci protègent les clés stockées ou l’intégrité du démarrage. La configuration du micrologiciel flashé et les paramètres de sécurité du matériel nécessitent des vérifications distinctes. Demandez au propriétaire de la sécurité d'organiser l'isolement ou un correctif si l'environnement prévu ne peut pas tolérer ces limites.
Ce guide repose sur le code et les interfaces chinoise et anglaise de TianShanOS 0.6.1, vérifiés le 9 octobre 2026. Il reste utile pour les fonctions inchangées des versions suivantes. Si les commandes, les étapes ou les messages diffèrent, consultez les notes de votre version avant de continuer.
L'examen portait sur le code source et une interface simulée locale. La simulation n'a pas été traitée comme un test d'acceptation sur le matériel. Vérifiez l'accès SSH, les négociations TLS, les redémarrages et l'autorisation à distance dans votre propre environnement, comme décrit ici.
Clé publique / clé privée : partagez la clé publique avec l'administrateur qui accorde l'accès ; garder la clé privée secrète. L'authentification utilise la paire correspondante.
Fingerprint : un résumé utilisé pour comparer les identités de serveur ou de certificat. Convertissez différents formats d’affichage avant de comparer.
CSR / CA : une demande de signature de certificat, et une autorité de certification ou son certificat.
CN / O / OU : nom commun, organisation et unité organisationnelle dans un sujet de certificat. Le département sous la forme correspond à l'UO.
SAN / EKU : les noms d'accès ou les adresses IP couverts par un certificat et ses objectifs d'authentification autorisés.
PEM : un format de texte avec des marqueurs BEGIN/END pour les certificats, les CSR et les clés.
mTLS / PKI : authentification mutuelle par certificat et système de gestion des certificats et de la confiance.
NVS : une zone de stockage Flash pour les paramètres et les clés de l'appareil ; son nom n'implique pas de cryptage.
