Connecting to a Linux Server with SSH

Check the server address, authorised user, authentication method and network access before starting an SSH session.

Before you begin

You need permission to access the server, its address, an authorised account and the correct authentication method. Confirm the expected server identity with the administrator and keep private keys private. Port and user examples below are placeholders, not CloudLelo-issued credentials.

Work through the checklist

1. Confirm the endpoint. Obtain the hostname or address and SSH port from the administrator. Check that your network and the server’s access rules permit the connection.
2. Prepare authentication. Use the authorised account and the agreed password or key. Store a private key securely; do not upload it to a website enquiry or share it in ordinary email.
3. Connect from a terminal. For a typical account and default port, use ssh username@server.example. For a specified port use ssh -p 2222 username@server.example, substituting the real approved values.
4. Verify server identity. On an unfamiliar or changed host key, confirm the expected fingerprint through a trusted administrative channel before accepting it. A warning is a reason to investigate rather than blindly remove the old record.
5. Collect safe error detail. For failed access, record the exact error, time, network and endpoint without including secrets. Ask the administrator to check authorised access and server availability.

Connection is not an administrative change

This example establishes a session only. It does not configure accounts, firewall rules or server software. Once connected, follow your organisation’s change approvals. Distribution and server configuration affect the available commands and privileges.

Example and limits

Example only: ssh -p 2222 username@server.example. The hostname is illustrative, port 2222 is not a supplied default, and username must be replaced by the account authorised for your environment.

Document the next action

Record the decisions, the person authorised to approve changes and the evidence used to validate the result. Keep passwords, private keys and confidential business data out of planning notes shared through an initial enquiry. Revisit the record when the application, access requirements or commercial agreement changes.

Primary references

• OpenSSH client manual