Network is unreachable when using myrepos (mr) #730

Open
opened 3 weeks ago by manheraz · 8 comments

I use myrepos to manage my local and remote repositories hosted on Codeberg.

I work with multiple computers, so the first thing I do is update all my local repositories from Codeberg with mr update, which executes git pull for each repository.

Two weeks ago, myrepos stopped working: it can update a few repositories (four or so) but the following ones return this error:

ssh: connect to host codeberg.org port 22: Network is unreachable
fatal: Could not read from remote repository.

It looks like there is a SSH connetion limit defined in the Codeberg servers.

If that's the case, could you please relax it a bit?

Thank you in advance.

Manuel

I use [myrepos](https://myrepos.branchable.com) to manage my local and remote repositories hosted on Codeberg. I work with multiple computers, so the first thing I do is update all my local repositories from Codeberg with `mr update`, which executes `git pull` for each repository. Two weeks ago, myrepos stopped working: it can update a few repositories (four or so) but the following ones return this error: ``` ssh: connect to host codeberg.org port 22: Network is unreachable fatal: Could not read from remote repository. ``` It looks like there is a SSH connetion limit defined in the Codeberg servers. If that's the case, could you please relax it a bit? Thank you in advance. Manuel
Poster

Workaround: I found that I have to wait a bit more than six seconds (it won't work with less waiting time) between each git pull.

This can be acomplished adding something like this to the myrepos configuration:

[DEFAULT]
git_update =
    git pull "$@"
    BRANCH="$(git branch --show-current)"
    REMOTE="$(git branch --list "$BRANCH" --format="%(upstream:remotename)")"
    if git remote get-url "$REMOTE" | grep -iq "git@codeberg.org"; then sleep 6.1; fi

This will apply the delay to the Codeberg repositories using SSH.

So this is clearly a restriction configured in the Codeberg servers.

I'd prefer not being forced to wait between each git pull, but I suppose this is a measure to protect the Codeberg services.

No problem with this, but it would be nice if this is documented somewhere.

Thanks!

EDIT: Improved the workaround.

**Workaround**: I found that I have to wait a bit more than six seconds (it won't work with less waiting time) between each `git pull`. This can be acomplished adding something like this to the myrepos configuration: ``` [DEFAULT] git_update = git pull "$@" BRANCH="$(git branch --show-current)" REMOTE="$(git branch --list "$BRANCH" --format="%(upstream:remotename)")" if git remote get-url "$REMOTE" | grep -iq "git@codeberg.org"; then sleep 6.1; fi ``` This will apply the delay to the Codeberg repositories using SSH. So this is clearly a restriction configured in the Codeberg servers. I'd prefer not being forced to wait between each `git pull`, but I suppose this is a measure to protect the Codeberg services. No problem with this, but it would be nice if this is documented somewhere. Thanks! EDIT: Improved the workaround.
Collaborator

Well, rate limiting is usually very dynamic and will surely be adapted to real threats and experiences in the future. I don't even think there is a special config for this on our side, it might even be restricted by debian defaults.

We can consider to relax this a bit. I suppose this issue would not occur with session muxing (only one SSH connection), if this is possible?

Well, rate limiting is usually very dynamic and will surely be adapted to real threats and experiences in the future. I don't even think there is a special config for this on our side, it might even be restricted by debian defaults. We can consider to relax this a bit. I suppose this issue would not occur with session muxing (only one SSH connection), if this is possible?
Poster

Well, rate limiting is usually very dynamic and will surely be adapted to real threats and experiences in the future. I don't even think there is a special config for this on our side, it might even be restricted by debian defaults.

But something has changed, because a few weeks ago, myrepos worked without workarounds.

We can consider to relax this a bit. I suppose this issue would not occur with session muxing (only one SSH connection), if this is possible?

I'm not sure how myrepos works internally, but I can do some tests and report back.

Thanks!

> Well, rate limiting is usually very dynamic and will surely be adapted to real threats and experiences in the future. I don't even think there is a special config for this on our side, it might even be restricted by debian defaults. But something has changed, because a few weeks ago, myrepos worked without workarounds. > We can consider to relax this a bit. I suppose this issue would not occur with session muxing (only one SSH connection), if this is possible? I'm not sure how myrepos works internally, but I can do some tests and report back. Thanks!
Collaborator

We don't know of recent changes in our infrastructure that could have changed the behaviour. The configuration was not touched by us :)

We don't know of recent changes in our infrastructure that could have changed the behaviour. The configuration was not touched by us :)
Poster

Well, it seems something is blocking the SSH connections when they are made in a short time period.

A quick test without using git or myrepos, just the SSH client:

for i in $(seq 1 20); do
    ssh -T git@codeberg.org;
done

And this is the result:

Hi there, ******! You've successfully authenticated with the key named ******, but Gitea does not provide shell access.
If this is unexpected, please log in with password and setup Gitea under another user.

Hi there, ******! You've successfully authenticated with the key named ******, but Gitea does not provide shell access.
If this is unexpected, please log in with password and setup Gitea under another user.

Hi there, ******! You've successfully authenticated with the key named ******, but Gitea does not provide shell access.
If this is unexpected, please log in with password and setup Gitea under another user.

Hi there, ******! You've successfully authenticated with the key named ******, but Gitea does not provide shell access.
If this is unexpected, please log in with password and setup Gitea under another user.

Hi there, ******! You've successfully authenticated with the key named ******, but Gitea does not provide shell access.
If this is unexpected, please log in with password and setup Gitea under another user.

ssh: connect to host codeberg.org port 22: Network is unreachable
ssh: connect to host codeberg.org port 22: Network is unreachable
ssh: connect to host codeberg.org port 22: Network is unreachable
ssh: connect to host codeberg.org port 22: Network is unreachable
ssh: connect to host codeberg.org port 22: Network is unreachable
ssh: connect to host codeberg.org port 22: Network is unreachable
ssh: connect to host codeberg.org port 22: Network is unreachable
ssh: connect to host codeberg.org port 22: Network is unreachable
ssh: connect to host codeberg.org port 22: Network is unreachable
ssh: connect to host codeberg.org port 22: Network is unreachable
ssh: connect to host codeberg.org port 22: Network is unreachable
ssh: connect to host codeberg.org port 22: Network is unreachable
ssh: connect to host codeberg.org port 22: Network is unreachable
ssh: connect to host codeberg.org port 22: Network is unreachable
ssh: connect to host codeberg.org port 22: Network is unreachable
Well, it seems something is blocking the SSH connections when they are made in a short time period. A quick test without using git or myrepos, just the SSH client: ```shell for i in $(seq 1 20); do ssh -T git@codeberg.org; done ``` And this is the result: ``` Hi there, ******! You've successfully authenticated with the key named ******, but Gitea does not provide shell access. If this is unexpected, please log in with password and setup Gitea under another user. Hi there, ******! You've successfully authenticated with the key named ******, but Gitea does not provide shell access. If this is unexpected, please log in with password and setup Gitea under another user. Hi there, ******! You've successfully authenticated with the key named ******, but Gitea does not provide shell access. If this is unexpected, please log in with password and setup Gitea under another user. Hi there, ******! You've successfully authenticated with the key named ******, but Gitea does not provide shell access. If this is unexpected, please log in with password and setup Gitea under another user. Hi there, ******! You've successfully authenticated with the key named ******, but Gitea does not provide shell access. If this is unexpected, please log in with password and setup Gitea under another user. ssh: connect to host codeberg.org port 22: Network is unreachable ssh: connect to host codeberg.org port 22: Network is unreachable ssh: connect to host codeberg.org port 22: Network is unreachable ssh: connect to host codeberg.org port 22: Network is unreachable ssh: connect to host codeberg.org port 22: Network is unreachable ssh: connect to host codeberg.org port 22: Network is unreachable ssh: connect to host codeberg.org port 22: Network is unreachable ssh: connect to host codeberg.org port 22: Network is unreachable ssh: connect to host codeberg.org port 22: Network is unreachable ssh: connect to host codeberg.org port 22: Network is unreachable ssh: connect to host codeberg.org port 22: Network is unreachable ssh: connect to host codeberg.org port 22: Network is unreachable ssh: connect to host codeberg.org port 22: Network is unreachable ssh: connect to host codeberg.org port 22: Network is unreachable ssh: connect to host codeberg.org port 22: Network is unreachable ```
Poster

This could be the default UFW rate limit (ufw limit ssh)

From the man page:

ufw supports connection rate limiting, which is useful for protecting against brute-force login attacks. When a limit rule is used, ufw will normally allow the connection but will deny connections if an IP address attempts to initiate 6 or more connections within 30 seconds.

But this wasn't configured a few weeks ago.

This could be the default UFW rate limit (`ufw limit ssh`) From the man page: > ufw supports connection rate limiting, which is useful for protecting against brute-force login attacks. When a limit rule is used, ufw will normally allow the connection but will deny connections if an IP address attempts to initiate 6 or more connections within 30 seconds. But this wasn't configured a few weeks ago.
Poster

This would explain the sleep time between SSH connections: with six seconds or less, it fails at the fifth attempt. When using more than six seconds, it works, because it never does six or more connection attempts in 30 seconds.

This would explain the sleep time between SSH connections: with six seconds or less, it fails at the fifth attempt. When using more than six seconds, it works, because it never does six or more connection attempts in 30 seconds.
Poster

@fnetX could you please confirm my findings?

I improved the workaround. Now it only applies to Codeberg repositories using SSH.

@fnetX could you please confirm my findings? I improved the workaround. Now it only applies to Codeberg repositories using SSH.
Sign in to join this conversation.
No Milestone
No Assignees
2 Participants
Notifications
Due Date

No due date set.

Dependencies

No dependencies set.

Reference: Codeberg/Community#730
Loading…
There is no content yet.