ubuntuusers.de

Hallo,

Nur weil etwas funktioniert, ist es deswegen noch nicht sinnvoll.

Schon - aber dein Aussage oben ("... dass es offensichtlich nicht funktioniert.") besagt exakt das Gegenteil von lionziard ("...funktioniert tadellos..."). Von daher ist das schon wichtig zu klären. Ob wir sinnlose Sachen im Wiki haben wollen ist das eine - aber falsche wollen wir sicher nicht.

Gruß, noisefloor

Into_the_Pit schrieb:

Nur weil etwas funktioniert, ist es deswegen noch nicht sinnvoll. 😉

Und nur weil Du den Sinn nicht erkennst, ist es nicht sinnlos. Außerdem hilft es, bei einer Frage den Kontext zu betrachten, um deren Sinn zu verstehen. Kontext in diesem Fall ist die Wikiseite SSH

noisefloor schrieb:

Ob wir sinnlose Sachen im Wiki haben wollen ist das eine - aber falsche wollen wir sicher nicht.

Wenn ich ein Terminal aufmache, und den Aufruf ohne & starte, dann öffnet sich zwar das Programmfenster, aber die Konsole bleibt blockiert. Mit dem & kann ich, dank Multitasking, sowohl im Editor auf dem anderen System als auch in meiner Konsole weiterarbeiten.

Ohne das & anzufügen, hat sich die Konsole bei mir auch erst nach einem Strg + C wieder belebt, nachdem das Programm wieder geschlossen war (vielleicht habe ich auch nicht lang genug gewartet).

Kurze Frage: Weshalb verwendet ssh keygen noch rsa? Laut experten Info ist

1

ssh-keygen -t ed25519 

sogar stärker als:

1

ssh-keygen -t rsa -b 4096 

Wenn man aber für ein 4096 bit langes Zertifikat, was wohl zur Zeit überall empfohlen wird, dies explizit auch angeben muss, stellt sich mir die Fragen, weshalb in ssh nicht automatisch das Stärkste Verfahren Standard ist.

Könnte mir das wer erklären? Wäre allenfalls auch etwas für den Artikel.

Hallo,

Kurze Frage: Weshalb verwendet ssh keygen noch rsa?

Vermutlich weil es noch keinem Aufgefallen ist und sich noch keiner dazu berufen fühlte, es zu aktualisieren. Letzteres kannst du gerne machen ☺

stellt sich mir die Fragen, weshalb in ssh nicht automatisch das Stärkste Verfahren Standard ist.

Die frage musst du wohl den Entwicklern von SSH stellen...

Gruß, noisefloor

Das finde ich sind doch wichtige Fragen. Schliesslich geht es um Sicherheit.

Hallo,

Das finde ich sind doch wichtige Fragen. Schliesslich geht es um Sicherheit.

Völlig richtig. Wenn du Erkenntnisse bzw. die Antwort hast, kannst du das gerne in Wiki einbauen.

Die Chance, dass du die Antwort hier im Wikiforum bekommst, ist aber eher gering. Ggf. solltest du die Frage nochmal im passenden Supportforum hier bei uu.de stellen.

Gruß, noisefloor

Für SSH-Hops gibt es ja seit Version 7.irgendwas die Option:

ProxyJump

Damit spart man sich das bisher eher umständliche

ProxyCommand

.

Außerdem gibt es endlich eine .ssh/config.d.

Fühlt sich jemand berufen, das in den Artikel einzubauen? Ich krieg das gerade nicht unter (sonst bleibt es eben erstmal hier als Gedankenstütze für mich selbst...)

Ich habe hier ein Verständnisproblem:

Die Verbindung vom Ende des Tunnels zu host läuft dagegen unverschlüsselt ab, und wird aus Sicht des betreffenden Systems angegeben, weswegen man host in den allermeisten Fällen wohl auf "localhost" setzen sollte. Hierbei darf "localhost" nicht mit dem lokalen Rechner verwechselt werden. Es handelt sich um "localhost" von server aus betrachtet, daher um den Server selbst.

Das ist doch nur bei der -L-Option so, bei der -R-Option ist der angegebene host aus Sicht des lokalen Rechners oder?

Danke & Viele Grüße,

Frink

push. s. o.

Hallo,

kurz fürs Protokoll: Ich habe die letzte Änderung von martinu mit der Überschriften-Korrektur rückgängig gemacht, da der Abschnitt "Serverkonfiguration" ein Teil des Abschnitts X-Forwarding ist.

Gruß BillMaier

Prof._Frink schrieb:

Ich habe hier ein Verständnisproblem:

Die Verbindung vom Ende des Tunnels zu host läuft dagegen unverschlüsselt ab, und wird aus Sicht des betreffenden Systems angegeben, weswegen man host in den allermeisten Fällen wohl auf "localhost" setzen sollte. Hierbei darf "localhost" nicht mit dem lokalen Rechner verwechselt werden. Es handelt sich um "localhost" von server aus betrachtet, daher um den Server selbst.

Das ist doch nur bei der -L-Option so, bei der -R-Option ist der angegebene host aus Sicht des lokalen Rechners oder?

Danke & Viele Grüße,

Frink

Laut dem Beispiel aus dem Artikel nicht:

Umgekehrte Richtung. Benutzern auf server wird ermöglicht, über localhost:3306 auf den MySQL-Server auf client zuzugreifen:

ssh -R 3306:localhost:3306 server 

oder ich verstehe deine Frage falsch.

Viele Grüße BillMaier

Hallo allerseits,

nach einigen Anläufen habe ich meine ssh-Verbindung zu einem Server mittels dem Paket google-authenticator so konfiguriert, dass ich zum Zugang einen Key+Passwort sowie ein 6-digit 2FA Passwort benötige. Das hierzu notwendige Vorgehen würde ich gern in den Artikel aufnehmen.

Kann ich einfach loslegen oder gibt es Gegenstimmen hierzu? Ich könnte mir vorstellen, dass der Artikel damit evtl. zu unübersichtlich/komplex werden könnte?!

Beste Grüße

lock-3 schrieb:

Kann ich einfach loslegen oder gibt es Gegenstimmen hierzu? Ich könnte mir vorstellen, dass der Artikel damit evtl. zu unübersichtlich/komplex werden könnte?!

Das wäre meines Erachtens eher was für einen extra (Unter)-Artikel.

Gruß BillMaier

Hallo,

korrekt. Bitte pack' das ganze in einen neuen Unterartikel.

Wenn der fertig ist, du beim Schreiben Fragen hast etc. bitte eine neue Diskussion zu deinem neuen Artikel starten.

Gruß, noisefloor