Am Thu, 21 Oct 2021 15:20:42 +0000 (UTC) schrieb Michael Matz <matz@suse.de>:
since $forever we use a rsync cron job to push data for gcc.opensuse.org to it, essentially via:
% RSYNC_RSH='ssh -p2271' rsync -av --filter='dir-merge dontsync' --delete-after ./ gcc@gate.opensuse.org:gcc.opensuse.org/
(from a machine within the SUSE engineering network). Since yesterday night that doesn't work anymore:
% ssh -p2271 -v gcc@gate.opensuse.org ... debug1: Connecting to gate.opensuse.org [2001:67c:2178:8::28] port 2271. <timeout>
I did the usual maintenance on both machines yesterday (kernel update on scar, "zypper dup" on gcc-stats.
% ssh -p2271 -v -4 gcc@gate.opensuse.org ... [connection works] debug1: kex: server->client aes128-ctr hmac-sha1 none debug1: kex: client->server aes128-ctr hmac-sha1 none no hostkey alg % # back to local shell here
With rsync (and forcing ipv4 to not run into the timeout) I also get the "no hostkey alg" message, and no rsyncing done, of course.
So, was the VM behind port 2271 somehow changed? Anything I need to do here to get back in?
gcc-stats is on: VERSION_ID="20211016" PRETTY_NAME="openSUSE Tumbleweed" openssh-server-8.8p1-1.1.x86_64 On scar, I see something like: Oct 21 15:07:35 scar xinetd[13633]: START: ssh-openqa from=91.22.69.88 Oct 21 15:07:36 scar xinetd[13633]: EXIT: ssh-openqa status=0 duration=1(sec) Oct 21 15:16:56 scar xinetd[13633]: START: ssh-gcc-stats from=195.135.221.27 Oct 21 15:16:56 scar xinetd[13633]: EXIT: ssh-gcc-stats status=0 duration=0(sec) So it seems to work for openqa - and I guess it should also work for gcc-stats. Something from RPM changelog, that might be worth a 2nd look? * This release disables RSA signatures using the SHA-1 hash algorithm by default. This change has been made as the SHA-1 hash algorithm is cryptographically broken, and it is possible to create chosen-prefix hash collisions for <USD$50K. For most users, this change should be invisible and there is no need to replace ssh-rsa keys. OpenSSH has supported RFC8332 RSA/SHA-256/512 signatures since release 7.2 and existing ssh-rsa keys will automatically use the stronger algorithm where possible. Incompatibility is more likely when connecting to older SSH implementations that have not been upgraded or have not closely tracked improvements in the SSH protocol. For these cases, it may be necessary to selectively re-enable RSA/SHA1 to allow connection and/or user authentication via the HostkeyAlgorithms and PubkeyAcceptedAlgorithms options. Sorry, Lars