Repository navigation
Troubleshooting
Start with Test on the account (Git accounts page) or Test login on the server (Hosts page). The message tells you which section below applies.
The server didn't accept any key Lanyard's config offered. Check, in order:
- The public key is registered with this account. Account's ⋯ → Copy public key, and compare it with the keys in the provider's settings. A key added to your work account won't log you in as personal.
-
The right account is active, or the remote uses the account's alias. Run
git remote -v:git@github.com:uses the active account,git@github.com-personal:always uses personal. - A passphrase-protected key is loaded. Keys with a passphrase must be in the ssh-agent, or SSH has to prompt for the passphrase, which Test can't do.
- The key file's permissions. See Bad permissions below.
To see exactly what SSH tries, run ssh -vT git@github.com.
The server accepted the connection but doesn't know the key. Hugging Face answers this way (Hi anonymous). Add the public key to the account's SSH key settings, then test again.
Two separate things decide who you are:
- Who pushes is the SSH key, chosen by the active account or the alias in the remote URL.
-
Who authored a commit is
git config user.name/user.email, chosen when the commit is made.
Turn on Set the global git identity when this account becomes active for the account (⋯ → Edit), or point the repository at the account with Clone / switch a repository, which also sets the repository's own name and email. Commits you already made keep their old author.
Git hosts accept git commands but give you no shell, so Connect doesn't apply to them. Lanyard shows Test (ssh -T) for git hosts instead.
On Windows the agent is a service that is disabled by default. In PowerShell as Administrator:
Get-Service ssh-agent | Set-Service -StartupType Automatic
Start-Service ssh-agentmacOS and Linux: see ssh-agent.
Load the key into the agent once: Keys page → key's ⋯ → Add to ssh-agent.
The server's key doesn't match ~/.ssh/known_hosts. If you know why (a reinstall, or an announced key rotation), forget the host and trust it again: Known hosts. If you don't know why, don't connect.
OpenSSH refuses private keys other users can read. Keys page → key's ⋯ → Restrict permissions to you (or lanyard keys fix-perms <key>).
The block between the lanyard managed section markers is regenerated from your accounts on every change. Put your own settings outside the markers, or change the account in Lanyard. See How it works.
Use Raw config → Validate on the Hosts page to see the error. To roll back a change, open Backups and restore the previous version.
The installer isn't code-signed yet. Click More info → Run anyway. Compare the file with SHA256SUMS.txt from the release if you want to check it first:
Get-FileHash .\Lanyard-Setup-*.exe -Algorithm SHA256The app isn't notarized yet. Right-click it in Applications → Open. If macOS still refuses:
xattr -dr com.apple.quarantine /Applications/Lanyard.app- The desktop app doesn't install the command. Install it with npm (Node.js 20+):
npm install -g lanyard-cli. - After installing, open a new terminal; terminals opened earlier keep the old PATH.
- Without installing anything:
npx lanyard-cli status.
That's the tray. Right-click the tray icon → Quit Lanyard, or turn off Keep running in the tray when closed in Settings.
Open an issue with the Lanyard version (Settings → About), your OS, and the output of ssh -vT <host>. Remove anything private from the output first.
This wiki is generated from docs/wiki in the repository. To suggest a change, edit the file there and open a pull request.
Start
Using the app
- Git accounts
- Hosts (remote servers)
- Keys
- ssh-agent
- Known hosts
- Backups
- Settings
- Tray, palette and shortcuts
Reference