Establish the destination and authority first
SSH supports encrypted remote administration, and SFTP transfers files over SSH. A sound connection starts before the password prompt: identify the correct server, verify its host identity, use an approved account and know what that account may do.
This guide is for systems you own or are authorized to administer. Obtain the hostname, port, account name, approved authentication method and host-key fingerprint through your administrator’s trusted process. Also obtain the permitted destination directory and the service owner’s contact. A file-transfer account may deliberately have no interactive shell.
Use a supported client from your operating system or an official distribution. The OpenSSH ssh manual and sftp manual describe the reference tools. Check your installed client’s help and version because packaged versions and organizational settings vary. Keep client and server maintenance within the normal change process.
| Check | What it answers | Expected evidence |
|---|---|---|
| Host identity | Am I connecting to the intended server? | The offered host key matches a trusted fingerprint or approved host-certificate policy. |
| User authentication | Can I prove control of the approved account credential? | The server accepts the authorized method for that account. |
| Authorization | What may this account do after login? | Only required commands, directories and operations are available. |
Treat host-key prompts as decisions
On a first connection, a client may present the server’s host-key fingerprint. Compare the complete fingerprint with the value supplied through the trusted administrative route. Checking a value received through the same unverified connection provides little independent assurance.
A later host-key-change warning calls for investigation. Planned server replacement or key rotation can explain it; a mistaken address or an intercepted connection can also cause trouble. Pause and ask the owner to confirm the new identity through the approved route. Update the saved record only after resolving the reason. Do not bypass checking or erase saved keys merely to silence the warning.
The OpenSSH client-configuration manual documents StrictHostKeyChecking, known-hosts files and managed host-identity options. An administrator can distribute verified host records or a trusted host-certification policy. These controls make repeat connections predictable without teaching users to approve unknown keys automatically.
Make the first transfer small and reversible
Use an approved test directory and harmless content before transferring production files. Confirm whether the server permits overwrites, and choose a unique test filename that cannot replace something important.
- Connect using the approved client settings and complete the host-identity check.
- Confirm the remote account and directory. In an interactive OpenSSH SFTP session,
pwdshows the remote directory andlpwdshows the local directory. - Upload the harmless file with
put, using the approved remote destination. Read the completion or error message. - List the destination and download the uploaded file to a different local filename with
get. - Open the returned file and compare its bytes or cryptographic digest with the original. Ask the recipient to confirm the intended access and application behavior.
- Remove only the test artifacts you created when the owner agrees, then close the session with
bye.
If a transfer is interrupted, inspect the destination state before retrying. A partial file can be visible to downstream software. Agree on the service’s supported staging-and-release convention, rather than inventing a rename or resume process for a production application.
Maintain accounts, keys and service behavior
Public-key authentication uses a private key held by the client and a corresponding authorized public key on the server. Protect the private key using the approved device and passphrase or hardware-backed method. Give automation a specifically scoped identity with an owner; separate it from a human administrator’s daily account.
Keep an access record that links the user or job to the server, permissions, key identifier, owner and review date. When access ends, remove the applicable authorization and check related accounts or jobs. Removing one public key does not automatically end every existing session or disable other login methods; verify those separately.
Troubleshoot in order: destination and network reachability, host identity, authentication, then directory permissions. A permission error after login is different from a failed identity check. Share sanitized error details with the administrator while keeping private keys, passwords and sensitive filenames out of tickets.
For remote administration, know the approved recovery route before changing network or authentication settings. Use a documented maintenance window and verify that another authorized session can connect before ending the working one. Service continuity and access removal belong in the same operational plan as encryption.