Connect Sophos Firewall via SSH

For many support and troubleshooting tasks you need access to the Sophos Firewall via SSH. These include, for example, log analyses, service restarts, special diagnostic commands or working in the Advanced Shell.

But SSH is also a management access with high risk. Access should therefore only be permitted from trustworthy admin networks, via a targeted Local Service ACL exception rule or via clearly defined support access. For general hardening of local firewall services, Configure Device Access correctly is also suitable.

Requirements

For a SSH connection to the Sophos Firewall you need:

• Administrative access to the Sophos Firewall.
• The IP address or DNS name of the firewall.
• Access to user admin.
• A trusted admin source, for example management network, VPN or fixed admin IP.
• On macOS or Linux: the preinstalled Terminal app with SSH.
• On Windows: Windows Terminal with OpenSSH or PuTTY.
• Allowed SSH access under Administration > Device access or via a Local service ACL exception rule.
• For planned changes in the Advanced Shell: backup, maintenance window and clear rollback path.

⚠️ SSH should only be allowed from trusted networks. For productive environments, it is better to restrict access to a management IP or admin network rather than releasing SSH generally.

Clarify beforehand what SSH is needed for

Not every analysis needs the Advanced Shell. Before logging in, it should be clear which console is required and how severe the intervention is.

• Routing, DNS, Ping, simple system commands: Device Console. Sophos CLI, less risky than the Advanced Shell.
• Read log files, tail, grep, less: Advanced Shell. Read only, do not modify or delete files.
• Check service status or debug: Advanced Shell. Only specifically activate debug and deactivate it again.
• Execute unknown commands: Check first or open a support case. Do not try in the production system.

The distinction is important because Device Console and Advanced Shell use different syntax. Many errors occur simply because a correct command is entered in the wrong place. A broader overview is available in Sophos Firewall Troubleshooting: Services and Logs.

SSH Allow access on the firewall

In order for a connection to be possible, the Sophos Firewall must allow SSH on the appropriate zone or via a Local Service ACL exception rule.

1. Log in to the Web Admin of the Sophos Firewall.
2. Open Administration.
3. Select Device access.
4. Check whether SSH is allowed for the desired zone.

For internal administration networks, SSH can be activated directly for the appropriate zone, for example for LAN. If access is to be restricted more specifically, a Local service ACL exception rule makes sense.

Device Access controls access to the firewall itself. This is not the same as a normal firewall rule that allows traffic through the firewall. If SSH in Device Access is enabled too broadly, a client will reach the firewall’s local SSH service regardless of whether a classic LAN to WAN rule is cleanly built.

In the case of an ACL exception, the values ​​should be set as narrowly as possible:

• Source zone: the zone from which administration takes place
• Source Network / Host: the admin IP or management network
• Services: SSH
• Action: Accept

SSH should not be accessible uncontrolled from the Internet. If external access is necessary, this should only be permitted via a clearly defined source IP, VPN or dedicated support access.

Store public key for admin

For SSH access, public key authentication is the preferred method. On the Sophos Firewall, the public key for the user admin can be stored under Administration > Device access. Password login may be necessary for emergencies, but should not remain the most convenient default access.

⚠️ A SSH login to the Sophos Firewall is only possible with the user admin. Other WebAdmin users cannot log in via SSH.

Important: Only the default admin can change the public key authentication for SSH, i.e. add or remove keys. For operations, this means: Key changes belong in a documented admin process and should not be treated as a spontaneous support shortcut.

The public key is added in the Public key authentication for admin area:

1. Open Administration.
2. Select Device access.
3. Scroll to the Public key authentication for admin area.
4. Activate Enable authentication.
5. Add the public key under Authorized keys.
6. Save with Apply.

The private key always remains on the admin client and may not be shared. Only the public key is stored on the firewall.

If multiple admins use SSH, the same private key should not be shared. It is better to have separate admin clients, documented public keys and a review of which keys are still needed. After changes in personnel or service providers, the area Authorized keys should be checked.

Supported SSH key types

Not every modern SSH key type is equally suitable for Sophos Firewall. Before rolling out, you should check whether the key type is supported.

• RSA: Use at least 2048 bits.
• DSA: At least 2048 bits, if necessary for compatibility reasons.
• ECDSA: Supports; ED25519 is not accepted for this purpose.
• ED25519: For SSH Public Key Authentication do not use on Sophos Firewall.

For new admin access, a properly managed RSA or supported ECDSA key is usually more pragmatic than a modern key type that the firewall or an older SSH tool does not accept.

Connect to macOS or Linux

A SSH client is usually already present on macOS and Linux. The connection is established in the terminal.

Example:

ssh admin@192.0.2.1

192.0.2.1 is replaced by the IP address or DNS name of your own Sophos Firewall.

When the connection is established for the first time, the SSH client asks whether the fingerprint of the target system should be accepted. This fingerprint should be checked and then confirmed. If a warning about a changed host key appears after a reimage, hardware replacement or IP change, the new fingerprint should not be blindly accepted. First check whether the same firewall has actually been replaced, reinstalled or moved to a new IP. Only then can the old entry in ~/.ssh/known_hosts be cleaned up and the new fingerprint accepted.

Depending on the configuration, the password of the user admin is then requested or the login is carried out using the stored SSH key.

If a specific private key should be used:

ssh -i ~/.ssh/sophos-admin-key admin@192.0.2.1

For recurring access, the key path, the permitted source IP and the purpose should be documented. The known_hosts entry should not be copied into tickets or chat histories; For host key warnings, the change history is more important than a quick workaround.

Connect to PuTTY

Under Windows you can either use Windows Terminal with OpenSSH or use PuTTY.

With Windows Terminal, establishing a connection works similarly to macOS or Linux:

ssh admin@192.0.2.1

For PuTTY:

1. Open PuTTY.
2. Enter the IP address or DNS name of the Sophos Firewall under Host Name.
3. Set Port to 22.
4. Set Connection type to SSH.
5. Connect with Open.
6. Check and confirm the SSH fingerprint.
7. Log in as user admin and use password or SSH key depending on the configuration.

After logging in, the Sophos Firewall console menu appears.

If PuTTY is used with a private key, the key must match the public key stored on the firewall. After a change in personnel or service provider, not only the password should be changed; old public keys must also be removed from Authorized keys.

Open Device Console or Advanced Shell

After successful login via SSH, the firewall displays a console menu. Which option you choose depends on what you want to get done.

For many SFOS commands you use:

4. Device Console

For deeper Linux or file system tasks, use the Advanced Shell via:

5. Device Management > Advanced Shell

The Advanced Shell offers very extensive access to the system. Commands should only be executed there if it is clear what they do.

• Device Console: ping, dnslookup, traceroute, show, Routing or System Options.
• Advanced Shell: Read /log, tail -f, grep, less, service -S, Debug Logs.

For log analysis, service names and typical error patterns, Sophos Firewall Troubleshooting: Services and Logs is a better starting point than memorizing individual commands.

Terminate connection

When the work is complete, the SSH session should exit cleanly:

exit

If you are in a submenu, it may be necessary to first switch back to the main menu and then end the session.

If SSH was only activated temporarily for a support case, the release should then be removed or deactivated. This is especially true for ACL exceptions that come from external source IP addresses or service provider access.

After deep interventions, the following should also be checked:- Is debug disabled again?

• Has a temporary ACL exception rule been removed or disabled?
• Were there no temporary files, support dumps or recordings left unnecessarily on the firewall?
• Are log extracts, time, command and result documented in the ticket or change?
• Was the SSH key only used for scheduled admin or support access?

Common problems

Connection is refused

If the connection is rejected, SSH is usually not allowed on the firewall for the selected zone or source. In this case, Administration > Device access should be checked. Additionally check whether an ACL exception rule allows the source or whether a broader device access release was deliberately removed.

Connection times out

A timeout often indicates that the firewall cannot be reached via the selected IP address, a route is missing, or an upstream firewall is blocking access.

Login fails

If the login fails, the user admin, the password or the SSH key and the permitted source networks should be checked. Typical messages like Permission denied (publickey,password) indicate an incorrect password, an incorrect private key, or a missing public key configuration.

If public key login fails, additionally check key type, key length, incorrect private key, PuTTY key format and the entry under Authorized keys. A correctly permitted SSH service does not help if the key does not match the stored public key.

Host key warning appears

A host key warning may be harmless if a firewall has been reinstalled or replaced. The warning can also indicate an incorrect target system or an IP address mix-up. Therefore, first check the firewall, IP address, DNS and change history. Only then should the old known_hosts entry be removed.

Wrong console opened

If a command is not recognized, the wrong console is often open. Commands like system ... often belong in the Device Console. File system and log commands such as tail, grep, less or service -S belong in the Advanced Shell.

Operational checklist

• Only allow SSH from trusted admin sources.
• If possible, use Local Service ACL Exception Rule instead of wide zone release.
• Prefer Public Key Authentication for admin.
• Use supported key type and document key length.
• Do not share private keys.
• Check SSH fingerprint on first login.
• Consciously handle host key warnings after reimage or hardware replacement.
• Do not confuse Device Console and Advanced Shell.
• Only make changes in the Advanced Shell with a clear purpose.
• Remove temporary SSH releases after support cases.
• Delete old public keys after changing personnel or service providers.

FAQ