News PuTTY adé: Windows 10 erhält nativen SSH-Client und -Server

@textract:
Prinzipiell reicht es schon aus, wenn der SSH- Client mitlogged, zu welchen Servern Du Dich regelmäßig verbindest.
Und das an Microsoft überträgt.

Daß MS Interesse dran hat, was Du auf den Servern tust, will ich da gar nicht mal unterstellen, und würde auch zu weit gehen. Schon die Entführung von Metadaten gibt mehr Informationen preis als wünschenswert wären. Und die wären bei einer Absturzmeldung in jedem Fall enthalten.

textract schrieb:
Das hat auch gar nichts mit reißerisch zu tun. Microsoft hat sein Vertrauen mit Windows 10 gefühlte 1000 mal verspielt.

Microsoft hat doch gerade erst angefangen.
 
@textextract

Das Problem ist ja, wer einmal lügt... allerdings klar, wenn Passwörter ungehashed übertragen werden ist da snicht so sexy. A) Für was gilt es noch? B) ist es noch so? 1 Jahr ist ne lange Zeit
 
@textract: Da wird nichts im Klartext übertragen, die Übertragung ist verschlüsselt. Ok, sie ist nicht komplett gegen man-in-the-middle Angriffe abgesichert (kein Zertifikat pinning, falls das überhaupt noch so ist) und innerhalb des verschlüsselten Streams sind die Passwörter nicht gehasht. Das könnte man tatsächlich besser machen.

Aber dir kann es ja eh nicht passieren dass du aus versehen was in den MS SSH Client eingibst denn da du aufgrund deiner bedenken eh kein Windows verwendest wirst du den Client nie auf dem Rechner vor dir haben..
 
espiritup schrieb:
Erstmal abwarten, was die Lösung taugt.

Ein Telnet- Tool gab es ja schon unter Windows 95. Leider taugte es nichts, und hatte sich durch Einführung von SSH ab 2000/2001 dann eh erledigt.
[...]

Nö, der ist immernoch da :D

Konsole auf -> Telnet -> Enter
 
Halloele,

Jesterfox schrieb:
Der Entwicklermodus ist nicht notwendig, bei mir ging es auch ohne.

Und hier erst, nachdem ich bei einer W10 Build 16299.125 den Entwicklermodus aktiviert hab. Sonst haett ich nichts dazu geschrieben. ;)
Die VM ist allerdings keine frische 1709, ist hochgepaeppelt seit 15**.

BFF
 
Grundsätzlich finde ich die Integration von solchen Tools direkt in das Betriebssystem super. Mit Windows 10 hat man out-of-the-box mittlerweile echt eine richtig gute Grundlage, um mit Linux-Systemen und -Tools arbeiten zu können.

Zuerst Ubuntu on Windows und nun OpenSSH Client/Server.

Wenn man jedoch viel mit SSH-Verbindungen arbeitet, verwendet man ohnehin ein Tool, mit dem man auch mehrere Connections, Sessions und Credentials vernünftig verwalten kann.
Ich habe hierfür seit geraumer Zeit Xshell mit integriertem Xftp im Einsatz und bin damit sehr zufrieden. Ist für den privaten Gebrauch kostenlos.
 
Sun_set_1 schrieb:
Nö, der ist immernoch da :D

Konsole auf -> Telnet -> Enter

Windows 10 kennt ihn nicht mehr.

Aber selbst wenn: Versuch mal, wo drauf zu kommen.
Jede Linuxmaschine, die in den letzten 15 Jahren installiert wurde, hat Telnet per Default abgeschaltet.
Aus gutem Grund.
 
espiritup schrieb:
Windows 10 kennt ihn nicht mehr.

Aber selbst wenn

Bitte was?

Versuch mal, wo drauf zu kommen.

https://seeit.org/2010/01/31/debug-your-imap-server-with-telnet/
http://www.esqsoft.com/examples/troubleshooting-http-using-telnet.htm
https://github.com/ant-thomas/zsgx1hacks
http://www.fredericb.info/2017/11/n...mera-support-to-create-a-security-webcam.html

Ich selbst teste in der Firma mit Telnet die Firewall-Freischaltungen. Allerdings komme ich mir dabei immer ziemlich alt vor, fehlt doch jegliches Blinki-Blinki und nicht einmal ein lustig quiekendes Emoticon begleitet meine Arbeit.
 
Okay Hayda,

ich entschuldige mich untertänigst :)

Natürlich hatte ich beim Thema "telnet" nur die Fernwartung von Linux- Maschinen im Kopf.
Dafür nutzt man heutzutage - auch dank Putty - eigentlich ausschließlich ssh.

Daß man auch mit anderen Diensten im Klartext "sprechen" kann, ist mir tatsächlich entfallen.
Mein Arbeitsgebiet geht zu sehr richtung "Blinki" und "Klickibunti", deswegen habe ich Telnet hier auch nicht installiert.
 
Sun_set_1 schrieb:
Bin da nicht mehr ganz aktuell unterwegs, aber lag letzteres nicht eher an den komplett unterschiedlichen Berechtigungsparamtern zwischen NTFS und dem Rest der Welt? Sprich, dass einfach die Übersetzung irgendwo Bockmist gebaut hat, was aber weniger am Protokoll denn an den Dateisystemen selbst lag.
Mit der Schnittmenge von Linux unt NTFS war ich ganz gut zufrieden. Der Punkt ist eher, dass man dafür diese Funktion auf dem Client aktivieren muss und wenn man sich ganz blöd anstellt irgendwas dabei freigibt. Wenn man SSH verwendet, muss man selber keinen Server aufmachen, um auf Samba zugreifen zu können.
 
Ich bekomme es nicht hin, Installation von Server und Client problemlos (Neustart nicht vergessen), aber ich bin zu blöd mich mit meiner SAT-Box zu verbinden, bekomme immer
Code:
C:\Users\knud>ssh root@vusolo2
Unable to negotiate with 192.168.178.22 port 22: no matching host key type found. Their offer: ssh-rsa
Mit Putty klappt alles nach wie vor einwandfrei. Was mach ich denn falsch?
 
Danke !! :)
Hab das in dem Link gerade mal quergelesen, ist für mich als Ottonormalverbraucher zu komplex, Putty geht ja hier....
 
Dann wäre die Fehlermeldung ja falsch, die besagt ja, dass rsa angeboten wurde (der Link behandelt ja den entgegengesetzten Fall).

Evtl. kann MS ja noch kein RSA. ;)
 
falsch rum, stimmt. Es wird NUR RSA angeboten wie es aussieht. Putty dürfte das egal sein, deshalb gehts.
 
Bei meinem Testclient geht der SSH-Client auch nur wenn man die CMD als Administrator mit Administratorrechten gestartet hat. Hingegen geht Putty auch als normaler User. Für mich zumindest ein KO Kriterium.

Ich möchte nicht das unsere "Bastelabteilung" wenn Sie mit ihren PIs rumtestet Adminrechte auf ihren Clients benötigt.:rolleyes:

Gibt aber schon Anwendungsfälle wo der MS-SSH Client Sinn ergibt.
 
Zurück
Oben