Docs

Getting Support

Where to go

GitHub Issues — bugs and feature requests. Search first; a lot of things are already there.

GitHub Discussions — questions, and “is this supposed to work like this”.

Cloud and Enterprise customers have their support channel through their account.

Before you ask

Two pages answer most of what comes up, and checking them first usually saves a round trip:

What to include

The difference between a fast answer and three days of clarifying questions:

Which edition and version. Community, Cloud or Enterprise, and the version:

$ grep SHELLHUB_VERSION .env      # self-hosted

Self-hosted or Cloud. They fail differently.

Whether the namespace is legacy. A legacy namespace and a new one authorize SSH differently. See How Authorization Works.

How the agent was installed. Docker, Podman, standalone, WSL, or built into an image.

What you did, what happened, what you expected. Concretely. “It does not work” cannot be acted on; “ssh [email protected]@server returns permission denied, and the device shows online in the console” can.

Logs, if the server is yours:

$ ./bin/docker-compose logs --tail 200

Agent logs, from the device:

$ docker logs <container>
$ journalctl -u shellhub-agent -n 200
$ sudo snap logs shellhub

What not to include

Redact before pasting:

  • The contents of .env.override — it has your database password
  • API keys and provisioning keys
  • Private keys, always
  • Tenant IDs, if you would rather not have them public

Log output can carry addresses and hostnames too. A quick read before pasting is worth it.

Reporting a security issue

Do not open a public issue. There are two private routes: a GitHub Security Advisory, which is the preferred one and is visible only to maintainers, or [email protected]. Receipt is confirmed within two business days.

ShellHub follows coordinated disclosure, assigns a CVE to every confirmed vulnerability, and publishes an advisory once a fix exists. The security policy carries the patch targets by severity and what an advisory contains.

Contributing a fix

ShellHub is open source and the fix may well be yours. Open an issue first for anything larger than a small change, so the discussion happens before the work; for a small one, the pull request is the discussion. Branch, push, open the PR against the relevant repository.

CONTRIBUTING.md has the rest, including the code of conduct every interaction is expected to follow, and the repository’s README covers getting the stack running.

Where to go next

  • FAQ — Short answers to common questions.
  • Troubleshooting — Self-hosted server problems.
esc