Das längste Thema

nitram

Schau mal mit

Code

ssh -Q key

welche Algos verfügbar sind.

Hast du was in /etc/ssh/ssh_config oder ~/.username/config z.B mit

Code

HostKeyAlgorithms 
PubkeyAcceptedKeyTypes

irgendwas limitiert?

aRaphael

Zitat von nitram

Schau mal (...) welche Algos verfügbar sind.

Ist auf den Servern identisch

Zitat von nitram

Hast du was in /etc/ssh/ssh_config oder ~/.username/config z.B (...) irgendwas limitiert?

Nein

Der einzige Unterschied scheint zu sein, dass auf dem Server, auf dem es nicht geht, eine neuere Version von openssh installiert ist

Aber mit der Option geht es ja nun

Im Übrigen geht es ohne die Option durchaus anderswohin. Nur die Verbindung zum netcup ftp-Server macht diese "Probleme".

KB19

Zitat von aRaphael

Ich habe gerade versucht einen snapshot auf einen (neuen) Server herunter zu laden, aber da kam:

Unable to negotiate with 46.38.225.190 port 2222: no matching host key type found. Their offer: ssh-rsa,ssh-dss

[…]

EDIT:

OK. Selbst gefunden. (Google ist dein Freund )

Mit dieser zusätzlichen scp-Option funktioniert es:

-o HostKeyAlgorithms=ssh-dss

[…]

Alles anzeigen

[netcup] Lars S. *ping*

Vielleicht wären da neuere Hostkeys angebracht?

OpenSSH 8.2 unter Ubuntu 20.04 unterstützt definitiv mehr.

**[netcup] Lars S.**

Hallo KB19,

danke für deinen Hinweis.

Ich habe das Thema an die zuständige Abteilung weitergeleitet, damit es dort geprüft und gelöst werden kann.

mainziman

Moderatoren

es scheint ein seltsames Routing-Problem zu geben

2 vServer, einer hier in Nürnberg [shinkansen.host] und einer in bei jemand anders in Wien [6in4gate.tunnel]

einmal IPv4/IPv6 von Wien [6in4gate.tunnel] nach Nürnberg [shinkansen.host] - das passt

traceroute[6] -I shinkansen.host

Code

[root@6in4gate ~]# traceroute -I shinkansen.host
traceroute to shinkansen.host (194.55.15.x), 30 hops max, 60 byte packets
 1  gw101.core1.vie.alwyzon.net (46.102.157.65)  5.980 ms  5.983 ms  5.979 ms
 2  ae0.edge1.vie.alwyzon.net (46.102.157.10)  0.557 ms  0.567 ms  0.608 ms
 3  et-2-0-5-1337.bbr01.anx03.vie.at.anexia-it.net (193.203.0.19)  0.446 ms  0.451 ms  0.503 ms
 4  ae0-0.bbr02.anx03.vie.at.anexia-it.net (144.208.208.132)  9.388 ms  9.389 ms  9.411 ms
 5  ae1-0.bbr02.anx84.nue.de.anexia-it.net (144.208.208.137)  9.065 ms  9.064 ms  9.061 ms
 6  netcup-gw.bbr02.anx84.nue.de.anexia-it.net (144.208.211.11)  9.015 ms  10.005 ms  9.997 ms
 7  shinkansen.host (194.55.15.x)  10.041 ms  10.368 ms  10.576 ms
[root@6in4gate ~]# traceroute6 -I shinkansen.host
traceroute to shinkansen.host (2a03:4000:31:x::1), 30 hops max, 80 byte packets
 1  gw101.core1.vie.alwyzon.net (2a0d:f302:101::1)  15.824 ms  15.837 ms  15.778 ms
 2  ae0.edge1.vie.alwyzon.net (2a0d:f302:8:11::1)  0.271 ms  0.299 ms  0.300 ms
 3  et-2-0-5-1337.bbr01.anx03.vie.at.anexia-it.net (2001:7f8:30:0:1:1:4:7147)  0.588 ms  0.591 ms  0.590 ms
 4  2a00:11c0:47:1:47::132 (2a00:11c0:47:1:47::132)  0.540 ms  0.579 ms  0.577 ms
 5  2a00:11c0:47:1:47::137 (2a00:11c0:47:1:47::137)  9.023 ms  9.034 ms  9.030 ms
 6  2a00:11c0:47:3::33 (2a00:11c0:47:3::33)  11.941 ms  11.855 ms  11.843 ms
 7  shinkansen.host (2a03:4000:31:x::1)  9.262 ms  9.087 ms  9.093 ms
[root@6in4gate ~]#

Alles anzeigen

aber hier die andere Richtung von Nürnberg [shinkansen.host] nach Wien [6in4gate.tunnel], ebenfalls IPv4/IPv6

traceroute[6] -I 6in4gate.tunnel

Code

[root@shinkansen ~]# traceroute -I 6in4gate.tunnel
traceroute to 6in4gate.tunnel (46.102.157.x), 30 hops max, 60 byte packets
 1  194.55.12.2 (194.55.12.2)  0.506 ms  1.153 ms  1.506 ms
 2  ae3-4019.bbr02.anx84.nue.de.anexia-it.net (144.208.211.10)  1.677 ms  1.847 ms  2.007 ms
 3  ae2-0.bbr02.anx03.vie.at.anexia-it.net (144.208.208.136)  10.684 ms  11.087 ms  11.258 ms
 4  ae0-0.bbr01.anx03.vie.at.anexia-it.net (144.208.208.133)  10.147 ms  10.318 ms  10.858 ms
 5  vix.alwyzon.net (193.203.0.75)  9.299 ms  9.847 ms  10.479 ms
 6  ae19.core1.vie.alwyzon.net (46.102.157.11)  31.178 ms  28.883 ms  29.173 ms
 7  6in4gate.tunnel (46.102.157.x)  9.347 ms  9.010 ms  9.166 ms
[root@shinkansen ~]# traceroute6 -I 6in4gate.tunnel
traceroute to 6in4gate.tunnel (2a0d:f302:101:x::1), 30 hops max, 80 byte packets
 1  2a03:4000:31::2 (2a03:4000:31::2)  5.321 ms  5.298 ms  5.281 ms
 2  2a03:4000:ff00:4::4 (2a03:4000:ff00:4::4)  0.375 ms  0.386 ms  0.379 ms
 3  2a00:11c0:47:3::fa (2a00:11c0:47:3::fa)  66.031 ms  66.014 ms  65.994 ms
 4  2a00:11c0:47:1:47::138 (2a00:11c0:47:1:47::138)  0.373 ms  0.355 ms  0.310 ms
 5  2a00:11c0:47:1:47::136 (2a00:11c0:47:1:47::136)  9.150 ms  9.164 ms  9.160 ms
 6  2a00:11c0:47:1:47::133 (2a00:11c0:47:1:47::133)  9.155 ms  9.419 ms  9.401 ms
 7  vix.alwyzon.net (2001:7f8:30:0:2:1:4:994)  9.198 ms  9.181 ms  9.182 ms
 8  2a0d:f302:8:11:: (2a0d:f302:8:11::)  11.784 ms  58.969 ms  58.911 ms
 9  6in4gate.tunnel (2a0d:f302:101:x::1)  9.129 ms  9.058 ms  9.033 ms
[root@shinkansen ~]#

Alles anzeigen

hier passt das bei IPv6 nicht;

falls dies die selbe Ursache hat, iperf3 in Wien [6in4gate.tunnel] als Server gestartet

und iperf3 unterscheidet sich hier ebenfalls aber genau anders herum: bei IPv6 passt und bei IPv4 hackt es;

iperf3 [-4|-6] -c 6in4gate.tunnel -R

Code

[root@shinkansen ~]# iperf3 -4 -c 6in4gate.tunnel -R
Connecting to host 6in4gate.tunnel, port 5201
Reverse mode, remote host 6in4gate.tunnel is sending
[  4] local 194.55.15.x port 36128 connected to 46.102.157.x port 5201
[ ID] Interval           Transfer     Bandwidth
[  4]   0.00-1.00   sec  24.1 MBytes   202 Mbits/sec
[  4]   1.00-2.00   sec  24.3 MBytes   204 Mbits/sec
[  4]   2.00-3.00   sec  24.8 MBytes   208 Mbits/sec
[  4]   3.00-4.01   sec  25.4 MBytes   212 Mbits/sec
[  4]   4.01-5.01   sec  25.3 MBytes   213 Mbits/sec
[  4]   5.01-6.01   sec  21.6 MBytes   180 Mbits/sec
[  4]   6.01-7.00   sec  24.3 MBytes   206 Mbits/sec
[  4]   7.00-8.00   sec  29.3 MBytes   245 Mbits/sec
[  4]   8.00-9.01   sec  22.3 MBytes   186 Mbits/sec
[  4]   9.01-10.00  sec  23.6 MBytes   200 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-10.00  sec   247 MBytes   207 Mbits/sec   42             sender
[  4]   0.00-10.00  sec   245 MBytes   206 Mbits/sec                  receiver

iperf Done.
[root@shinkansen ~]# iperf3 -6 -c 6in4gate.tunnel -R
Connecting to host 6in4gate.tunnel, port 5201
Reverse mode, remote host 6in4gate.tunnel is sending
[  4] local 2a03:4000:31:x::1 port 49364 connected to 2a0d:f302:101:x::1 port 5201
[ ID] Interval           Transfer     Bandwidth
[  4]   0.00-1.00   sec  85.0 MBytes   713 Mbits/sec
[  4]   1.00-2.00   sec   105 MBytes   885 Mbits/sec
[  4]   2.00-3.00   sec   102 MBytes   857 Mbits/sec
[  4]   3.00-4.00   sec  83.0 MBytes   696 Mbits/sec
[  4]   4.00-5.00   sec  87.5 MBytes   734 Mbits/sec
[  4]   5.00-6.00   sec  91.3 MBytes   766 Mbits/sec
[  4]   6.00-7.00   sec  93.1 MBytes   781 Mbits/sec
[  4]   7.00-8.00   sec  95.2 MBytes   799 Mbits/sec
[  4]   8.00-9.00   sec  78.3 MBytes   657 Mbits/sec
[  4]   9.00-10.00  sec  72.7 MBytes   610 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-10.00  sec   897 MBytes   753 Mbits/sec  367             sender
[  4]   0.00-10.00  sec   895 MBytes   750 Mbits/sec                  receiver

iperf Done.
[root@shinkansen ~]#

Alles anzeigen

RAD750

Mainziman, du lebst? Schön, dass du wieder da bist 😊

ThomasChr

Jep, Willkommen zurück! 🦆

mainziman

Ja ich lebe, und die Welt hat Glück dass ich nur IT-Mensch bin und kein Jurist

ich würd die Betreiber von Sites die mit dem komischen Cookies-Zeugs daherkommen,

dazu zu verpflichten eine Palette Prinzenrolle [= Cookies] bei mir zu Hause abzuladen;

des Risiko, dass ma damit die Aussicht verstellt werden könnte nehme ich gerne in Kauf;

friend_of_root

Liebe Freunde.
Ich erlaube mir in unserem längsten Thread das Thema Snapshot sind nicht gut gelöst! zu verlinken, da es sicher im SCP Forum nicht ganz so viel Sichtbarkeit hat.
Ich bin ein wirklich weitgehend zufriedener Netcup Nutzer, aber ich finde es gibt da und dort Verbesserungen, die machbar sind und auf die wir als Community manchmal hinweisen sollten.

https://forum.netcup.de/netcup-anwendu…ut-gel%C3%B6st/

ThomasChr

Schade dass das auf dem Event keiner angesprochen hat. Ja, die Snapshots könnten viel besser gelöst sein!

KB19

Welcome back mainziman

michaeleifel

Zitat von ThomasChr

Schade dass das auf dem Event keiner angesprochen hat. Ja, die Snapshots könnten viel besser gelöst sein!

Das war definitv ein Thema auf dem Event, aber vermutlich dann eher Teil der ganzen Diskussionen / Gespräche die in Kreisen dort geführt worden. Auch ging es um die Cloud VLANs mit VPS, Migrationen von VMs, Storagespace, Automatischer Failober der IP wenn Healtcheck kaputt etc.

**[netcup] Lars S.**

Zitat von mainziman

Moderatoren

es scheint ein seltsames Routing-Problem zu geben

2 vServer, einer hier in Nürnberg [shinkansen.host] und einer in bei jemand anders in Wien [6in4gate.tunnel]

einmal IPv4/IPv6 von Wien [6in4gate.tunnel] nach Nürnberg [shinkansen.host] - das passt

traceroute[6] -I shinkansen.host

Code

[root@6in4gate ~]# traceroute -I shinkansen.host
traceroute to shinkansen.host (194.55.15.x), 30 hops max, 60 byte packets
 1  gw101.core1.vie.alwyzon.net (46.102.157.65)  5.980 ms  5.983 ms  5.979 ms
 2  ae0.edge1.vie.alwyzon.net (46.102.157.10)  0.557 ms  0.567 ms  0.608 ms
 3  et-2-0-5-1337.bbr01.anx03.vie.at.anexia-it.net (193.203.0.19)  0.446 ms  0.451 ms  0.503 ms
 4  ae0-0.bbr02.anx03.vie.at.anexia-it.net (144.208.208.132)  9.388 ms  9.389 ms  9.411 ms
 5  ae1-0.bbr02.anx84.nue.de.anexia-it.net (144.208.208.137)  9.065 ms  9.064 ms  9.061 ms
 6  netcup-gw.bbr02.anx84.nue.de.anexia-it.net (144.208.211.11)  9.015 ms  10.005 ms  9.997 ms
 7  shinkansen.host (194.55.15.x)  10.041 ms  10.368 ms  10.576 ms
[root@6in4gate ~]# traceroute6 -I shinkansen.host
traceroute to shinkansen.host (2a03:4000:31:x::1), 30 hops max, 80 byte packets
 1  gw101.core1.vie.alwyzon.net (2a0d:f302:101::1)  15.824 ms  15.837 ms  15.778 ms
 2  ae0.edge1.vie.alwyzon.net (2a0d:f302:8:11::1)  0.271 ms  0.299 ms  0.300 ms
 3  et-2-0-5-1337.bbr01.anx03.vie.at.anexia-it.net (2001:7f8:30:0:1:1:4:7147)  0.588 ms  0.591 ms  0.590 ms
 4  2a00:11c0:47:1:47::132 (2a00:11c0:47:1:47::132)  0.540 ms  0.579 ms  0.577 ms
 5  2a00:11c0:47:1:47::137 (2a00:11c0:47:1:47::137)  9.023 ms  9.034 ms  9.030 ms
 6  2a00:11c0:47:3::33 (2a00:11c0:47:3::33)  11.941 ms  11.855 ms  11.843 ms
 7  shinkansen.host (2a03:4000:31:x::1)  9.262 ms  9.087 ms  9.093 ms
[root@6in4gate ~]#

Alles anzeigen

aber hier die andere Richtung von Nürnberg [shinkansen.host] nach Wien [6in4gate.tunnel], ebenfalls IPv4/IPv6

traceroute[6] -I 6in4gate.tunnel

Code

[root@shinkansen ~]# traceroute -I 6in4gate.tunnel
traceroute to 6in4gate.tunnel (46.102.157.x), 30 hops max, 60 byte packets
 1  194.55.12.2 (194.55.12.2)  0.506 ms  1.153 ms  1.506 ms
 2  ae3-4019.bbr02.anx84.nue.de.anexia-it.net (144.208.211.10)  1.677 ms  1.847 ms  2.007 ms
 3  ae2-0.bbr02.anx03.vie.at.anexia-it.net (144.208.208.136)  10.684 ms  11.087 ms  11.258 ms
 4  ae0-0.bbr01.anx03.vie.at.anexia-it.net (144.208.208.133)  10.147 ms  10.318 ms  10.858 ms
 5  vix.alwyzon.net (193.203.0.75)  9.299 ms  9.847 ms  10.479 ms
 6  ae19.core1.vie.alwyzon.net (46.102.157.11)  31.178 ms  28.883 ms  29.173 ms
 7  6in4gate.tunnel (46.102.157.x)  9.347 ms  9.010 ms  9.166 ms
[root@shinkansen ~]# traceroute6 -I 6in4gate.tunnel
traceroute to 6in4gate.tunnel (2a0d:f302:101:x::1), 30 hops max, 80 byte packets
 1  2a03:4000:31::2 (2a03:4000:31::2)  5.321 ms  5.298 ms  5.281 ms
 2  2a03:4000:ff00:4::4 (2a03:4000:ff00:4::4)  0.375 ms  0.386 ms  0.379 ms
 3  2a00:11c0:47:3::fa (2a00:11c0:47:3::fa)  66.031 ms  66.014 ms  65.994 ms
 4  2a00:11c0:47:1:47::138 (2a00:11c0:47:1:47::138)  0.373 ms  0.355 ms  0.310 ms
 5  2a00:11c0:47:1:47::136 (2a00:11c0:47:1:47::136)  9.150 ms  9.164 ms  9.160 ms
 6  2a00:11c0:47:1:47::133 (2a00:11c0:47:1:47::133)  9.155 ms  9.419 ms  9.401 ms
 7  vix.alwyzon.net (2001:7f8:30:0:2:1:4:994)  9.198 ms  9.181 ms  9.182 ms
 8  2a0d:f302:8:11:: (2a0d:f302:8:11::)  11.784 ms  58.969 ms  58.911 ms
 9  6in4gate.tunnel (2a0d:f302:101:x::1)  9.129 ms  9.058 ms  9.033 ms
[root@shinkansen ~]#

Alles anzeigen

hier passt das bei IPv6 nicht;

falls dies die selbe Ursache hat, iperf3 in Wien [6in4gate.tunnel] als Server gestartet

und iperf3 unterscheidet sich hier ebenfalls aber genau anders herum: bei IPv6 passt und bei IPv4 hackt es;

iperf3 [-4|-6] -c 6in4gate.tunnel -R

Code

[root@shinkansen ~]# iperf3 -4 -c 6in4gate.tunnel -R
Connecting to host 6in4gate.tunnel, port 5201
Reverse mode, remote host 6in4gate.tunnel is sending
[  4] local 194.55.15.x port 36128 connected to 46.102.157.x port 5201
[ ID] Interval           Transfer     Bandwidth
[  4]   0.00-1.00   sec  24.1 MBytes   202 Mbits/sec
[  4]   1.00-2.00   sec  24.3 MBytes   204 Mbits/sec
[  4]   2.00-3.00   sec  24.8 MBytes   208 Mbits/sec
[  4]   3.00-4.01   sec  25.4 MBytes   212 Mbits/sec
[  4]   4.01-5.01   sec  25.3 MBytes   213 Mbits/sec
[  4]   5.01-6.01   sec  21.6 MBytes   180 Mbits/sec
[  4]   6.01-7.00   sec  24.3 MBytes   206 Mbits/sec
[  4]   7.00-8.00   sec  29.3 MBytes   245 Mbits/sec
[  4]   8.00-9.01   sec  22.3 MBytes   186 Mbits/sec
[  4]   9.01-10.00  sec  23.6 MBytes   200 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-10.00  sec   247 MBytes   207 Mbits/sec   42             sender
[  4]   0.00-10.00  sec   245 MBytes   206 Mbits/sec                  receiver

iperf Done.
[root@shinkansen ~]# iperf3 -6 -c 6in4gate.tunnel -R
Connecting to host 6in4gate.tunnel, port 5201
Reverse mode, remote host 6in4gate.tunnel is sending
[  4] local 2a03:4000:31:x::1 port 49364 connected to 2a0d:f302:101:x::1 port 5201
[ ID] Interval           Transfer     Bandwidth
[  4]   0.00-1.00   sec  85.0 MBytes   713 Mbits/sec
[  4]   1.00-2.00   sec   105 MBytes   885 Mbits/sec
[  4]   2.00-3.00   sec   102 MBytes   857 Mbits/sec
[  4]   3.00-4.00   sec  83.0 MBytes   696 Mbits/sec
[  4]   4.00-5.00   sec  87.5 MBytes   734 Mbits/sec
[  4]   5.00-6.00   sec  91.3 MBytes   766 Mbits/sec
[  4]   6.00-7.00   sec  93.1 MBytes   781 Mbits/sec
[  4]   7.00-8.00   sec  95.2 MBytes   799 Mbits/sec
[  4]   8.00-9.00   sec  78.3 MBytes   657 Mbits/sec
[  4]   9.00-10.00  sec  72.7 MBytes   610 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-10.00  sec   897 MBytes   753 Mbits/sec  367             sender
[  4]   0.00-10.00  sec   895 MBytes   750 Mbits/sec                  receiver

iperf Done.
[root@shinkansen ~]#

Alles anzeigen

Hallo mainziman,

vielen Dank für deinen Hinweis.

Bitte wende dich damit an unseren Support unter mail@netcup.de. Dieser kann das beschriebene Anliegen prüfen und an die richtige Stelle weitergeben. Danke.

**[netcup] Lars S.**

Zitat von KB19

[netcup] Lars S. *ping*

Vielleicht wären da neuere Hostkeys angebracht?

OpenSSH 8.2 unter Ubuntu 20.04 unterstützt definitiv mehr.

Hi KB19,

ich habe gerade die Rückmeldung aus der Fachabteilung erhalten, dass das nun behoben sein sollte.

Bud

Zitat von tab

Ich kaufe mir ja auch kein Auto, nur um damit mein Smartphone aufzuladen.

Wie jetzt, das geht auch ohne Auto?!

RAD750

Wie jetzt, Smartphones kann man aufladen?! Hab mir bisher immer neue gekauft...

aRaphael

Zitat von aRaphael

Ich habe gerade versucht einen snapshot auf einen (neuen) Server herunter zu laden, aber da kam:

Unable to negotiate with 46.38.225.190 port 2222: no matching host key type found. Their offer: ssh-rsa,ssh-dss

Zitat von aRaphael

Im Übrigen geht es ohne die Option durchaus anderswohin. Nur die Verbindung zum netcup ftp-Server macht diese "Probleme".

Zitat von KB19

Vielleicht wären da neuere Hostkeys angebracht?

OpenSSH 8.2 unter Ubuntu 20.04 unterstützt definitiv mehr.

Zitat von [netcup] Lars S.

ich habe gerade die Rückmeldung aus der Fachabteilung erhalten, dass das nun behoben sein sollte.

Ja. Danke.

Geht nun zum ftp-Server wieder wie gewohnt

mainziman

Hat jemand mehr als nur eine IPv6-Adresse des /64-Prefix am vServer-NIC in Verwendung?

ich hab auf einem vServer 4 IPv6-Adressen in Verwendung

prefix::1

prefix::2

prefix::3

prefix::4

und jetzt der AHA-Effekt, den ich überhaupt nicht erklären kann ...

ich hab folgendes laufen sobald das NIC aktiv ist

/sbin/ip addr change prefix::2 dev eth0 preferred_lft 0

/sbin/ip addr change prefix::3 dev eth0 preferred_lft 0

/sbin/ip addr change prefix::4 dev eth0 preferred_lft 0

bewirken soll das, dass ausgehender Traffic von nur einer IPv6 (prefix::1) gemacht wird;

dass sich hier dabei aber der traceoute6 verlängert, kann das jemand erklären warum?

und bekommt man das gewünschte Verhalten auch ohne der zusätzlichen Hops¹ im traceroute6 hin?

¹ diese sind irgendwo, und lassen echt nicht auf diese config schließen ...

frank_m

Zitat von mainziman

dass sich hier dabei aber der traceoute6 verlängert, kann das jemand erklären warum?

und bekommt man das gewünschte Verhalten auch ohne der zusätzlichen Hops¹ im traceroute6 hin?

¹ diese sind irgendwo, und lassen echt nicht auf diese config schließen ...

Hab ich das richtig verstanden? Die zusätzlichen Hops sind irgendwo in der Mitte des Traces? Nicht am Anfang? Also ich meine, an dem "Ende" des Traces, wo der Server ist?

RAD750

Hab nun schon seit einiger Zeit eine Mastodon Instanz auf einem VPS 200 G10s am laufen. Das läuft wunderbar und die Kosten halten sich dadurch auch in Grenzen.

Benutzer online in diesem Thema