Linux App Service SSH fails for all applications after platform update

Question

Linux App Service SSH fails for all applications after platform update

Josh Yarbrough 1

Starting approximately 2026-10-22, all Linux App Services in our subscription lost SSH access via the Azure Portal. Applications remain healthy and continue serving traffic normally. Log streaming works. SSH launches redirect through gr-prod-sn1-afd.sso.azurewebsites.windows.net and return HTTP 500. Issue affects multiple App Services across production, test, and development environments running both PHP 8.2 and PHP 8.3. No application changes were deployed at the time the issue began.

Evidence

App Service state: Running
Log Stream: healthy, returning HTTP 200 responses
Multiple environments affected
Multiple PHP versions affected
SCM publishing profiles intact
SSH failure reproduces consistently
Azure-managed SSO endpoint returns HTTP 500

0 comments

Answer accepted by question author

0 additional answers

Your answer

Answer 1

Use az webapp exec as the supported non-browser access path, then open an Azure support request if it reproduces the HTTP 500 because the cross-app pattern points to the shared portal/Kudu access path rather than the healthy PHP applications.

Bypass and isolate the browser failure

The current Linux App Service shell experience uses Kudu as an authenticated proxy. The CLI path avoids the browser and managed SSO redirect, although it still depends on Kudu. It requires Azure CLI 2.90.0 or later and Microsoft Entra authorization to the SCM/Kudu site; basic publishing authentication does not need to be enabled.^1^

Run this against one representative app:

az version
az login
az account set --subscription "<subscription-id>"

az webapp exec \
  --resource-group "<resource-group>" \
  --name "<app-name>"

If Bash is unavailable, specify sh:

az webapp exec \
  --resource-group "<resource-group>" \
  --name "<app-name>" \
  --shell /bin/sh

Then distinguish the app container from the Kudu component:

az webapp exec \
  --resource-group "<resource-group>" \
  --name "<app-name>" \
  --target kudu

Interpret the results as follows:

App-container CLI succeeds: use it as the temporary shell-access workaround. The failure is isolated more narrowly to the browser/managed-SSO flow.
App container succeeds but --target kudu fails: include that difference in the support case.
Both CLI targets fail across unrelated apps: the evidence supports escalation as a shared SCM/Kudu access-path problem, subject to Microsoft confirming the platform cause.
CLI reports authorization or network denial: check the caller’s SCM/Kudu RBAC access and whether SCM access restrictions or private networking permit the client. Do not enable SCM basic authentication merely to test this path.^1^

Check tenant-specific incident information

A matching broad public incident is not currently shown on Azure Status. Public Azure Status covers issues affecting a broad set of customers; Resource Health provides current and historical health for individual resources.^2^^3^

Check:

Azure portal → Service Health → Health history / Service issues
- Filter to the affected subscription, App Service, region, and the period beginning 2026-10-22.
Each representative App Service → Resource health
- Review current and historical events for the same UTC interval.
App Service → Properties → Site status
- Record the runtime state and any issue details. This page exposes platform-reported state, last error, occurrence time, and available repair actions.^4^

A healthy site status does not clear the separate portal/Kudu shell path; it establishes that the application runtime remains operational.

Escalate with correlation-ready evidence

If no Service Health advisory explains the issue and the CLI test also fails, open the request from an affected app:

App Service → Support + Troubleshooting → Create a support request

Select the problem area corresponding to Configuration and Management / Accessing app using SSH. Microsoft’s support workflow accepts a browser trace and asks for the start time and reproduction details.^5^

Include:

First known failure and latest reproduction time in UTC.
Affected subscription, region, app names, and App Service plan names.
The failing managed endpoint hostname and HTTP 500 status.
Browser HAR trace from SSH → Go, with cookies and authorization headers removed.
Correlation/request IDs and response headers from the failed request.
Results of both az webapp exec tests, including CLI version and full sanitized errors.
Confirmation that production, test, and development apps are affected across PHP 8.2 and 8.3.
Confirmation that application traffic and log streaming remain healthy.
Service Health, Resource Health, and Site status findings.

Avoid changing PHP versions, redeploying, regenerating publishing profiles, or restarting all apps solely for this symptom; none of those actions addresses a managed SSO/Kudu HTTP 500 when the application workloads remain healthy.

References