Did something change on gate.opensuse.org ?
Hi, 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> % 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? Ciao, Michael.
Am Thu, 21 Oct 2021 15:20:42 +0000 (UTC)
schrieb Michael Matz
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
Hi, so, just for posterity for others on this list: On Thu, 21 Oct 2021, Lars Vogdt wrote:
Something from RPM changelog, that might be worth a 2nd look? * This release disables RSA signatures using the SHA-1 hash algorithm by default.
Yeah, this is it. Unfortunately I'm constrained on the hosts from which I need to connect to that machine for the data syncing, so we needed to enable the old signature algos again, by adding this to sshd_config: HostkeyAlgorithms +ssh-rsa PubkeyAcceptedAlgorithms +ssh-rsa It's not exactly wonderful, but gcc-stats is basically only a data container for gcc.opensuse.org without any further services or influences, so somebody investing $50k and time to crack the ssh key should perhaps rather simply ask me and donate the money to openSUSE :-) Thanks Lars for the quick with the above. Ciao, Michael.
Am Mon, 25 Oct 2021 13:01:28 +0000 (UTC)
schrieb Michael Matz
It's not exactly wonderful, but gcc-stats is basically only a data container for gcc.opensuse.org without any further services or influences, so somebody investing $50k and time to crack the ssh key should perhaps rather simply ask me and donate the money to openSUSE :-)
Well: the main problem I have with such statements: the data itself will not be interesting for the attacker, but the host's resources will. And if (s)he could use the resources to attack other machines, it might become a problem for openSUSE hosting an attacker bot(net). Even if it's just the bad press: something like this is what we want to avoid. So please everyone: keep your environment safe for our all safety. Regards, Lars
participants (2)
-
Lars Vogdt -
Michael Matz