Diskussion:Secure Shell

SSH-Tunnel

Hallo, habe gerade das Wort "SSH-Tunnel" verlinkt, obwohl ein solcher Artikel noch nicht existiert. Aber vielleicht findet sich ja jemand, der den Artikel mit der Definition, was ein SSH-Tunnel eigentlich ist, mal erstellt.--Sammler05 17:38, 14. Jan 2006 (CET)

Hallo, hab gerade den Artikel umgestaltet und einiges dazugecshrieben - wäre nett, wenn jemand mit SSH-Kenntnissen sich das ganze nochmal durchlesen könnte und eventuelle Fehler korrigieren könnte! Ansosnten wäre es für mich noch ganz interessant, ob der Artikel so gut gegliedert und verständlich zu lesen ist. Danke im Vorhinein. --Xell 17:32, 14. Mär 2006 (CET)

Hab gerade mal den Artikel durchgescannt um eine Idee zugewinnen wie SSH/Aufbau einer SSH Verbindung eigentlich funktionieren - leider fühl ich mich jetzt nicht sonderlich schlauer - SSH_Newbie.

Implementierung

für windows ist freesshd nicht die einzige implementierung. es gäbe da auch noch copssh. Martin

Die folgende sehr gewagte und in dieser pauschalen Form auch absolut falsche Aussage habe ich mal aus dem OpenSSH-Absatz rausgenommen:

• Kryptographieexperten bevorzugen grundsätzlich freie Software für sicherheitsrelevante Anwendungen, da nicht nur die verwendeten Algorithmen, sondern insbesondere die Implementierung über die Sicherheit einer Software entscheidet. --Der sich nen Wolf tanzt 15:03, 24. Jun. 2008 (CEST)

SSH unter Linux

mal nee doofe Frage: Wie nutze ich SSH unter Linux? Schließlich kommt die Entwicklung ja aus dem Bereich also sollte es wohl gehen. Von WinSCP bin ich begeistert und wollt nicht alzu viel auf der Konsole rum tippen. Also gibt es einen grafischen Clienten für Linux (RH9) ? Kolossos 19:26, 2. Jul 2006 (CEST)

Eingentlich ist das hier der falsche Ort für sowas, aber mit Konqueror kannst Du per sftp auf einen remote host zugreifen. Einfach über die Adressleiste ansurfen: sftp://REMOTEHOST/ Grüße --AT talk 20:36, 2. Jul 2006 (CEST)

http://wiki.mobbing-gegner.de/Linux/ssh Links und Erklärungen ... für die Weblinks bestimmt für einige nicht "Premium" genug. Aber es hilft dem Einsteiger trotzdem :) --Macdet 12:39, 21. Jul 2006 (CEST)

Für Dateiübertragungen mit SFTP kann man Filezilla benutzen. --Ephramac (Diskussion) 23:03, 2. Sep. 2016 (CEST)

javabasierter SSH-Client

Es gibt auch javabasierte SSH-Clients wie z.B. http://www.appgate.com/products/80_MindTerm/ Diese lassen sich z.B. direkt im Browser nutzen, siehe Beispiel: http://weavervsworld.com/ssh/ssh.php (Laden dauert etwas)

Verschlüsselungsalgorithmus

Weiß jemand, wie leistungsfähig der Verschlüsselungsalgorithmus von SSH ist? Mir hat da heute jemand eine Zahl von 128-Bit-Algorithmus bei DotNet an den Kopf geworfen, und mich damit aus der Bahn geworfen. Vielleicht gibt es ja noch andere Kriterien, die in Zahlen ausdrücken, wie sicher SSH ist. --Turelion

Bevor du Angst bekommst, weil 128 Bit in Zeiten von 4096 Bit und weiß-nicht-was so wahnsinnig wenig klingt, denk dran, dass es einen signifikanten Unterschied macht, ob man von Schlüssellängen bei symmetrischen oder asymmetrischen Verschlüsselungen redet. --Scytale 13:16, 2. Feb. 2007 (CET)

Nochmal als Erklärung: Gerade AES ist eher unsicherer mit längeren Schlüssellängen. Wenn die Schlüssellänge unter 60 oder 70Bit oder so liegt ist das ein Kriterium dafür das der Algorithmus unsicher ist (weil anfällig gegen bruteforce) ansonsten hat das recht wenig zu sagen und andere Kriterien sind entscheidender. (Du musst bedenken ein Bit mehr heißt doppelt so stark.) 128Bit ist selbst bei derzeigiger Entwicklung der Rechenleistung nicht innerhalb eines Menschenlebens nicht brutforcebar. Somit ist diese Angriffsmöglichkeit ausgeschlossen und andere, die viel stärker von anderen Faktoren abhängen, treten in den Vordergrund. ---Fabiwanne (Diskussion) 13:26, 11. Jul. 2013 (CEST)

da muss ich mal korrigieren: AES ist natuerlich nicht unsicherer mit laengeren schluesseln: AES-256 ist sicherer als AES-128. das BSI empfiehlt derzeit eine schluessellaenge von mind. 100 bit [1], und ein kurzer schluessel bedeutet nicht, dass der algorithmus unsicher ist. ein algorithmus ist unsicher, wenn man ihn schneller brechen kann als mit brute force. --Mario d 13:34, 11. Jul. 2013 (CEST)

Authentifizierung

"Der Client kann sich wahlweise mit einem öffentlichen Schlüssel, der auf dem Server hinterlegt ist (sogenannte Public-Key-Authentifizierung), oder einem gewöhnlichen Textpasswort authentifizieren." Das verstehe ich nicht. Wie kann man sich mit einem öffentlichen Schlüssel authentifizieren? Öffentlich heißt ja gerade, dass er jedem zugänglich ist... Die einzig logische Erklärung wäre, dass der Server mit dem public key des Clients eine Nachricht verschlüsselt, die der Client (und nur der) mit seinem Private Key wieder entschlüsseln und in angemessener Form darauf antworten kann. Wenn dem so ist, sollte diese Passage bitte konkretisiert werden. --ComradeMicha 13:43, 15. Sep. 2008 (CEST)

Hallo ComradeMicha,

es geht um die Public-Key-Authentifizierung, der Client verfügt also über einen (eigenen) Private-Key, den er mit dem Public-Key des Servers kombiniert. Eine gängige Praxis, die z.B. auch bei PGP verwendet wird. Ich hab die Passage mal etwas umformuliert. --Benji 18:50, 15. Sep. 2008 (CEST)

Ich habe die bemängelte Formulierung überarbeitet. Der Client benötigt zur Authentifizierung den privaten Schlüssel. --Fomafix 18:55, 15. Sep. 2008 (CEST)

Was ist an diesem Satz falsch?

Im Artikel steht:
Hierdurch wird der Effekt erreicht, als säße man vor der entfernten Konsole.

Was stimmt an dem Satz nicht? --Snapper007 15:25, 8. Mai 2009 (CEST)

Quellenangabe

und derzeit gilt das Protokoll als sicher. Wo habt ihr das her, Quelle? (nicht signierter Beitrag von 62.167.74.0 (Diskussion | Beiträge) 02:50, 16. Mai 2009 (CEST))

Das BSI empfiehlt den Einsatz, weil andere Alternativen unsicher sind:

https://www.bsi.bund.de/DE/Themen/ITGrundschutz/ITGrundschutzKataloge/Inhalt/_content/m/m04/m04203.html

https://www.bsi.bund.de/DE/Themen/ITGrundschutz/ITGrundschutzKataloge/Inhalt/_content/m/m05/m05064.html

Aber ich nehme an, dass reicht den Wikipedianern nicht als Quelle. Selber denken ist hier halt verboten. (nicht signierter Beitrag von Fabiwanne (Diskussion | Beiträge) 13:06, 11. Jul. 2013 (CEST))

SSH Schwachstellen

Was ist mit der Unsicherheit bei X11-Forwards, die Ulrich Flegel beschrieben hatte: [2]. Sollte man dies im Bereich der "Schwachstellen" beschreiben? -- Starcalc 00:48, 20. Jun. 2009 (CEST)

Verwendung angepasst (Public Key entfernt)

Folgender Abschnitt wurde entfernt, da er mMn hier nichts zu suchen hat; außerdem wird im Abschnitt "Sichheit" auch nochmal darau eingegangen:

• Wenn der Server A dem Server B ohne interaktive Eingabe des Passworts SSH-Zugriff gestatten soll, trägt man den öffentlichen Schlüssel (public key) von B in die Schlüsseldatei (authorized_keys) der SSH-Konfiguration von A ein. Dann kann B z. B. von der Kommandozeile via SSH auf A Kommandos ausführen oder mit SCP eine Datensicherung durchführen. Wenn zusätzlich unterschiedliche Benutzer verwendet werden sollen, also zum Beispiel der Server A unter dem Nutzer alpha für den Nutzer beta auf Rechner B den SSH-Zugriff ohne interaktive Passwort-Eingabe gestatten soll, ist der öffentliche Schlüssel des Nutzers beta auf dem Server B an die Schlüsseldatei (authorized_keys) des Nutzers alpha auf dem Server A anzuhängen.

-- Freebirth One 16:37, 3. Okt. 2010 (CEST)

Snakeoil-Algorithmus

Davon ausgehend das Snakeoil hier nicht der Name eines Codierverfahrens ist, sondern eine Bewertung des Algorithmus als Snakeoil (Scharlatanerie) beinhaltet, entferne ich diese Bezeichnung. In diesem Zusammenhang formuliere ich die entsprechend Sätze wertfrei um. MfG, --178.2.195.33 12:49, 9. Apr. 2011 (CEST)

Ich vertrete hier den Standpunkt, dass der genannte Algorithmus offensichtlich und bekannterweise ein Snakeoil-Algorithmus ist und es deshalb drinstehen darf, ohne dass es den NPOV verletzt. Aber das ist nur mein persönlicher Standpunkt, wir sollten noch auf andere Nutzer warten. LG, --Der Messer ^{meckern? - Bew} 17:28, 24. Apr. 2011 (CEST)

Die Kritik wird doch im Abschnitt Secure Shell#Verschlüsselung aufgeführt dort auch mit einer Quelle versehen. Der Hinweis der jedoch als unsicher gilt reicht hier meiner Meinung nach bereits vollkommen aus und ist eine wertneutraler Formulierung. Abgesehen davon liefert Google zum Begriff Snakeoil-Algorithmus nur rund 100 Ergebnisse die größtenteils wieder auf diesen Artikel zurückzuführen sind. U.U. könnte man den Satz vielleicht umformulieren um die Kritik besser zu integrieren. Hast Du vielleicht auch noch eine besseren Beleg für die Kritik? Die im Artikel verlinkte erscheint mir doch eher schwach (oder habe ich da den entscheidenen Teil in den 3 Sätzen überlesen?) und der enthaltene Link tot... -- Aveexoo 01:49, 25. Apr. 2011 (CEST)

Hallo und Danke für die Diskussionsbeiträge. Aus meiner Sicht bestärken diese meine Auffassung, das Snakeoil die falsche Wortwahl für berechtigte Kritik ist. Snakeoil ist bekannterweise eine Bezeichnung für wirkungslose Wundermittelchen. Da CryptoCore offensichtlich seinen Zweck -Verschlüsselung- erfüllt, ist diese Software offensichtlich nicht wirkungslos. Mit SnakeOil teilt es sich allerdings die verheissungsvolle Vermarktung und wortreiche Werbung. Darauf weisst auch die Quelle hin. Die Quelle -ein m.E. launischer Kommentar eines Crypto-Spezialisten- weisst keinesfalls nach, das es sich um leere Versprechungen handelt, sie mockiert nur über die blumige Aufbauschung. Mit einer Formulierung wie "Namhafte Crypto-Experten wie Bruce Schneier bezweifeln die angepriesenen Nutzervorteile" wäre ich einverstanden. Mit einer nicht durch Messergebnisse o.ä. Verdammung als Nutzlos nicht. MfG, --80.226.45.201 10:15, 25. Apr. 2011 (CEST)

Diskusion um Security through obscurity

<<um z. B. Angriffe zu erschweren, da der SSH-Port dem Angreifer nicht bekannt ist.>> wird die Diskusion geführ ob dieser Abschnitt sinn macht? (nicht signierter Beitrag von Tabletop-Player (Diskussion | Beiträge) 12:36, 12. Jun. 2012 (CEST))

Vorteil der Public-Key-Authentifizierung

"...ermöglicht die Public-Key-Authentifizierung, dass sich Client-Computer auch ohne Benutzerinteraktion auf SSH-Servern einloggen können, ohne dass dabei ein Passwort auf dem Client im Klartext gespeichert werden muss." Dieser Satz ergibt für mich keinen Sinn, schließlich muss stattdessen der unverschlüsselte Private Key (oder der verschlüsselte Private Key + Passwort zum Entschlüsseln) auf dem Client gespeichert werden, wenn keine Interaktion erforderlich sein soll. Der Vorteil liegt meines Erachtens eher in der größeren Schwierigkeit, einen Private Key per Brute Force zu knacken bzw. per Social Engineering Kenntnis von ihm zu erlangen. -- 95.141.28.117 11:52, 21. Jan. 2015 (CET)

Mittels ssh-agent geht's auch ohne Passworteingabe sobald der Key mal dort hinzugefügt wurde (da wird das Passwort benötigt), um den Key zu entschlüsseln, dieser kann auch weitergeleitet werden. Es geht bei deiner Beschreibung eher um den Standardclient, denn wenn man eine SSH-Bibliothek zum Programmieren hernimmt, kann man die Keys und Passworter anders hinterlegen und für den Standardclient kann man mit einer Option das fragen nach dem Passwort deaktivieren wodurch die Verbindung fehlschlägt, anstelle dass nach einem Passwort gefragt wird. Fabianfrz (Diskussion) 16:43, 26. Aug. 2018 (CEST)

Fernwartungssoftware?

Nach meinem Verständnis ist SSH ein Protokoll und keine Fernwartungssoftware, die Einstufung als Kategorie:Fernwartungsoftware sollte überdacht werden. Grüße --DaxBichler (Diskussion) 11:12, 14. Mär. 2017 (CET)

Würde eher sagen sowohl als auch: SSH ist ein Protokoll, jedoch ist ssh (Üblicherweise der OpenSSH-Client unter Linux) ein Werkzeug, mit dem Linux-Server administriert werden. Fabianfrz (Diskussion) 16:48, 26. Aug. 2018 (CEST)

SSH over UDP und SSH over SCTP

Durch die IANA zugewiesener Port, jedoch anscheinend nicht implementiert. https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml Die RFC-4251 erwähnt diese ebenfalls nicht. Falls jemand hierzu mehr Informationen hat, bitte ergänzen. Ich habe nur diese Thesis gefunden: https://publications.lib.chalmers.se/records/fulltext/123799.pdf (nicht signierter Beitrag von Agowa (Diskussion | Beiträge) 12:11, 27. Mai 2020 (CEST))