Support
This page covers the six most common issue classes, each with the typical symptom, the most likely cause and the steps that resolve it. For anything not covered here, the documentation and the linked pages go deeper.
connector offline
Typical symptom
A connector shows as offline in the Organization's connector list, and assets behind it cannot be reached.
Most likely cause
Outbound connectivity from the connector host to WingGate is broken, the connector service is not running, or its binding credential is no longer valid.
What to check
- From the connector host, verify outbound HTTPS connectivity to the WingGate endpoint — the model is outbound-only, so no inbound port is involved.
- Check the connector service status (for example systemctl status) and read its logs for connection or authentication failures.
- If the credential was rotated or the binding was redone, rebind the connector; binding issues an independent credential used to authenticate to WingGate.
Not authorized
Typical symptom
A member sees an authorization error when opening a session, using SSH, or calling an MCP tool against an asset.
Most likely cause
The member has no active grant for that Project, the asset is not in the Project or not ready, or (for MCP) the Project/asset MCP configuration does not allow the tool.
What to check
- Confirm the member is bound to the Project that contains the asset.
- Check they have an active Project access grant. Finer MCP limits come from Project/asset MCP configuration, not from the grant.
- Remember that revoked grants take effect at the next authorization check; if access persists unexpectedly, re-check which grant actually covers the operation.
SSH host key mismatch
Typical symptom
A connection is blocked with a host key mismatch warning after the target was rebuilt, reinstalled or moved to a new address.
Most likely cause
The host key presented by the target no longer matches the fingerprint you confirmed earlier. This can be a legitimate rebuild — or a man-in-the-middle signal.
What to check
- Verify the new fingerprint out of band (console access, provider panel or the person who rebuilt the host) before doing anything else.
- If the change is expected, probe the host key again and confirm the new fingerprint deliberately.
- Never override a mismatch you cannot explain — the override is an audited, explicit action, and unexplained key changes are exactly what confirmation protects against.
SSH client cannot connect
Typical symptom
Your own SSH client fails to authenticate or reach the asset through WingGate.
Most likely cause
The account has no registered SSH public key, the client is pointed at the wrong endpoint, or the member has no Project grant for that asset.
What to check
- Register your public key on the account — WingGate authenticates you by public key at its SSH endpoint and never holds your private key.
- Confirm you are connecting to the WingGate SSH endpoint and selecting the correct Organization and asset.
- Verify the member has an active Project access grant and the asset supports the SSH client entry; without that, authorization refuses the connection, not SSH itself.
MCP authentication or tool failures
Typical symptom
Your MCP client gets a 401, lists no tools, or a tool call fails even though other tools work.
Most likely cause
The bearer credential is missing or wrong on the client side, or the call crosses a capability boundary — MCP exposes only one-shot non-PTY tools, and file.find/file.grep are Runner-only.
What to check
- Check that the client sends the Project MCP credential on every request; the credential value is shown only once at creation, so create a new one if it was lost.
- Make sure the client connects to the connector's MCP endpoint discovered through the WingGate API — not to WingGate itself.
- Do not expect interactive shell sessions over MCP: it publishes only one-shot, non-PTY tools (shell.exec, the file tool group, and browser tools on browser assets); PTY sessions belong to the Web Terminal and SSH client entries.
- If file.find or file.grep is unavailable, check whether a Runner is installed and callable on that asset — these tools are Runner-only, and authorization, installation and callability are separate states.
Account recovery
Typical symptom
You lost your authenticator device or passkey and cannot pass the second-factor step at sign-in.
Most likely cause
Recovery depends on what you prepared in advance: the one-time recovery codes issued at passkey enrollment, or the key shown at TOTP enrollment that you kept (it can re-enroll an authenticator), are the only self-service safeguards.
What to check
- If you saved the recovery codes, use one to sign in and re-enroll a factor as prompted.
- If you kept the key shown at TOTP enrollment, use it to re-enroll an authenticator.
Still not solved?
If none of the above resolves your issue, reach out to the operator of the deployment you use. Include what you were trying to do, the exact symptom, and which of the steps above you already checked.