Diskussion:Secure Shell

message: 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)
thread_title:  SSH-Tunnel 

message: 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)
thread_title: Implementierung

message: 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)
replies: text: 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)
thread_title:  SSH unter Linux 

message: 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)
replies: text:  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)
replies: text:  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 , 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)
thread_title:  Verschlüsselungsalgorithmus 

message: 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)
thread_title:  Was ist an diesem Satz falsch? 

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

message: 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)
thread_title:  Verwendung angepasst (Public Key entfernt) 

message: 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)
replies: text: 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)
replies: text: 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)
thread_title:  Snakeoil-Algorithmus 

message: <<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)
thread_title:  Diskusion um Security through obscurity 

message: "...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)
replies: text: 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)
thread_title:  Vorteil der Public-Key-Authentifizierung 

message: 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)
replies: text: 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)
thread_title:  Fernwartungssoftware?