Connect Sophos Firewall via SSH

Many support and troubleshooting tasks require SSH access to Sophos Firewall. Examples include log analysis, service restarts, specific diagnostic commands, and work in Advanced Shell.

SSH is also a high-risk management interface. Only permit access from trusted admin networks, through a narrowly scoped Local Service ACL exception rule, or through clearly defined support access. For broader hardening of local firewall services, see Configure Device Access correctly.

Requirements

For an 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 changed and securely documented password for the default administrator; the factory-set password must not remain in production use.
• 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 Advanced Shell: a backup, a maintenance window, and a clearly defined plan for rolling back changes if problems occur.

⚠️ Only allow SSH from trusted networks. In production, restrict access to a management IP or admin network rather than enabling SSH broadly.

Decide what SSH is needed for

Not every investigation requires Advanced Shell. Before signing in, decide which console you need and how intrusive the work will be.

• Routing, DNS, ping, and simple system commands: Device Console is usually the right choice. It uses the Sophos CLI and is less risky than Advanced Shell.
• Detailed system information, databases, or system services: Advanced Shell may be required. Without reliable, case-specific Sophos instructions, limit work to read-only checks and don’t change or delete anything.
• Service status or debugging: This also belongs in Advanced Shell. Enable debugging only for a specific purpose and turn it off again afterwards.
• Unknown commands: Don’t try them on a production system. Verify them first, reproduce the task in a test environment, or open a support case.

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.

Allow SSH access to 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 Sophos Firewall WebAdmin.
2. Open Administration.
3. Select Device access.
4. Under Local service ACL, check whether SSH is allowed for the intended trusted admin zone. Record the current state before making any changes.
5. If you deliberately want to allow access from this entire zone, enable SSH only for that zone and save with Apply. Settings that already meet your requirements do not need to be changed again.

For a trusted internal administration network, LAN may be the appropriate zone. However, allowing access for a zone does not restrict access to a single admin computer. To restrict access to an admin IP or management network, use the Local service ACL exception rule described below instead; broadly enabling access for the zone is not an additional required step. Do not enable SSH broadly for WAN.

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 can reach the firewall’s local SSH service regardless of whether a classic LAN-to-WAN rule is configured cleanly.

The web-based CLI Console is a different access method from an SSH client: the SSH client uses TCP 22, whereas the browser console uses HTTPS access to WebAdmin. For browser access, open Administration > Device access, check the HTTPS permission under Local service ACL for the intended trusted admin zone, and enable it with Apply if needed. Then open the admin drop-down menu at the top right of WebAdmin and select Console. SSH permission is not required for this browser access method. Do not enable HTTPS broadly for WAN either; existing source restrictions must remain in place.

Account selection is subject to the documented limitation in SFOS 22 and 23: the PuTTY instructions explicitly require admin and exclude other usernames, including for password login. Although the profile description grants the Administrator profile full CLI access and allows it to be assigned to additional administrators, it does not specify a transport method for that access. A role permission therefore does not guarantee that a named account can log in via network SSH. Nor is general browser console access confirmed here for every named account. Before using an access method as a fallback, validate it with the intended account on the installed SFOS version. If Console is missing or access is rejected, keep existing working sessions open; check the account, profile and access method and, if necessary, clarify the issue with Sophos Support rather than widening WAN or ACL permissions. The following SSH steps continue to use admin; the exclusive management of SSH Public Keys by the default admin is a separate permission.

Before changing anything, record the zones in which SSH is currently enabled and the SSH exceptions that already exist. This preserves a reliable rollback state without removing another intentional permission.

Under Local service ACL exception rule, click Add and set the values as narrowly as possible:

• Name: for example SSH-from-admin-network; freely selectable and unambiguous
• Rule position: the position of the exception in the Local Service ACL
• Description: purpose, responsible team, and the end date for temporary access
• IP version: IPv4 or IPv6 matching the admin source and destination address
• Source zone: the zone from which administration takes place
• Source Network / Host: the admin IP or management network
• Destination host: the firewall IP or interface to be administered, if access can additionally be restricted to a specific destination address
• Services: SSH
• Action: Accept

Click Save. For one admin system, Source Network / Host could be a host object containing 192.0.2.10. This is a documentation address; replace it with the actual, preferably fixed admin IP. Destination host additionally limits the firewall IP through which the service can be reached. Don’t include every interface address without an operational reason.

Open a new SSH session from the intended admin source. The test succeeds when the console menu appears. Then test from a deliberately unauthorized network and confirm that no session is established. If the result is unexpected, keep the existing WebAdmin session open and check the source IP, Source zone, IP version, Destination host, rule position, and upstream filters.

For temporary access, delete only this exception under Administration > Device access > Local service ACL exception rule and confirm with OK. If you changed a zone checkbox instead, restore only that checkbox to its recorded state and click Apply. Then test from the same source and confirm that SSH is reachable or blocked exactly as it was before the change. This validates the restored state without assuming that the expected result is always a successful or failed login.

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.

Diagnostics > Support access is a separate mechanism. It does not simply expose SSH from the internet. Instead, it allows Sophos Support temporary access through a support channel established by the firewall. This access should also be time-limited and disabled again after the support case.

When enabling Support access, you select a duration, after which the firewall generates a unique Access ID for Sophos Support. This Access ID remains valid for the selected duration; Support access can be disabled at any time before that duration expires. Sophos Support can use it to access WebAdmin and the shell without requiring normal admin credentials. The firewall itself establishes the outbound support connections for both HTTPS and SSH over TCP 22; operationally, this is different from allowing inbound SSH from the WAN.

Before any activation – including in WebAdmin – first check the existing support channel under 4. Device Console using the read-only command:

show support_access

The command shows whether Support access is active and, when access is active, also shows the Access ID and duration. Record the baseline state and any displayed duration and Access ID exclusively in the authenticated, relevant support case. The output alone does not establish which case the channel belongs to; clarify this association and consent to access with the responsible team and Sophos Support.

If a channel is already active for another case or ownership is unclear, stop and coordinate the next steps without re-enabling, replacing or disabling the channel. An active channel already authorised for the same case must not be enabled again either; coordinate its continued use and closure within the existing case. Only begin the standalone enable, analyse and disable procedure when the baseline state is confirmed as inactive and explicit consent has been given for this support case. This prerequisite applies to both access methods below.

For the WebAdmin method, open Diagnostics > Support access, turn on Support access, and confirm with OK. Then select the duration needed for the specific support case, click Apply, and confirm again with OK. The firewall establishes a secure control connection to its access proxy; find the generated access ID under Access status and share it only with Sophos Support through the agreed support channel.

Control support access from Device Console

SFOS 22 can also enable the support channel under 4. Device Console. Immediately before running the write command, repeat the check described above there using show support_access. Only enable the channel if it is confirmed as inactive and consent has been given for this case:

set support_access enable

After successful activation, the command shows the Access ID and access duration. Compare the duration actually displayed with the case-specific consent; the documented CLI syntax contains no parameter for setting a duration. If a specific duration is required, use the WebAdmin method described above after performing the same preflight check. Share the Access ID and duration only in the authenticated, relevant support case, and do not copy them into general documentation, chats or password stores.

After completing the analysis, disable only your own channel that was set up with consent for this case, regardless of its remaining duration. Before doing so, use show support_access and the documented Access ID to verify that it is still the same channel. If it is already inactive, no write command is needed; if the ID differs or ownership is unclear, stop and coordinate rather than disabling a channel that may belong to someone else:

set support_access disable

Then check under Diagnostics > Support access or using show support_access that your own channel is no longer active. disable changes neither the normal SSH configuration under Device Access nor Local Service ACL Exception Rules; temporary admin and SSH permissions must therefore be rolled back separately to the previously recorded state, and only to the extent of your own changes.

If another router or outbound filter is in front of the firewall, it must allow TCP 22 to *.apu.sophos.com. This does not require an inbound WAN rule on Sophos Firewall. Idle support sessions close after 15 minutes; the selected overall duration and the option to turn off Support access manually remain independent of that timeout.

Check Sophos Firewall outbound services and ports maps the other vendor destinations for updates, licensing, RED, Central, reporting, and backups.

Support access via XML API: clarify before write access

The XML API help for SFOS 22 and 23 identifies the object as SupportAccess, but contains two contradictions: In the XML example, the duration tag is GrantAccessFor, whereas the parameter table lists GrantAccessForr. For ConfigOption, the table gives the default as ON, but only permits Enable and Disable. Neither a valid request value of ON nor support access being active by default can be inferred from this. Before writing, confirm the valid tag spelling for the installed build in API help or with Sophos Support.

The table marks both fields as optional scalar values and lists the time windows 1 day, 2 days, 1 week, 2 weeks, 1 month and 2 months. This does not clarify what actually happens when a field is omitted. Before making an automated change, therefore, check the object-specific API help for the installed SFOS build and have Sophos Support clarify any outstanding questions about the tag, values or omission behaviour. Until the contradiction is resolved, stop XML write access; do not invent a payload or try both spellings on the production system. For an approved support case, the WebAdmin method described above remains the alternative, without broadening WAN or ACL permissions.

For this operation, the reference lists 200 with Operation Successful. and 500 with Operation Fail.. Inspect the exact object response rather than blindly repeating a failed or unclear write operation. After a confirmed change, check the actual activation state and duration under Diagnostics > Support access or using show support_access as described above. After the support case, disable only your own channel authorised for this case, subject to the ownership checks described above, and verify that it is inactive; temporary SSH/ACL permissions must still be rolled back separately.

Add a 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.

⚠️ An 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 public key authentication for SSH by adding or removing SSH keys. These SSH-key changes belong in a documented admin process and are not a spontaneous support shortcut.

The default admin isn’t a normal role account that can simply be replaced. Sophos points out that this account can’t be renamed or deleted. The default admin password, MFA or recovery information for interactive admin sign-ins, and the stored SSH public keys should therefore be managed together in the admin operations process. A public key doesn’t replace proper management of this account.

Named WebAdmin administrators are managed separately and can’t sign in through SSH with their own usernames. Manage local administrators and Device Access profiles according to least privilege explains the lifecycle and permissions of these accounts.

Before storing the public key on the firewall, generate a matching public and private key pair on your own admin client using an SSH key tool. An existing, suitable matching key pair can be reused. For the key type and key length, follow the guidance in the following section on supported SSH key types. Store and protect the private key exclusively on the admin client; never share it or upload it to the firewall. For the following steps, copy only the public key.

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.

Keep the existing WebAdmin or SSH session open while testing the new key in a second SSH session. Only remove an old key or change a password fallback after the console menu appears in that second session. If the test fails, the existing login remains available: check the key type, public-key entry, matching private key, and permitted source, then remove only the newly added faulty entry.

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: Supported; 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 from macOS or Linux

An SSH client is usually already installed on macOS and Linux. Establish the connection from a 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, document the private key path, the permitted source IP, and the purpose. Do not copy the known_hosts entry into tickets or chat histories. When investigating host-key warnings, the change history is more important than a quick workaround.

Connect with 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: If the program is not already installed, first download it from the official PuTTY download page and set it up on the admin computer. Then establish the connection as follows:

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, the Main Menu appears. The following example provides a guide to the menu options:

Main Menu

  1. Network Configuration
  2. System Configuration
  3. Route Configuration
  4. Device Console
  5. Device Management
  6. VPN Management
  7. Shutdown/Reboot Device
  0. Exit

Select Menu Number [0-7]:

At the Select Menu Number [0-7]: prompt, enter the number of the desired menu option, for example 1 for Network Configuration. The following two paths are particularly important for diagnostic commands. 7. Shutdown/Reboot Device leads to actions that can interrupt operation; this menu option is not intended for experimentation.

For many SFOS commands you use:

4. Device Console

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

5. Device Management
3. 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.

According to Sophos, configuration changes made directly in Advanced Shell, such as changes to interfaces, rules, or policies, don’t persist after a restart and aren’t included in backups. This is therefore not a normal configuration path. Files under /tmp/ are also deleted on restart.

• Device Console: ping, dnslookup, traceroute, show, Routing or System Options.
• Advanced Shell: detailed system information, databases, system services, and case-specific diagnostics directed by Sophos Support.

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

Understand the set and system command families

In 4. Device Console, set defines settings and parameters for various system components, while system configures system parameters. Both families can change the configuration. To learn about them, use help only, not a complete change command. The SFOS 22 and 23 documentation uses these general syntax patterns – they are not commands to copy:

set [command] [option 1|option 2] <value>
system [command] [option 1|option 2] <value>

• set or system is the literal prefix; enter it exactly as shown.
• Replace [command] with the documented command you need, for example advanced-firewall for set or firewall-acceleration for system.
• [option 1|option 2] means choosing one of the documented alternatives. Do not type the square brackets or |; here they do not mean that you can simply omit the choice.
• <value> is a placeholder for a value appropriate to the selected option. Replace it, including the angle brackets, with the required value. The specific command’s help determines which arguments are actually required; the general pattern alone does not.

Syntax explanation only – do not execute: In the vendor example set advanced-firewall icmp-error-message allow, set is the prefix, advanced-firewall the selected command, icmp-error-message the option and allow the actual value replacing <value>. This changes configuration; it is not a required SSH step. The vendor example system firewall-acceleration enable is not a learning exercise either: system is the prefix, firewall-acceleration the selected command and enable the selected option. This specific example has no additional value; do not blindly append <value> or enable acceleration just to experiment.

For safe discovery, type only set in Device Console and press Tab three times to list the available settings. Tab followed by ? shows their descriptions. Repeat with the prefix system to explore the other family. Expect help output, not a changed setting. Clear the input line afterwards without submitting a change command with Enter. If the expected help is missing, check the console and the documentation for the installed SFOS version first rather than trying an example command.

End the connection

⚠️ The legacy Device Console controls enableremote and disableremote are not a normal logout method: for SFOS 22 and 23, Sophos states that disableremote not only prevents new SSH connections on port 22, but also terminates existing SSH sessions. Therefore, do not execute these controls to log out or to roll back a temporary ACL permission. Before any explicitly approved use of these controls, a working recovery access path independent of network SSH must have been tested: a local serial or out-of-band console for physical appliances, or the appropriate platform console for virtual or cloud firewalls. Without this access and a recovery plan confirmed for the installed version, stop and clarify the case with Sophos Support. The description of enableremote mentions an Ethernet port; neither TCP port syntax nor a blanket inverse command is inferred from this here. For temporary access permissions, the precise rollback described above under Administration > Device access remains the required procedure; the outbound channel established under Diagnostics > Support access is separate from this.

In Advanced Shell, use the following command to leave the shell. It is not a substitute for selecting a number in the console menu:

exit

If you are in a submenu, first return to the Main Menu. There, 0. Exit ends the console session: enter 0 at the menu prompt. The shell command and the menu number are therefore used in different places.

Sophos Firewall closes idle SSH sessions after 15 minutes. This does not replace a clean logout: Open sessions, debug modes, and temporary access rules should still be closed or removed deliberately.

If SSH access was allowed only for a support case, revoke exactly that temporary access permission afterwards. Delete the Local service ACL exception rule created for that purpose as described above; if you changed a zone checkbox, restore it to its previously recorded state and save with Apply. Leave other permissions that are still needed intact. This is particularly important for 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 refused, SSH is often not allowed for the selected zone or source. Under Administration > Device access, check the SSH setting and existing Local service ACL exception rule entries. Also determine whether broader zone access was deliberately revoked. Do not reverse such a restriction without checking first.

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.

If a firewall that hasn’t yet been fully configured still uses the factory-set default password, SFOS intentionally drops SSH connections from the WAN zone without an error message. This is a security safeguard. Change the password through an approved local administration path first; don’t broaden Device Access or the ACL as a workaround.

No network access to the firewall

If neither WebAdmin nor SSH is reachable, do not rush to enable additional WAN or zone access. For a physical appliance, the local serial console is the fallback, for example when Device Access, routing, or interface zone assignments are incorrect. Use the appropriate RJ45 console cable or, on supported models, Micro-USB, and set the terminal program to 38400 baud.

If Micro-USB and RJ45 are connected at the same time, Micro-USB takes priority and the firewall redirects console output to it. If the terminal is blank, first check the selected serial port, the cable, and this priority. The 38400 baud setting is grayed out in the BIOS to prevent accidental changes; do not try to adjust it there.

The detailed connection steps are provided under Open a serial connection. If you know the admin password, use it to log in after establishing the connection; no password reset is required. Use only the connection steps in the linked article, not its reset procedure. The connection is successful when the console menu appears; virtual or cloud firewalls instead require the console access method appropriate to their platform.

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 the default admin password has genuinely been lost, Reset the Sophos Firewall admin password explains serial recovery for physical appliances and the separate limitations for virtual and cloud firewalls.

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 documented Sophos CLI command isn’t recognized, the wrong console may be open or the syntax may be incomplete. In Device Console, press Tab to list available commands and arguments; ? shows their descriptions. Don’t enter Linux shell instructions there, and don’t experiment with unsupported commands in Advanced Shell either.

Operational checklist

• Allow SSH only from trusted admin sources.
• Change the factory-set default password before using SSH in production.
• Where possible, use a Local service ACL exception rule instead of broadly enabling access for a zone.
• Prefer public key authentication for the admin account over password login.
• Document the default admin password, MFA/recovery information, and SSH keys separately.
• Use a supported key type and document the key length.
• Do not share private keys.
• Check the SSH fingerprint on first login.
• Handle host-key warnings carefully after a reimage or hardware replacement.
• Do not confuse Device Console and Advanced Shell.
• Make changes in Advanced Shell only with a clear purpose.
• Revoke temporary SSH access permissions after support cases.
• Delete old public keys after personnel or service provider changes.

FAQ