DEV Community

Bobo Yang
Bobo Yang

Posted on

New to Linux Operations? Install DeepSeek Harness on a Remote Host Over SSH

#ai #linux #devops #tutorial

If you can SSH into a Linux host but do not yet know which commands are safe, a remote agent can help collect evidence on the machine itself. The important part is keeping changes behind a human approval boundary.

Disclosure: I’m affiliated with KeySync, the remote-access product used in this tutorial.

For someone new to operations, the most stressful moment after an alert may not be the red error message. It may be the first few minutes after SSH login.

You know something is wrong, but you do not know whether to inspect disk usage, processes, ports, or logs first. Search results offer dozens of commands, yet it is not obvious which ones only inspect state and which ones delete files, restart services, or modify configuration.

Copying a few log lines into a web chat does not fully solve the problem either. The AI cannot see the host’s actual environment, so it asks for another command and another fragment of output. You return to SSH and run a command you may not completely understand.

This tutorial has one narrow goal: use SSH to install the KeySync CLI and DeepSeek Harness (DSH) on an Ubuntu host. Afterward, you can find that host in KeySync, open its DSH instance remotely, ask the agent to begin with read-only checks, inspect the evidence, and decide whether any change should be made.

This workflow does not make unsafe operations impossible, and it does not replace your organization’s change-management process. It gives a new operator a more structured way to investigate before acting.

What you will have at the end

The workflow is:

  1. Install the KeySync CLI and DeepSeek Harness over SSH.
  2. Find the online Linux device in KeySync.
  3. Select Remote Open to enter the DSH instance running on that host.
  4. Describe the problem in natural language and request inspection only.
  5. Review the commands, evidence, and conclusions.
  6. Keep deletion, restart, upgrade, and configuration changes behind human approval.

KeySync provides the path to the selected machine. DSH performs the investigation inside that machine’s real environment.

KeySync device list with the Remote DSH entry

Test environment and limits

This walkthrough was tested with:

  • Ubuntu 22.04.5 on x86-64
  • A normal SSH user, without root installation
  • KeySync CLI 0.1.123
  • Node.js 24.18.0
  • DeepSeek Harness 0.1.1-rc.2
  • About 9.7 GiB free on the root filesystem before installation

The test machine had Ubuntu Desktop components installed, but the procedure used no Linux GUI and the SSH session had no desktop environment variables. This demonstrates a CLI-only installation, not a pristine minimal Ubuntu Server image.

Do not copy the procedure unchanged to ARM64, another distribution, or a production server. Validate it in a non-production environment or ask an experienced administrator to review it first.

The commands below use Bash syntax. Run echo "$SHELL" to check your shell. If it is not Bash, ask an administrator how to switch or adapt the commands.

Know what will change before you copy a command

  • System, Node.js, and disk checks are read-only.
  • Downloading and extracting KeySync writes only to a temporary directory and the current user’s home directory.
  • keysync login stores login state for the current user and registers the device.
  • keysync service install creates a user-level systemd service, not a system service.
  • keysync dsh install downloads and installs DeepSeek Harness.
  • keysync dsh remote enable enables the Remote DSH channel for this device.

This tutorial does not ask you to run sudo rm, docker system prune, format a disk, or modify production configuration. If your output differs from the examples, stop instead of trying more commands at random.

Step 1: Perform read-only preflight checks

These commands do not modify the system:

uname -m
. /etc/os-release && printf '%s %s\n' "$NAME" "$VERSION_ID"
node --version
df -h /
Enter fullscreen mode Exit fullscreen mode

They answer four questions: Is the machine x86-64? Which Linux distribution is running? Which Node.js does the current shell use? How much space remains on the root filesystem?

My test host returned:

x86_64
Ubuntu 22.04
v12.22.9
about 9.7 GiB free on /
Enter fullscreen mode Exit fullscreen mode

The first real issue appeared immediately: Node.js 12 could not run the current KeySync CLI. The current Linux CLI requires Node.js 24 or newer on PATH.

The test host already had Node.js 24.18.0 in NVM, so I selected it:

export PATH="$HOME/.nvm/versions/node/v24.18.0/bin:$HOME/.local/bin:$PATH"
node --version
# v24.18.0
Enter fullscreen mode Exit fullscreen mode

That NVM path belongs to this test host; it is not a universal location. If node --version already reports 24 or newer, do not add it. If Node.js is installed elsewhere, use the real path on your host.

If the version is still below 24, stop here. Do not run a blind apt upgrade just to continue the tutorial. Use your organization’s approved Node.js installation method or ask an administrator to install Node.js 24.

Step 2: Download the KeySync CLI

On September 3, 2026, the current Linux x64 release was 0.1.123:

tmp_dir=$(mktemp -d /tmp/keysync-install.XXXXXX)
curl -fsSL \
  'https://keysync.sublang.ai/keysync-updates/cli-linux-x64/keysync-cli-0.1.123-linux-x64.tar.gz' \
  -o "$tmp_dir/keysync.tar.gz"
stat -c '%s bytes' "$tmp_dir/keysync.tar.gz"
Enter fullscreen mode Exit fullscreen mode

The tested file size was:

33124893 bytes
Enter fullscreen mode Exit fullscreen mode

If curl fails or the size differs, do not extract the archive. Read the current public release manifest instead of guessing a download URL:

https://keysync.sublang.ai/keysync-updates/latest.json
Enter fullscreen mode Exit fullscreen mode

Step 3: Verify the archive

SHA-512 is the archive’s digital fingerprint. The calculated value must match the value in the release manifest.

expected='IdEI49Z7d4rtyFwE6XqMCapDBSo9Us2PwAg+ocK2Mkchu4wrVcF/ExaMzFzfEu5OvcOK4Nu3d3xMl6O3knhJpQ=='
actual=$(node -e "const fs=require('fs'),c=require('crypto');const p=process.argv[1];console.log(c.createHash('sha512').update(fs.readFileSync(p)).digest('base64'))" "$tmp_dir/keysync.tar.gz")
test "$actual" = "$expected" && echo 'SHA-512 OK' || echo 'Verification failed; stop the installation'
Enter fullscreen mode Exit fullscreen mode

Continue only after seeing:

SHA-512 OK
Enter fullscreen mode Exit fullscreen mode

If verification fails, do not edit expected to force a match. Confirm that the version, URL, and digest came from the same current manifest entry.

Step 4: Install into your home directory

These commands create files under the current user’s home directory and do not overwrite /usr/bin:

mkdir -p "$HOME/.local/share/keysync/cli" "$HOME/.local/bin"
tar -xzf "$tmp_dir/keysync.tar.gz" -C "$HOME/.local/share/keysync/cli"
ln -s \
  "$HOME/.local/share/keysync/cli/keysync-cli-0.1.123-linux-x64/keysync" \
  "$HOME/.local/bin/keysync"
export PATH="$HOME/.nvm/versions/node/v24.18.0/bin:$HOME/.local/bin:$PATH"
keysync --version
Enter fullscreen mode Exit fullscreen mode

Expected output:

0.1.123
Enter fullscreen mode Exit fullscreen mode

If ln reports that the destination already exists, the machine may already have KeySync installed. Inspect it instead of overwriting it:

ls -l "$HOME/.local/bin/keysync"
keysync --version
Enter fullscreen mode Exit fullscreen mode

Step 5: Log in without writing passwords into shell history

Do not place your real email address and passwords directly in command-line arguments. They may remain in shell history. The CLI can read them from environment variables populated through hidden prompts:

read -rp 'KeySync email: ' KEYSYNC_EMAIL
read -srp 'KeySync login password: ' KEYSYNC_PASSWORD; echo
read -srp 'KeySync Vault password: ' KEYSYNC_VAULT_PASSWORD; echo
export KEYSYNC_EMAIL KEYSYNC_PASSWORD KEYSYNC_VAULT_PASSWORD
keysync login
unset KEYSYNC_EMAIL KEYSYNC_PASSWORD KEYSYNC_VAULT_PASSWORD
keysync status
Enter fullscreen mode Exit fullscreen mode

Run this only in your own private SSH session. If login fails, clear the variables with the unset command before checking the account, password, and network.

Step 6: Run KeySync as a user-level systemd service 

keysync service install
keysync service status
systemctl --user is-enabled keysync.service
systemctl --user is-active keysync.service
Enter fullscreen mode Exit fullscreen mode

The tested result was:

enabled
active
Enter fullscreen mode Exit fullscreen mode

No sudo is used here. If someone suggests adding it after an unexpected error, stop and determine why first.

If the installer reports user lingering is disabled, the service may run only while that user has an active login session. It may not be online after a reboot before the user logs in. Do not enable linger or add sudo without approval; ask an administrator to apply the organization’s policy, then test again after logging out or rebooting the test host.

Step 7: Install DeepSeek Harness 

keysync dsh install
keysync dsh start
keysync dsh remote enable
keysync dsh status
Enter fullscreen mode Exit fullscreen mode

A clean reinstall took about 118 seconds in this test. A quiet period does not necessarily mean failure, so do not start a second concurrent installation.

The successful state was:

DeepSeek Harness: running
Version: 0.1.1-rc.2
Remote access: connected
Enter fullscreen mode Exit fullscreen mode

On the test host, DSH listened only on 127.0.0.1:3080; port 3080 was not exposed on every network interface.

If you do not plan to use remote access yet, omit keysync dsh remote enable and enable it later.

Step 8: Open the host and send a safe first instruction

On another computer, open KeySync, select the online Linux host, and choose Remote Open next to DeepSeek Harness.

Do not begin with “fix it.” Start with an explicit diagnostic boundary:

Perform read-only checks only. Do not delete or move files, install or upgrade software, modify configuration, terminate processes, or start, stop, or restart services. First explain what you plan to inspect. Then run only the read-only commands required. Finally, list every command executed, the important output, the evidence behind your conclusion, remaining uncertainty, and any next action that requires my approval.

I used a similar instruction to investigate a Node.js version problem. DSH checked Node.js, PATH, and the launcher on the target host, reproduced the syntax error under Node.js 12, and verified that the same CLI worked under Node.js 24.

Remote DSH performing the read-only Node.js diagnosis

Natural-language “read-only” instructions are not an operating-system sandbox. Important production systems still need low-privilege accounts, restricted sudo, and explicit approval for deletion, restart, and configuration changes.

Common failure modes

keysync: command not found

Make sure the current shell includes the installation directory:

export PATH="$HOME/.nvm/versions/node/v24.18.0/bin:$HOME/.local/bin:$PATH"
keysync --version
Enter fullscreen mode Exit fullscreen mode

SyntaxError: Unexpected token '.'

The test host produced this when it was still using Node.js 12:

which node
node --version
Enter fullscreen mode Exit fullscreen mode

Verify the executable actually selected by the shell, not merely that Node.js 24 exists somewhere on the machine.

Could not resolve host

Confirm that the URL comes from the current latest.json, then inspect DNS. Do not disable certificate checking or use an untrusted mirror.

Remote access: disabled

If you intend to enable remote access:

keysync dsh remote enable
keysync dsh status
Enter fullscreen mode Exit fullscreen mode

The state may briefly show reconnecting before becoming connected.

The installer is quiet for a long time

The tested reinstall took about 118 seconds. First wait and confirm that only one installation process is running. If it exceeds a reasonable time, save the error information and ask a colleague or an AI assistant to help interpret it.

Final verification

Run:

keysync --version
systemctl --user is-active keysync.service
keysync dsh status
ss -ltnp | grep '127.0.0.1:3080'
Enter fullscreen mode Exit fullscreen mode

Then verify all four outcomes:

  • KeySync returns an explicit version.
  • The user-level service is active.
  • DSH is running and Remote is connected.
  • You can open the real DSH instance from KeySync and complete one read-only investigation.

What you now have is not an AI that should be allowed to change a server freely. It is a diagnostic partner that can remain on the target Linux host and collect evidence continuously.

For a new operator, the goal is not merely to memorize fewer commands. It is to know how to inspect first, when to stop, and which decisions must remain with a human.

Try the workflow

Version note: tested on September 3, 2026. KeySync and DeepSeek Harness evolve quickly, so read the current public release manifest before installation. This tutorial is for learning and non-production validation; it does not replace your organization’s access-control or change-management procedures.

Top comments (0)