Unable to push to 'REMOTE' - Unknown error

Marcool04 commented 1 year ago

Hi all.

I'm mostly creating this issue to ask kindly if anybody can help with debugging a problem I'm having in Gittyup which could, I'm afraid, very well have nothing to do with the application itself...

This is about a repo for which git push works fine when I do it at the command line, but which fails with the rather uninformative error: Unable to push to 'REMOTE' - Unknown error in Gittyup.

The particularity with this repo, maybe, is that it has 3 remotes configures. The config file is like this:

[core]
    repositoryformatversion = 0
    filemode = true
    bare = false
    logallrefupdates = true
[branch "master"]
    remote = archpi
    merge = refs/heads/master
[remote "amu"]
    url = https://github.com/SCD-Aix-Marseille-Universite/latexamu
    fetch = +refs/heads/*:refs/remotes/amu/*
[remote "gitlab"]
    url = ssh://gitlab.com:/Marcool04/REPO.git
    fetch = +refs/heads/*:refs/remotes/gitlab/*
[remote "archpi"]
    url = ssh://archpi:/home/mark/git/these
    fetch = +refs/heads/*:refs/remotes/archpi/*
[gui]
    wmstate = normal
    geometry = 1920x961+0+0 179 212

This is the latex source for a PhD thesis. I pulled it from the university repo, which is called amu, then I have two remotes, one on my own homeserver, archpi, the other on Gitlab. Note that archpi, as well as a remote name in this git repo, is an SSH alias to the homeserver.

Could anybody please help me to debug this? I can quite easily see this being an issue with my own setup or the repo, but I can't see how to get Gittyup to help me help myself...

Thanks a lot in advance. Regards, Mark.

PS : here is some more system info, this is Archlinux on a Lenovo T480 Thinkpad.

# uname -a
Linux t480 6.2.13-arch1-1 #1 SMP PREEMPT_DYNAMIC Wed, 26 Apr 2023 20:50:14 +0000 x86_64 GNU/Linux

# pacman -Qi gittyup 
Name            : gittyup
Version         : 1.3.0-1

# pacman -Qi qt5-base
Name            : qt5-base
Version         : 5.15.9+kde+r151-1

# pacman -Qi git
Name            : git
Version         : 2.40.1-1

Murmele commented 1 year ago

Hi @Marcool04 thanks for the description! Can you try to use push to... functionality to find out to which remote it is not possible to push?

I see you don't have a "origin" remote. I will check the code if this might be the problem.

Marcool04 commented 1 year ago

Hi @Murmele, thanks for getting back to me so quickly. So, it is definitely just the archpi remote that is having problems. I can push to gitlab.com.

This is interesting, because the two remotes are so similar that this eliminates quite a few possible variables. Basically, the only two differences left are:

the homeserver remote uses an SSH alias, not a domain, whereas gitlab.com is a resolvable domain name;
the homeserver ssh server is listening on a non-default port (to reduce noise from bots trying to connect).

Note that both have configuration set up in .ssh/config, and that I have set the correct file path in Gittyup options to indicate where that file is. My access to gitlab is such that if the configuration from .ssh/config wasn't being read, then I would not have been able to push there either, as it uses, among other options, a non-default ssh private key.

I also verified that renaming the remote to origin made no difference...

Marcool04 commented 1 year ago

Ahah!

I think I have a smoking gun. When I attempt to push from Gittyup, I get this in the homeserver logs:

userauth_pubkey: signature algorithm ssh-rsa not in PubkeyAcceptedAlgorithms [preauth]

So what is PubkeyAcceptedAlgorithms set to? On the server we have:

# sshd -T | rg pubkeyacceptedalgorithms
pubkeyacceptedalgorithms ssh-ed25519-cert-v01@openssh.com,ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,sk-ssh-ed25519-cert-v01@openssh.com,sk-ecdsa-sha2-nistp256-cert-v01@openssh.com,rsa-sha2-512-cert-v01@openssh.com,rsa-sha2-256-cert-v01@openssh.com,ssh-ed25519,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,sk-ssh-ed25519@openssh.com,sk-ecdsa-sha2-nistp256@openssh.com,rsa-sha2-512,rsa-sha2-256

And on the client machine:

$ ssh -G archpi | rg pubkeyacceptedalgorithms
pubkeyacceptedalgorithms ssh-ed25519-cert-v01@openssh.com,ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,sk-ssh-ed25519-cert-v01@openssh.com,sk-ecdsa-sha2-nistp256-cert-v01@openssh.com,rsa-sha2-512-cert-v01@openssh.com,rsa-sha2-256-cert-v01@openssh.com,ssh-ed25519,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,sk-ssh-ed25519@openssh.com,sk-ecdsa-sha2-nistp256@openssh.com,rsa-sha2-512,rsa-sha2-256

All of these are inspired by https://www.ssh-audit.com/hardening_guides.html

So this confirms that in some way, Gittyup is imposing its own algorithms for the SSH public key exchange, and this seems to be what is messing up the push.

Murmele commented 1 year ago

@Marcool04 thanks for the research, I will check it out

Marcool04 commented 1 year ago

I built Gittyup from source myself, and noticed that push/pull from my homeserver actually works fine. Therefore I believe this issue is in fact caused by the packaging toolchain I am using, which is this bash script:

pkgname=gittyup
pkgver=1.3.0
pkgrel=1
pkgdesc='Graphical Git client (GitAhead fork)'
url="https://murmele.github.io/${pkgname^}"
_url="https://github.com/Murmele/${pkgname^}"
arch=(x86_64)
license=(MIT)
depends=(cmark
         git
         hunspell
         libssh2
         lua
         lua-lpeg
         openssl
         qt5-base)
makedepends=(cmake
             libgnome-keyring
             ninja
             qt5-tools
             qt5-translations)
optdepends=('git-lfs: git-lfs support'
            'libgnome-keyring: for GNOME Keyring for auth credentials'
            'qt5-translations: translations')
source=("git+$_url.git#tag=${pkgname}_v$pkgver"
        "$pkgname-libgit2::git+https://github.com/stinb/libgit2.git" # a fork, not the official upstream!
        "$pkgname-scintillua::git+https://github.com/orbitalquark/scintillua.git"
        "$pkgname-lexilla::git+https://github.com/ScintillaOrg/lexilla.git"
        "$pkgname-zip::git+https://github.com/kuba--/zip.git")
sha256sums=('SKIP'
            'SKIP'
            'SKIP'
            'SKIP'
            'SKIP')

prepare() {
    cd "${pkgname^}"
    git submodule init
    git config submodule.dep/cmark/cmark.update none
    git config submodule.dep/git/git.update none
    git config submodule.dep/hunspell/hunspell.update none
    git config submodule.dep/libssh2/libssh2.update none
    git config submodule.dep/openssl/openssl.update none
    git config submodule.dep/libgit2/libgit2.url "$srcdir/$pkgname-libgit2"
    git config submodule.dep/scintillua/lexilla.url "$srcdir/$pkgname-lexilla"
    git config submodule.dep/scintillua/scintillua.url "$srcdir/$pkgname-scintillua"
    git config submodule.test/dep/zip.url "$srcdir/$pkgname-zip"
    git -c protocol.file.allow=always submodule update
}

build() {
    cmake \
        -G Ninja \
        -W no-dev \
        -D CMAKE_BUILD_TYPE=Release \
        -D CMAKE_INSTALL_PREFIX=/usr \
        -D CMAKE_INSTALL_DATADIR=share/$pkgname \
        -D ENABLE_REPRODUCIBLE_BUILDS=ON \
        -D BUILD_SHARED_LIBS=OFF \
        -D DEBUG_OUTPUT=OFF \
        -D USE_SYSTEM_CMARK=ON \
        -D USE_SYSTEM_GIT=ON \
        -D USE_SYSTEM_HUNSPELL=ON \
        -D USE_SYSTEM_LIBSSH2=ON \
        -D USE_SYSTEM_LUA=ON \
        -D USE_SYSTEM_OPENSSL=ON \
        -D LUA_MODULES_PATH=/usr/lib/lua/5.4 \
        -B build \
        -S "${pkgname^}"
    ninja -C build
}

check() {
    ninja -C build check
}

package() {
    install -Dm0644 "${pkgname^}/LICENSE.md" "$pkgdir/usr/share/licenses/$pkgname/LICENSE"
    install -Dm0644 "${pkgname^}/rsrc/linux/com.github.Murmele.Gittyup.desktop" "$pkgdir/usr/share/applications/gittyup.desktop"
    DESTDIR="$pkgdir" ninja -C build install
    pushd "$pkgdir/usr"
    rm -f lib/libQt*.so.* lib/*.a
    rm -rf include lib/{cmake,pkgconfig,Plugins}
    mv bin/{indexer,relauncher} "share/$pkgname"
}

from the Arch User Repository (AUR) here: https://aur.archlinux.org/packages/gittyup.

What the packager is trying to do as far as I can gather, is integrate the build with system packages as much as possible, hence the removal of most of the git sub-modules. It doesn't seem obvious to me why this packaging would cause the default ssh signature algorithm to be different but that seems to be the case.

I've posted a comment against the AUR package anyhow. Closing this now, but I'd be interested to read your input on the above packaging script, if you have a second. Best, Mark.

Murmele commented 1 year ago

@exactly-one-kas do you know anything about?

Murmele / Gittyup

Unable to push to 'REMOTE' - Unknown error #543