We're in closed beta. Sign up for early access — founding pricing locks in at signup, for as long as your subscription stays active.
Set up an SSH key once, then clone, push, and pull without typing credentials.
ssh-keygen -t ed25519 -C "[email protected]", then add the public key under Settings → SSH Keys.[email protected]:owner/repo.git remotes.ssh -T [email protected] — a successful authentication looks like a message telling you shell access isn't provided, not an error about your key.If you don't already have an SSH key, generate an Ed25519 key pair — it's shorter and faster to verify than RSA, and is UnityFreak's recommended type:
ssh-keygen -t ed25519 -C "[email protected]"Accept the default file location unless you have a reason not to. This creates two files — a private key (never share this) and a .pub public key file, which is the one you add to UnityFreak.
Open Settings → SSH Keys and paste the contents of your .pub file into the Key field, then give it a Title so you can identify which machine it belongs to later (e.g. "My laptop") and click Add SSH Key.
Once added, SSH access to your repositories uses [email protected]:owner/repo.git remotes — no password or token needed for the rest of that key's lifetime.
Verify your key is registered and working with:
ssh -T [email protected]UnityFreak's SSH endpoint only ever serves Git operations, so a bare -T connection with no git command attached doesn't drop you into a shell. A successful authentication looks like a message explaining that shell access isn't provided and that the account only serves Git over SSH — seeing that message (rather than a permission or key error) means your key was recognized and the connection worked. From there, a real git clone [email protected]:owner/repo.git exercises the full path.
Prefer not to manage SSH keys — or working somewhere SSH ports are blocked? Clone and push over HTTPS instead, authenticating with a personal access token in place of a password. This is the same style of credential used for importing a repository from another host. Generate and manage your tokens under Settings → Personal Access Tokens, and use the token as the password when Git prompts for credentials over HTTPS.
Token expiry. A token you create in the web app expires after 90 days unless you choose another length — or, deliberately, No expiration — when you create it (the Clone button's one-click token and the Personal Access Tokens page both offer the choice). If your account email is verified we send one reminder email ahead of the deadline, and you get an in-app notice either way; a token whose whole lifetime is no longer than the reminder window (7 days by default) is not reminded about. When a token does expire, create a replacement and update wherever the old one was stored. Tokens you created before this change keep exactly the expiry they had, which for most of them is none.
Permission denied (publickey). The most common causes are that the key you added under Settings → SSH Keys isn't the one your local Git client is actually presenting, or that the wrong key is being offered first when you have several. Confirm which key SSH is using with ssh -Tv [email protected] (the verbose output lists every key it tries), and double-check the public key you pasted into the app matches your local private key's pair.
Could not open a connection to your authentication agent. Your SSH agent isn't running, or your key hasn't been added to it. Start the agent and add your key before retrying:
eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519This SSH key is not allowed by your organization's security policy. An organization you belong to restricts which key types may be used over SSH, and this key's type is not on its list. See the next section for the quick fix.
UnityFreak recommends Ed25519 keys and accepts RSA keys of 2048 bits or more (signed with SHA-2), plus ECDSA keys. The obsolete SHA-1 RSA signature is not accepted for anyone. Organizations on the Enterprise plan can go further and allow only the key types they choose, for example Ed25519 only.
How a restriction rolls out. An admin announces it with an enforcement date (always shown in UTC), at least 14 days ahead. You get an email and an in-app notification, and Settings → SSH Keys marks every key that will stop working, with the date. Until that date your keys keep working and git prints a warning when you connect. From the date on, the restriction applies to every key on your account, including keys you added long ago and keys you already had when you joined the organization. There are no exceptions after the date.
It covers SSH to every repository, not just that organization's. An SSH key belongs to your account, so once a restriction is in force a key it refuses stops working over SSH for all of your repositories, including your personal ones and those of other organizations. Git over HTTPS with a personal access token keeps working everywhere.
If more than one organization restricts keys, the strictest rule wins: a key must be allowed by every organization whose restriction is already in force.
A new key added while a restriction is announced. The add-key form checks a new key against the types the organization will allow from the enforcement date, so it never lets you add to the problem. If an organization is moving from one set of types to another (for example from RSA only to Ed25519 only), a new Ed25519 key is accepted when you add it, but until the enforcement date the organization still enforces its previous setting. SSH refuses that new key until then and it starts working on the enforcement date. Git over HTTPS with a personal access token works in the meantime.
The fix. Create an Ed25519 key and add it under Settings → SSH Keys:
ssh-keygen -t ed25519 -C "[email protected]"Nothing else is affected. Git over HTTPS with a personal access token is never restricted by a key policy, so you can keep working while you switch keys. The restriction is about the key type only: it does not change your account, your permissions, or the web app.
Deploy keys on an organization's repositories follow that organization's key policy and the same enforcement date; deploy keys on personal repositories are not affected. The organization's IP allowlist does not apply to deploy keys, because automation has no fixed address.