How to SSH Into a Server: Beginner’s Guide

Connecting to a remote server can feel intimidating when you first see a terminal window and an unfamiliar command such as ssh user@server. In reality, the basic process is surprisingly simple. Once you know the server address, username, authentication method, and SSH port, you can securely access a remote system with a single command.

SSH, or Secure Shell, is a protocol used to securely access and manage computers over a network. Developers, system administrators, cloud engineers, website owners, cybersecurity professionals, and hosting customers commonly use SSH to manage Linux servers, cloud virtual machines, websites, databases, applications, and other remote systems.

Unlike older remote-access methods that could expose login information, SSH creates an encrypted connection between your computer and the remote server. That secure channel allows you to execute commands, manage files, install software, check logs, restart services, transfer data, and perform administrative tasks without physically sitting in front of the server.

This beginner’s guide explains how to SSH into a server from Windows, macOS, and Linux. You will learn the basic SSH command, password and key authentication, custom ports, server fingerprints, SSH configuration files, file transfers, common connection errors, and practical security habits that make remote server management safer.

What Is SSH and How Does It Work?

SSH stands for Secure Shell. It is a network protocol designed for secure remote login and other network services across potentially untrusted networks. When you connect to a remote server with SSH, your computer operates as the SSH client while the remote machine runs an SSH server service.

The client begins communication with the server, and both sides negotiate cryptographic settings for the connection. The client also checks the server’s identity using its host key, helping reduce the risk of unknowingly connecting to an impersonating system when host-key verification is handled correctly.

Next, the server authenticates you. Depending on its configuration, authentication may involve a password, an SSH key pair, a hardware-backed credential, a certificate, or another permitted authentication method. Successful authentication grants access according to the permissions assigned to your server account.

Once connected, your terminal communicates through an encrypted SSH session. Commands you type are sent securely to the remote system, and the server’s responses return through the same protected connection. SSH can also support file transfers, port forwarding, tunneling, and automated remote commands.

What Do You Need Before You SSH Into a Server?

First, you need the hostname or IP address of the server. An IP address might look like 203.0.113.25, while a hostname could look like server.example.com. Cloud providers and hosting companies normally provide this information when a server or virtual machine is created.

Second, you need a valid SSH username. Common usernames depend on the server configuration and operating system. Your hosting provider or system administrator should tell you which account to use rather than expecting you to guess the username.

You also need an authentication method. The server may allow password authentication, SSH key authentication, or both. Key-based authentication is commonly used for servers because the private key stays with the client while the corresponding public key is authorized on the remote account.

Finally, you need to know the SSH port if the server does not use the standard setting. SSH normally listens on TCP port 22, but administrators can configure another port. You will need to specify that custom port when connecting if the server has been configured differently.

The Basic SSH Command for Beginners

The basic SSH connection syntax is simple:

ssh username@server

Replace username with your account on the remote server and server with its hostname or IP address. For example:

ssh zeeshan@203.0.113.25

After running the command, SSH attempts to contact the server and authenticate the specified user. On your first connection, you will normally receive a message asking you to verify the remote server’s host-key fingerprint before continuing.

If the server accepts password authentication, you may then be prompted for your password. Characters generally do not appear while you type the password, which can make beginners think the keyboard is not working. Type it normally and press Enter when finished.

After successful authentication, your command prompt changes to the remote environment. Commands entered from that point are being executed on the server rather than your local computer, so pay attention before deleting files, installing packages, changing configurations, or restarting important services.

How to SSH Into a Server From Linux

Most modern Linux distributions include an OpenSSH client or make it readily available through their package manager. Open a terminal and first test whether the ssh command is available by entering:

ssh -V

If SSH is installed, the terminal displays information about the installed SSH client. You can then connect using the standard syntax. For example:

ssh admin@192.168.1.50

If the remote account uses password authentication, enter the password when prompted. For a key-based server, OpenSSH may automatically try suitable private keys stored in the .ssh directory or keys available through an authentication agent.

If the ssh command is unavailable, install an OpenSSH client using the package-management method appropriate for your Linux distribution. Once installed, the same SSH syntax generally works across distributions, which makes the command line convenient when managing servers from different Linux environments.

How to SSH Into a Server From macOS

macOS includes a command-line SSH client, so most users do not need to install a separate SSH program. Open Terminal, which you can find through Spotlight or the Applications utilities, and you can begin connecting directly.

Use the familiar command:

ssh username@hostname

For example:

ssh developer@server.example.com

You can also connect directly to an IP address. If your cloud server has the address 203.0.113.40 and your username is admin, enter ssh admin@203.0.113.40, verify the correct host fingerprint when required, and complete the configured authentication process.

macOS also stores common SSH information within the .ssh directory inside your home folder. As you begin using keys and configuration files, this directory can contain files such as private keys, public keys, known_hosts, and an optional config file that simplifies frequently used server connections.

How to SSH Into a Server From Windows

Modern Windows systems can use OpenSSH directly through PowerShell, Command Prompt, or Windows Terminal when the OpenSSH Client feature is installed. This means many users no longer need a separate graphical SSH application just to make ordinary command-line connections.

Open PowerShell or Windows Terminal and check whether SSH is available:

ssh -V

If the command returns OpenSSH version information, you are ready to connect. Use the same syntax you would use on Linux or macOS:

ssh username@server

For example, entering ssh admin@203.0.113.25 attempts to connect to that address as the admin user. If OpenSSH Client is missing, Windows provides it through its optional-feature capabilities, after which SSH can be used directly from the terminal.

What Happens the First Time You Connect With SSH?

When connecting to a server for the first time, SSH may display a message explaining that the authenticity of the host cannot yet be established. It then shows a host-key fingerprint and asks whether you want to continue connecting.

Do not treat this message as a meaningless formality. The fingerprint represents the server’s host key and provides a way to verify that you are connecting to the intended machine. Ideally, compare it with a fingerprint supplied through a trusted source such as your hosting provider or system administrator.

When you confirm a legitimate host, its host-key information is normally stored in your client’s known_hosts file. Future connections can then compare the server’s key with the stored information and warn you if something unexpected changes.

A changed host key does not automatically mean an attack has occurred. Servers may be rebuilt or SSH host keys may legitimately change. However, you should investigate an unexpected warning rather than blindly removing the old entry because host-key checking is an important protection against server impersonation.

How to SSH Into a Server With a Password

Password authentication is the easiest SSH method for beginners to understand. Run the normal connection command:

ssh username@server

If the server permits passwords, it asks you to enter the password associated with your remote user account. The terminal normally hides all password characters, including asterisks, so type carefully even though nothing appears on the screen.

If authentication succeeds, the remote shell opens. If you receive a Permission denied message, verify the username and password first. A correct password will still fail if the account is not allowed to use SSH or the server has disabled password authentication.

Passwords can be convenient for initial setup, but internet-accessible servers face automated login attempts constantly. Organizations therefore often prefer SSH keys or stronger centralized authentication mechanisms, particularly for administrative accounts and automated server management.

What Is SSH Key Authentication?

SSH key authentication uses a public key and a private key rather than relying only on a reusable account password. The public key is installed on the server, while the private key remains under your control on the computer or secure authentication device you use to connect.

During authentication, the SSH client proves that it controls the appropriate private key. The server checks whether the matching public key has been authorized for the requested user account. The private key itself does not need to be sent to the server during this process.

A common OpenSSH location for authorized user keys on Linux and Unix-like systems is:

~/.ssh/authorized_keys

Each permitted public key can be added to this file. When the corresponding private key is available to your SSH client, you can authenticate without typing the remote account password, although your private key itself may be protected by a passphrase.

Key-based authentication is particularly valuable for administrators, developers, automation tools, cloud servers, and environments where users connect repeatedly. It also makes it possible to disable ordinary password login in suitable server configurations, reducing exposure to password-guessing attacks.

How to Create an SSH Key

OpenSSH provides the ssh-keygen utility for generating authentication keys. A straightforward modern command is:

ssh-keygen -t ed25519

You will be asked where to save the key. Accepting the standard location commonly creates a private key such as ~/.ssh/id_ed25519 and a corresponding public key named ~/.ssh/id_ed25519.pub.

The utility can also ask you to create a passphrase. A strong passphrase protects the private key if someone gains access to the key file. An SSH agent can often remember the unlocked key during a session so you do not have to re-enter the passphrase for every connection.

Never send your private key to someone simply because they need to give you server access. Share the public key, not the private key. A file ending in .pub is intended to be distributed for authorization, whereas possession of your private key can allow someone to authenticate as you wherever that key is trusted.

How to Add Your SSH Public Key to a Server

Your public key needs to appear in the authorized-key configuration for the remote account. On many Unix-like systems, this means placing the contents of your .pub file into:

~/.ssh/authorized_keys

If password login is temporarily available, some systems provide the convenient ssh-copy-id utility:

ssh-copy-id username@server

This connects to the server and helps install the public key for the remote account. Afterward, test a new SSH session before disabling any existing authentication method so you do not accidentally lock yourself out of the server.

Cloud hosting platforms may handle the process differently. When creating a virtual machine, you may paste or select a public SSH key through the provider’s dashboard. The platform then places the appropriate public key on the instance during provisioning.

How to Connect Using a Specific SSH Private Key

Sometimes the private key you need is not stored under the default filename or you maintain different keys for different servers. Use the -i option to tell SSH which identity file should be used.

For example:

ssh -i ~/.ssh/myserver_key admin@203.0.113.25

On Windows, the path format may differ depending on whether you are using PowerShell, Command Prompt, Windows Terminal, WSL, or another environment. The underlying concept remains the same: -i points your SSH client toward the required private key.

Protect private-key file permissions carefully. On Unix-like systems, OpenSSH may refuse to use a private key if its permissions allow other users excessive access. Keeping private authentication material restricted to its owner prevents accidental disclosure.

How to SSH Using a Custom Port

SSH commonly uses port 22, but some servers listen on another TCP port. If your administrator tells you that SSH is available on port 2222, include the uppercase/lowercase-sensitive -p option:

ssh -p 2222 username@server

For example:

ssh -p 2222 admin@203.0.113.25

If you forget the custom port, the SSH client normally attempts the default port instead. That can produce a timeout or connection-refused error even when the username, password, IP address, and SSH service are otherwise correct.

Changing the default port should not be treated as a substitute for strong authentication, patching, firewall controls, and server hardening. It may reduce some noisy automated scanning, but the real security of an SSH service depends on much stronger controls.

How to Use an SSH Config File

Typing a long command containing a username, hostname, key path, and custom port becomes tedious when you manage the same server every day. OpenSSH supports client configuration files that allow you to create short aliases for frequently used systems.

A configuration entry might look like this:

Host production
HostName 203.0.113.25
User admin
Port 2222
IdentityFile ~/.ssh/production_key

After saving the configuration, instead of typing the complete connection details each time, you can simply run:

ssh production

SSH configuration files are especially helpful when you manage development, staging, production, database, and cloud servers simultaneously. Clear aliases also reduce the chance of accidentally running a command on the wrong machine because each server can have a memorable name and dedicated connection settings.

How to Run a Command Over SSH Without Opening a Shell

SSH does not require you to start an interactive remote terminal every time. You can provide a command after the server address and ask SSH to execute it remotely.

For example:

ssh admin@server.example.com uptime

The SSH client connects, authenticates, executes uptime on the remote server, displays the output locally, and then closes the session. This technique is useful for quick checks and automation.

Another example could be:

ssh admin@server.example.com "df -h"

That command can display remote disk usage without requiring you to manually log in first. Quoting becomes important when the remote command contains spaces, pipes, redirects, or other shell features.

Remote command execution can become powerful very quickly, particularly when combined with shell scripts and automation platforms. Make sure scripts use appropriately restricted accounts and keys rather than giving unattended automation unnecessary administrator privileges.

How to Copy Files With SCP Over SSH

SSH is not limited to terminal access. SCP, or Secure Copy, can transfer files using SSH-based authentication and encrypted communication.

A simple local-to-remote example is:

scp report.txt username@server:/home/username/

This sends report.txt from your current computer to the specified directory on the remote server. You can reverse the source and destination to download a file from the server.

If the SSH service is running on a custom port, SCP commonly uses an uppercase -P option for the port rather than the lowercase -p used by the ssh command. Always check the tool’s syntax when combining options to avoid simple command-line mistakes.

What Is SFTP and How Is It Related to SSH?

SFTP stands for SSH File Transfer Protocol and provides file-management capabilities over SSH. Despite the similar name, it should not be confused with traditional FTP plus encryption because SFTP is designed as an SSH subsystem.

You can commonly start an SFTP session using:

sftp username@server

After authentication, an interactive SFTP prompt allows commands for listing directories, uploading files, downloading files, creating directories, changing locations, and managing permitted remote files.

Many graphical file-transfer applications also support SFTP. This can be convenient for beginners who prefer dragging files between local and remote directories while still benefiting from SSH authentication and secure transport.

How to Exit an SSH Session

When you finish working on the remote system, leave the SSH session cleanly by typing:

exit

You can also commonly press Ctrl+D in a shell to signal the end of input and close the remote shell. After the connection closes, your terminal returns to the local command prompt.

Pay attention to which shell you are currently using before entering commands. Beginners sometimes forget that they remain connected to a production server and accidentally run a command remotely that they intended to execute on their laptop.

A helpful habit is to configure distinctive shell prompts or terminal profiles for important environments. Production systems can be given obvious hostnames or visual terminal distinctions so administrators are less likely to confuse them with development or local machines.

What Does “Connection Refused” Mean in SSH?

An SSH connection refused message generally means your computer reached the target host but could not establish a connection to the requested TCP port. The SSH service may not be running, the port may be wrong, or a firewall configuration may be rejecting the connection.

First, confirm the hostname or IP address and check which port the server actually uses. If you have administrator access through a hosting console, verify that the SSH server service is running and listening on the expected interface and port.

Next, review firewall and cloud security rules. A cloud virtual machine may have a correctly configured SSH service while a security group or network firewall blocks inbound traffic. Corporate networks may also restrict outbound connections to unusual ports.

Do not repeatedly change unrelated SSH settings in response to a connection-refused message. Separate the problem into layers: verify the address, test network reachability where appropriate, confirm the port, confirm the SSH service, and then investigate authentication only after the connection itself succeeds.

Why Does SSH Say “Connection Timed Out”?

A timeout means the client did not receive the expected network response within the allowed period. Unlike an immediate refusal, a timeout often indicates traffic is being silently filtered, routed incorrectly, sent to the wrong address, or blocked somewhere between client and server.

Check that the server’s public IP or hostname is correct. Cloud servers may receive new addresses after certain infrastructure changes unless a static address has been configured. DNS records can also point toward an outdated address if a migration was not completed correctly.

Review firewall rules on the server, cloud platform, router, and any corporate network involved. If SSH access is restricted to approved source IP addresses, connecting from a new internet connection or VPN may cause your traffic to be dropped.

You can also use verbose SSH output to understand where the client stops progressing. Run a connection with -v, -vv, or -vvv for increasingly detailed diagnostic information when troubleshooting difficult connectivity or authentication problems.

Why Does SSH Show “Permission Denied”?

Permission denied usually means that the SSH service was reachable but the server did not accept your authentication. This is an important distinction because network troubleshooting is unlikely to help once the client has already reached the authentication stage.

Confirm that your username is correct. The same server can have several accounts, and an SSH key authorized for one user will not automatically authenticate another user. Cloud images also frequently use predefined administrative usernames rather than whatever name exists on your local computer.

If you are using a password, make sure password authentication is permitted by the server. If you use an SSH key, verify that you selected the correct private key and that its matching public key appears in the correct remote account’s authorization configuration.

Verbose mode is useful here as well. Running ssh -v username@server can show which authentication methods and identities the client is attempting, helping you distinguish between a missing key, rejected key, incorrect account, unsupported method, or other authentication issue.

Why Do You Get an SSH Host Key Changed Warning?

SSH remembers server host keys so it can detect when a previously known server unexpectedly presents a different identity. If that happens, OpenSSH displays a prominent warning rather than silently accepting the change.

There are legitimate explanations. A server may have been rebuilt, reinstalled, migrated, or intentionally given new host keys. An IP address may also have been reassigned to a completely different server.

However, the warning can also indicate that communication is being intercepted or that you are connecting to a different machine than expected. For that reason, do not simply delete the existing known_hosts entry because an online tutorial told you to remove the warning.

Verify the new fingerprint through a trusted channel first. Once you confirm that the server legitimately changed, remove or update the old entry and reconnect. Host-key verification is a meaningful part of SSH security, not an inconvenience that should routinely be disabled.

SSH Security Best Practices for Beginners

Prefer SSH keys or another strong authentication approach for sensitive servers when practical. Protect private keys with appropriate permissions and consider using passphrases, authentication agents, hardware-backed keys, or centrally managed certificates when the environment requires stronger controls.

Avoid routinely logging directly into powerful administrator accounts when a lower-privileged user can perform ordinary tasks. Grant elevated privileges only when needed through the operating system’s appropriate administrative mechanisms. Limiting standing privileges reduces the consequences of an account compromise.

Keep the SSH server and operating system updated, remove unused accounts and keys, restrict network exposure where practical, and monitor authentication activity. Internet-accessible SSH services are regularly scanned, so forgotten accounts and old keys can become unnecessary risks.

Do not disable host-key checking simply to avoid warnings, and do not share private keys between people. Each administrator should ideally have individually attributable credentials so access can be removed for one person without disrupting everyone else who manages the server.

Password Authentication vs SSH Keys

Passwords are familiar and simple to distribute, which makes them convenient for beginners and temporary environments. Their weakness is that reusable passwords can be guessed, phished, reused, shared, or exposed through unrelated credential breaches if users practice poor password hygiene.

SSH keys use public-key authentication instead. The public part can be installed on the server without exposing the private authentication secret, and automated guessing of a user’s account password becomes irrelevant when password authentication is not accepted.

Key authentication still requires good management. Private keys can be stolen, forgotten keys can remain authorized after employees leave, and unprotected automation keys can become powerful attacker targets. Keys therefore require inventory, access control, rotation or replacement, and removal when they are no longer needed.

For small environments, carefully managed individual SSH keys offer a practical improvement over password-only administrative access. Larger organizations may eventually adopt SSH certificates, privileged-access management, hardware-backed credentials, or identity-aware access platforms to make server authentication easier to govern at scale.

Can You SSH Into a Server From Anywhere?

Technically, you can connect from anywhere if the network path permits access and the server accepts your authentication. Whether you should expose SSH publicly is a separate security and architecture decision.

Organizations often restrict SSH access using firewalls, VPNs, private networks, bastion hosts, zero-trust access systems, or allowlists. These controls can reduce unnecessary exposure by preventing arbitrary internet addresses from reaching administrative services.

Cloud environments frequently provide similar options through security groups or network firewall rules. Rather than allowing port 22 from the entire internet, administrators can limit access to known office addresses, VPN networks, management systems, or dedicated jump servers.

Remote access should balance convenience with risk. A developer working from several locations may need flexible access, but that requirement does not mean every production server must expose SSH directly to the entire internet.

SSH vs Telnet: Why SSH Is Preferred

SSH and Telnet can both provide remote command-line access, but they were designed with very different security assumptions. Traditional Telnet communication does not provide the encrypted protection expected for modern administrative sessions.

SSH creates a cryptographically protected channel and supports strong server authentication and user authentication mechanisms. That makes it appropriate for administering systems across networks where traffic should not be trusted to remain private.

For modern remote system administration, SSH has effectively replaced Telnet in ordinary security-conscious environments. Telnet can still appear in legacy equipment, testing contexts, or situations where its simple text protocol is useful for diagnostics, but it should not be treated as an equivalent secure login method.

If you encounter older infrastructure that requires Telnet for management, consider isolating that equipment and limiting access through stronger surrounding controls. Legacy protocols often need compensating security because they cannot provide the protections available in current remote-administration technologies.

A Simple SSH Connection Example From Start to Finish

Imagine your hosting company creates a Linux server and gives you the IP address 203.0.113.25, the username admin, and tells you SSH is available on port 22. Open a terminal on Windows, macOS, or Linux.

Enter:

ssh admin@203.0.113.25

On the first connection, SSH displays the server’s host-key fingerprint. Compare it with the trusted fingerprint from your provider or administrator. Once verified, approve the connection so the host information can be saved for future checks.

Complete the required authentication. If a password is configured, enter it when prompted. If the server already has your public key installed, your SSH client may authenticate with the corresponding private key automatically or after you unlock that key with its passphrase.

When the remote prompt appears, you are connected. Run only commands you understand, and type exit when you are finished. That simple workflow—connect, verify, authenticate, work, and exit—is the foundation of everyday SSH server administration.

Final Thoughts on How to SSH Into a Server

Learning how to SSH into a server is one of the most useful skills for anyone working with websites, cloud computing, Linux, development, networking, cybersecurity, or system administration. Despite the technical terminology, the basic connection process requires only a few pieces of information.

For a standard server, the command may be as simple as:

ssh username@server

From there, SSH verifies the server and authenticates your account using a password, private key, or another configured method. After authentication, the encrypted session gives you remote command-line access according to the permissions of your account.

As you become more comfortable, learn key-based authentication, SSH config files, SFTP, SCP, remote commands, agents, port forwarding, bastion hosts, and stronger access controls. These capabilities turn SSH from a simple login tool into an extremely flexible system-administration platform.

The most important beginner habit is to treat SSH access as privileged access. Verify server identities, protect private keys, understand commands before running them, keep systems updated, and remove credentials when they are no longer needed. Used carefully, SSH provides a secure and efficient way to manage servers from almost anywhere.

How do I SSH into a server for the first time?

Open a terminal and run ssh username@server, replacing the values with your actual account and server address. Verify the host fingerprint, then complete the password or key-based authentication requested by the server.

What information do I need to SSH into a server?

You normally need the server IP address or hostname, an SSH username, an authentication method such as a password or private key, and the SSH port if it differs from the standard port 22.

How do I SSH into a server with a private key?

Use ssh -i path/to/private_key username@server. Make sure the matching public key has already been authorized for the remote account and keep the private key protected on your device.

Why is my SSH connection being refused?

A refused connection can mean the SSH service is stopped, you are using the wrong port, or a firewall is actively rejecting the connection. Check the server address, SSH port, service status, and network rules.

Can I use SSH on Windows?

Yes. Modern Windows systems support OpenSSH and can run SSH commands through PowerShell, Command Prompt, or Windows Terminal when the OpenSSH Client capability is installed.