An SSH workflow without constantly switching tools

You need to check an application on a staging server. The job involves a shell, a few files and a web interface that should stay off the public internet.

Here is a small workflow for doing that in Zync: connect to the host, inspect the application directory, then create a local SSH port forward. Terminal, Files and Port Forwarding are separate views within the app. You switch between those views, but you do not need a separate SSH or SFTP client for each step.

What you need

Use a staging machine or disposable test environment you are authorized to access. You need an SSH account, its password or private key, and permission to use the files and service in this example. The server must provide SFTP for file browsing and permit SSH local port forwarding.

The example uses staging.example.com, a remote directory at /srv/example-app, and an HTTP service listening on the server’s loopback port 8080. These are placeholders. Substitute your own permitted host, directory and service.

Save a connection you can recognize

Create a new connection in Zync. Give it a name such as Example app staging, then enter the hostname, SSH port and username. Select the authentication method your server supports.

Use your existing private-key file or the account’s password, depending on what the server accepts. If you already keep hosts in an SSH config, importing supported entries may save some typing. Review the imported hostname, username, port and key path before connecting.

Test the connection before saving. If the app presents a host-key warning, verify the fingerprint through a trusted channel before accepting it. A familiar display name is not proof of the server’s identity.

Confirm where the terminal is running

Open the saved host and inspect the session before making changes. On a typical Linux server, these commands are a useful starting point:

hostname
pwd
whoami

Check that the machine and account match your intended environment. Then navigate to the application directory:

cd /srv/example-app && ls -la

The listing runs only if changing directory succeeds. If the directory is missing or access is denied, confirm the path and account before continuing.

Browse files for the same host

Switch from the terminal to Files for the same host and navigate to /srv/example-app. Browse the directory and open a text file in the built-in editor without moving to a separate SFTP client.

Switch back to the terminal when you need to run a command. You can also use Open Terminal Here from the file browser to open a shell at the directory you are viewing. Terminal and Files remain separate views for the same host.

For this walkthrough, inspect a non-sensitive file rather than changing configuration. If you do make an edit, confirm the path and keep a backup before saving.

Reach the internal web interface

Suppose the application is already listening on 127.0.0.1:8080 on the remote server. Open the host’s Port Forwarding view, select New Forward, and choose Local Forward. Enter:

The destination is reached from the SSH server, so its 127.0.0.1 refers to the remote machine. The local bind address refers to your own computer. OpenSSH’s local-forward documentation explains that distinction.

Click Start Forwarding to save the configuration. If the saved forward is stopped, use its start control while the SSH connection is active. Once it is running, visit http://127.0.0.1:38080 in your browser. You should see the remote service’s page, such as its login screen. Keep any authentication required by the application; a tunnel does not replace it.

If the forward cannot start because 38080 is occupied, choose another local port and use that port in the browser URL. If it starts but the page cannot be reached, check that the service is listening on the remote machine at port 8080, and that the SSH server permits forwarding.

Keeping the bind address at 127.0.0.1 limits the listener to your own computer. This is local access through SSH, not a public web link.

Finish deliberately

Stop the forward when you are done. It depends on the host’s active SSH connection; a saved forwarding configuration is not an always-running service.

The useful part of this workflow is the context you keep. The connection name, shell, files and forwarding configuration all belong to the same task. Start with that small loop, then add other tools only when they help you understand the system.