Command line and advanced management

Preparation and safe checks

The 0.2.18 Windows ZIP includes tastessh-cli.exe and alias tssh.exe. On other operating systems, check distribution contents and execute permissions. Prepare the terminal and server/file access permissions. sample-server, example.invalid and demo below are documentation examples: replace them with authorized targets of your own.

tastessh-cli --version
tastessh-cli --help
tastessh-cli connect --help

Command-line help governs positional arguments and options. Global --data-file specifies a separate Vault JSON path; do not point it at the wrong real data file. --debug output can include paths/connection information: review before publication. Never put passwords, private keys or tokens in command lines, shell history or example files.

Hosts, groups and vaults

1. Inspect current data with hosts, groups and vaults.
2. Create a host with host-add and prepare authentication through password-set or host-auth/identity management.
3. Connect with connect. Use --accept-new only for a new server key matching the administrator-verified fingerprint. Never bypass changed-key errors by unconditional trust.
4. Check remote work state and end the session when finished.

tastessh-cli host-add sample-server example.invalid --username demo
tastessh-cli password-set sample-server
tastessh-cli connect sample-server

The expected result is a saved listing and connected terminal. On failure, inspect the selected data file, authentication, host key, firewall and server policy.

Startup commands can run immediately after connection; test against safe targets before registering them on production servers. Check each command's --help for removing inheritance/defaults and replacement options. Deleting vaults/hosts is not the same as deleting server files.

Identities and secrets

Slash-separated set/delete denotes separate commands; check help for actual executable names. Public-key installation can alter server authentication such as authorized_keys. Check permissions, target and preservation of existing data before running. Removing secrets requires OS-store access; check effects on other hosts too.

Connection types

• connect: options for SSH connection, authentication, PTY and command execution.
• mosh: starts through SSH, then uses Mosh client/server and UDP. Check client/server Mosh installation, UDP firewall policy and options such as prediction. Successful SSH alone does not establish Mosh readiness.
• telnet: plaintext connection requiring explicit --confirm-plaintext confirmation. Do not send credentials/business data; use only approved isolated equipment. It does not provide SSH-like encryption.
• serial-ports/serial: port enumeration and device communication settings. Check actual device settings, permissions and occupancy first.
• local: runs a local shell. Check installed shells, working folder and arguments.
• forward: uses <HOST> <KIND> plus bind/destination options to run local, remote or dynamic forwarding. Check destination and exposed bind scope, and stop afterward.

An advanced engine does not mean all commands have same-named desktop buttons.

SFTP commands

The form is tastessh-cli sftp <HOST> <COMMAND>. Prepare permissions, direction and current remote/local paths.

For get/put, --resumable creates recovery records; --resume specifies an existing token. Retain tokens, data files and destination paths and verify it is the same transfer. Do not always start new transfers or arbitrarily delete temporary leftovers on failure. Choose intended --overwrite or --keep-both behavior and check --verify-sha256. The expected result is completion plus target/hash verification; do not ignore exit codes.

Snippets, logs, synchronization and data migration

• snippets: list/add/show/edit/remove, render and package-list/add/edit/remove. Inspect rendered results and variable values first. Do not store secrets in bodies.
• logs: status/enable/disable/list/show/review/export/remove/clear. Check recording consent/retention policy, host/content and deletion scope. remove/clear can irreversibly remove data.
• sync: init/status/push/pull. Prepare the same target/passphrase and inspect status. Do not use overwrite-remote/local without confirmation.
• export: native/open-ssh/csv. Restrict output-file access because host data may be included. --overwrite can replace retained copies.
• import: native/open-ssh/csv/putty/putty-registry/moba-xterm/secure-crt/secure-crt-directory. Review external formats and sources. Check supported previews and --apply/--skip-existing, then decide duplicate/replacement policies. putty-registry depends on Windows. native --replace may replace existing data.
• diagnostics: status/configure/preview/send/flush. Distinguish report consent, previews, destination and automatic reporting. send/flush actually transmits data: review contents before running.

Expected results are the listings, exported files, application summaries and transfer states defined in help. On failure, preserve originals and check command help, exit codes, permissions and conflict guidance. Reading a command-name list does not constitute server connection or actual verification of every feature.