Connect to a server

3 minute read · SSH Terminal

Open a terminal on a server you control when your project needs remote work. A local project shell and an SSH session run on different machines; keep that distinction visible.

• Save and verify a host
• Handle host identity changes
• Use the terminal and agent tools deliberately
• Work in a terminal without losing context

Save and verify a host#

Create a host with a recognizable name, address, port and username. Choose password or key authentication. A key may come from a selected file, pasted content or a Vault reference, with a passphrase when required. Keep the secret in the connection form rather than in a conversation or public command example.

Connect in a session tab and inspect the connection state and logs. A connection attempt is not yet an authenticated shell. Confirm the expected server through a harmless identification step appropriate to your environment before issuing changes. Disconnect explicitly when the session is no longer needed.

Handle host identity changes#

Known-host fingerprints have a separate management surface. Compare a new or changed identity with a trusted source for the server. A changed fingerprint could be a legitimate rebuild, a wrong destination or an interception risk; blindly accepting it because a task is in Auto loses the value of the check.

When authentication fails, distinguish an unreachable host from a rejected username, key or passphrase. When a shell connects but a command is denied, inspect the account's remote permissions instead of replacing working credentials.

Use the terminal and agent tools deliberately#

Resize, search and scroll the session as needed. Font, cursor, scrollback and theme are terminal preferences; changing them does not change the host. Port forwarding, Laravel Tinker and database discovery operate through their specific supported workflows and should retain the same target awareness.

For agents, ssh_read_command is limited to strictly read-only inspection. ssh_exec_command handles mutating remote work with its declared confirmation boundary. Redirected or ambiguous shell text is not automatically read-only. Resource listing resolves useful IDs without returning passwords. Follow tunnels when a private service needs this host.

Work in a terminal without losing context#

Open the saved host in a session tab and verify the remote hostname and working directory before making changes. Resize, search and scroll the terminal to inspect output; disconnect or reconnect through the session controls. Font, cursor and scrollback preferences affect readability, not the remote command's permissions.

A local project shell runs on your computer in the project's checkout. An SSH terminal runs on the remote host. The same command can affect entirely different files in those two tabs. Use clear host names and keep the environment visible when asking an agent to inspect a service.

Start with bounded inspection such as checking one service's status and recent relevant output. Do not paste private keys or passwords into a conversation to make the connection work. A selected key file, Vault key or pasted key belongs in the saved host's protected authentication fields. Confirm host-key changes against a trusted server identity before reconnecting. Tunnels can reuse this saved host without exposing a private database port.

Related guides: tunnels, remote files.