iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Need a server to try this on? Antihost offers Linux VPS plans with NVMe storage, full root access and a 14-day free trial.
Laravel Forge’s Permission denied (publickey) message means an SSH server rejected the key-based login it received. It does not, by itself, tell you which connection failed. Forge deployments involve two separate SSH trust relationships: your computer connecting to the Forge server, and the Forge server connecting to GitHub, GitLab, or Bitbucket. Test those hops separately, then install the missing public key in the correct place.
What the error actually means
SSH authentication succeeds only when the destination recognizes a public key that matches a private key presented by the client. GitHub describes a “Permission denied” error as the server rejecting the connection. In a Forge workflow, that rejection can occur before Forge is involved (your workstation cannot enter the server) or during deployment (the server cannot read the repository).
The two paths use different credentials and authorization records:
| SSH hop | Client and destination | Where authorization is stored | Typical repair |
|---|---|---|---|
| Workstation to server | Your computer to the Forge server, using the Forge server hostname and your server username | The server account’s authorized keys, managed in Forge’s server SSH Keys area | Add the public half of the key you use on your computer |
| Server to repository | The Forge server to the source-control provider, normally as the git user |
The connected provider account or the repository’s deploy-key settings | Register Forge’s server SSH key with the intended repository and grant the required read access |
A key accepted on one hop is not automatically accepted on the other. Logging in to the server successfully therefore does not prove that a deployment can clone or fetch its repository.
#1 Best Overall
First identify which hop is failing
Do not rotate keys until you know which side rejected the connection. Run a direct server test from your workstation, then test repository access from the deployment environment.
Test workstation-to-server access
Use the same server hostname, username, and private key that you normally use for Forge access:
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
ssh -v user@serverReplace user and server with the account and host shown in Forge. If this command fails, the problem is the workstation key, the server username or hostname, or the server’s authorization for that key. Repository settings are not involved yet.
Test server-to-provider access
Run the provider test from the environment that performs the deployment. For GitHub, the diagnostic form is:
ssh -vT git@github.comThe destination must be the provider’s SSH host and the login must be git. A personal GitHub username in place of git causes public-key authentication to fail. If this test fails while your workstation-to-server test succeeds, repair the Forge deploy key rather than your personal workstation key.
If you cannot run a shell command in the deployment context, use the deployment log to establish which operation failed. A failure while connecting to the server points to the first hop; a failure while cloning, fetching, or updating the repository points to the second.
Read verbose SSH output instead of guessing
The -v option shows the authentication conversation. Repeat the failing command with verbosity and inspect the identity lines.
- An identity-file line marked as missing means SSH looked for that file and did not find it. Check the path, filename, and permissions for the user running the command.
- An
Offering public keyline means a key was actually presented to the server. If the server still rejects it, the corresponding public key is not authorized there, the wrong account is being used, or the key is not the one you intended. - If no intended key is offered, SSH may be reading a different configuration, using an empty agent, or running as a different operating-system user.
Verbose output is diagnostic, not proof of authorization. It tells you what the client attempted; the destination’s key registration determines whether that attempt is accepted.
Repair a workstation-to-Forge-server failure
1. Confirm the key available to your local user
Check the SSH agent identities visible to the same user who runs the failing command:
ssh-add -l -E sha256If the agent reports no identity, load the intended private key into it or create a replacement pair, then use the matching public key for authorization. Keep the private key on your workstation; only its public half should be copied to the server.
Rank #3
Do not run one diagnostic with sudo and another as your normal user. GitHub’s troubleshooting guidance warns that elevated commands can see a different home directory, agent socket, and key set. A key visible to your normal account may therefore appear to be missing when the command is run as root, and vice versa.
2. Verify the server host and username
Use the exact host and account configured in Forge. A valid key offered to the wrong host or account is still rejected. If the server was rebuilt or its connection details changed, update the command before changing any keys.
3. Add the matching public key in Forge
Laravel’s SSH guidance explains that adding your machine’s public key to the server lets the SSH service identify your connection and grant access. In Forge, open the server’s SSH Keys list and add the public key that corresponds to the private key your workstation is offering. Save it for the account you actually use to log in, then rerun ssh -v user@server.
Compare fingerprints when more than one key exists. The key listed by ssh-add -l -E sha256 should correspond to the public key you registered. Adding an unrelated public key, even if it belongs to the same person, will not authenticate the private key currently being offered.
Recommended Free Tools
4. If the key is missing or unusable
Load the intended private key into the agent and test again. If that private key is gone, create a replacement key pair and register its public half in Forge before retrying. Removing old keys is a separate cleanup decision; first establish a working connection so you do not lock yourself out.
Repair a Forge-to-repository failure
1. Check the repository URL format
Repository SSH URLs must use the provider’s expected host and the git user. For GitHub, the diagnostic command is ssh -vT git@github.com; do not substitute your personal username for git. A URL with the wrong host or account can produce the same public-key message as an unregistered key.
2. Locate the key Forge is using
Forge supplies an SSH key for the server’s connection to a connected source-control provider. Forge’s deploy-key documentation says this server key can be added to connected GitHub, GitLab, or Bitbucket accounts and managed as a repository deploy key. In the Forge server or source-control connection settings, identify that server key and its public half rather than using your workstation’s personal key by assumption.
3. Authorize it for the intended repository
Add the Forge server public key to the exact repository that the deployment references, or to the connected provider account according to your organization’s policy. Confirm that the key has the read access required to clone and fetch. A key authorized for a different repository, organization, or account remains unauthorized for the deployment target.
4. Retest from the deployment environment
Run the provider-specific verbose SSH test where Forge performs the operation. For GitHub:
ssh -vT git@github.comLook for the expected identity being offered. If it is not offered, inspect the server-side SSH configuration and key installation; if it is offered and rejected, correct the provider or repository registration. Once authentication succeeds, retry the deployment so that any separate repository permission or branch error can be evaluated independently.
Recover a revoked Forge server
A revoked server is an operational state distinct from a bad local key. Forge’s API documents a reconnect flow that returns a public key. Use that documented reconnect call for the revoked server, install the returned public key on the server, and then reactivate the server in Forge. The key returned by the reconnect operation is the one that must be installed; an older key from a previous server state may no longer restore the connection.
After reactivation, test both directions again: your workstation to the server, and the server to the repository provider. Reconnection repairs the server’s Forge relationship; it does not automatically grant repository access to a provider if that key is absent from the repository or connected account.
Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Fix the driver behind crashes, sound loss and screen glitches3Clear out junk files and repair common Windows errorsChoose the fix by symptom and key location
| Observed symptom | Likely failing hop | Key to inspect | Authorization to change |
|---|---|---|---|
ssh -v user@server cannot authenticate from your computer |
Workstation to server | Your local private key, agent, and matching public key | The server account’s SSH Keys list in Forge |
| Server login works, but clone or fetch fails | Server to repository | Forge’s server SSH key | The provider account or target repository deploy-key record |
| Verbose output shows a missing identity file | Either hop; the client did not find the configured key | The file path and user/agent context | None until the intended key is available |
| Verbose output shows “Offering public key” followed by rejection | The destination rejected a presented key | The offered key’s fingerprint | Register that exact public key for the correct account or repository |
| Forge marks the server revoked | Forge server connection state | The public key returned by the reconnect operation | Install the returned key, then reactivate the server |
Common scenarios and precise responses
“I can SSH to GitHub, but Forge deployments fail.”
Your workstation’s successful GitHub test proves only that your computer has a key accepted by GitHub. Forge deploys from the server, which has its own server key. Add that Forge key to the repository or connected provider account with the required read access, then test from the server’s deployment environment.
“I added my personal key to Forge, but the deployment still fails.”
Personal workstation keys and Forge server deploy keys serve different hops. A personal key in the server’s SSH Keys list can fix your login, but it does not authorize Forge’s server key at the repository provider. Identify and register the key Forge actually uses for repository access.
“The key exists, yet SSH says permission denied.”
Use the fingerprint and verbose output to verify that the existing key is the one being offered. Check the SSH username and host, avoid switching between normal and elevated users, and confirm that the public key is authorized for the exact server account or repository. Existence on disk alone does not grant access.
“A deployment started failing after server maintenance.”
Retest both hops. If Forge reports the server as revoked, follow the reconnect-and-reactivate flow and install the public key returned by Forge. If the server remains active, compare the offered key with the provider’s deploy-key record and repair only the relationship that is rejecting it.
Quick wins for a faster PC:
Repair Windows errors before they cause bigger problemsFix Now →Scan for outdated or missing drivers - takes under a minuteDriver Scan →Clear out junk files and repair common Windows errorsFree Scan →Pre-deployment verification checklist
- Record which hop failed before changing credentials.
- Run the appropriate verbose command:
ssh -v user@serverfor server access orssh -vT git@github.comfor GitHub repository access. - Confirm the expected identity file is present and, when using an agent, visible with
ssh-add -l -E sha256. - Use the provider’s required SSH host and the
gitusername for repository URLs. - Keep workstation-to-server authorization separate from Forge-to-repository deploy-key authorization.
- Register the public half of the exact key being offered, never the private key.
- Run commands under the same operating-system user used by the deployment; do not mix
sudoand normal-user key stores. - For revoked servers, install the key returned by Forge’s reconnect operation before reactivation.
Once each trust relationship has been tested independently and the corresponding public key is registered at the correct destination, the generic Permission denied (publickey) message becomes a specific, fixable configuration problem rather than a reason to regenerate every key.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
