SSH Access

CodeFloe’s Git over SSH is reached at git@codefloe.com on the default SSH port (22).

Recommended SSH configuration

Add a host stanza for codefloe.com to your ~/.ssh/config so your SSH client always offers the correct key and does not walk through every key loaded in your agent:

Host codefloe.com
  HostName codefloe.com
  User git
  IdentityFile ~/.ssh/your_codefloe_key
  IdentitiesOnly yes

Replace ~/.ssh/your_codefloe_key with the path to the private key whose public counterpart you uploaded under Settings → SSH Keys.

IdentitiesOnly yes is the important part — without it, OpenSSH offers every key the agent has loaded, one by one. The troubleshooting section below explains why that matters.

Troubleshooting

Not allowed at this time / Connection closed by … port 22

You may see one of the following when pushing or fetching:

kex_exchange_identification: banner line 0: Not allowed at this time
kex_exchange_identification: Connection closed by remote host
Connection closed by <ip> port 22
fatal: Could not read from remote repository.

This is a pre-authentication rate-limit on the SSH server, not an outage and not a key or permission problem. DNS still resolves, port 22 is reachable, but the server closes the connection during the protocol banner exchange.

The most common cause is that ssh-agent has several keys loaded and your SSH client offers all of them on every connection. The server’s brute-force protection counts each offered key as a failed attempt and temporarily refuses further connections from your IP. Once the temporary block expires (typically a few minutes), behaviour returns to normal — but the next plain git push will repeat the pattern.

Fix it permanently by adding the stanza from Recommended SSH configuration so only your CodeFloe key is offered, then wait for the current block to lapse and try again.

Verifying the right key is in use

A one-off connectivity check that bypasses the agent and only offers a specific key:

ssh -i ~/.ssh/your_codefloe_key -o IdentitiesOnly=yes -T git@codefloe.com

A successful authentication responds with:

Hi there, <username>! You've successfully authenticated with the key named <name>, but Forgejo does not provide shell access.

If you see this banner, your key is configured correctly on the server side — any later failures are then about your local client configuration (typically the multi-key situation described above).