DSM 6.0 - Fehlender "Root-Zugriff" - Lösung für WinSCP gesucht

HansOtto

Benutzer
Mitglied seit
29. Jul 2019
Beiträge
1
Punkte für Reaktionen
0
Punkte
1
Hallo Benares,
Auf der Suche nach der Root-Lösung bin ich nun hier gelandet. Und siehe da, genau soweit wie Du hier zeigst, komme ich auch. Aber wie geht es hier weiter? Was muss nun eingegeben werden?
 

Benares

Benutzer
Sehr erfahren
Mitglied seit
27. Sep 2008
Beiträge
6.352
Punkte für Reaktionen
593
Punkte
228

Kurt-oe1kyw

Benutzer
Mitglied seit
10. Mai 2015
Beiträge
6.907
Punkte für Reaktionen
570
Punkte
234
Ich packe die Info mal hier hin, eventuell sollte man aber ein neues Thema eröffnen mit der Überschrift DSM 7.0 - Fehlender "Root-Zugriff" - Lösung für WinSCP.

Das Wichtigste aber, die Beschreibung:
https://www.synology-forum.de/threa...-fuer-winscp-gesucht.74476/page-5#post-694440
und somit die Erklärung von jahlives im Beitrag #8
https://www.synology-forum.de/threa...oesung-fuer-winscp-gesucht.74476/#post-611920
hat nach wie vor Gültigkeit auch für das jetzt neue DSM 7.0:

dsm7_0_root_login.png

Mit der Beschreibung von jahlives und der Vorgehensweise hat es auch das Update auf DSM 7.0 "Überstanden".
Voller rootzugriff ist damit auch in DSM 7.0 nach wie vor möglich.
Somit ist auch unter DSM 7.0 weiterhin möglich eigene USB Nummern zu vergeben für die externen Speichermedien, in meinem Beispiel eine externe 2,5" WD Elements HDD welche fix als usbshare10 (USB DISK 10) definiert wurde.

dsm7_0_usbshare_definiert.png
Erklärung und Details dazu siehe meine Signatur unten mit dem Link "usbshare frei definieren", geht auch in DSM 7.0 nach wie vor.
 
Zuletzt bearbeitet:
  • Like
Reaktionen: mb01

ottosykora

Benutzer
Mitglied seit
17. Apr 2013
Beiträge
6.035
Punkte für Reaktionen
330
Punkte
203
@Kurt-oe1kyw

also ist der usbno_guid.map immer noch an gleicher Stelle und wird gleich bearbeitet?
(ich kann es nicht testen, meine 7 ist VM)
 

Kurt-oe1kyw

Benutzer
Mitglied seit
10. Mai 2015
Beiträge
6.907
Punkte für Reaktionen
570
Punkte
234
Ja korrekt, alles noch da und an gleicher Stelle.
Verhält sich genauso wie bei der vorigen DSM 6.x
 

Kurt-oe1kyw

Benutzer
Mitglied seit
10. Mai 2015
Beiträge
6.907
Punkte für Reaktionen
570
Punkte
234
Dann per puttygen Conversions - Key importieren und dann Save private key

Und hier lag bis Dato der Hund begraben:


Das angelegte SSH File ist mit 4096 Bit verschlüsselt, in puttygen ist aber 2048 eingestellt:

number of bits in a generated key : 2048

Beim abspeichern stimmen die verschlüsselungen nicht mehr überein und deshalb wird der Schlüssel auch abgelehnt!

Vor dem Speichern sollte man dort die 4096 eintragen, dann funktioniert auch putty und WinSCP mit Key authentifizierung.

Freddy3108 VIELEN DANK für deinen damaligen Hinweis. Ich bin schon verrückt geworden, aber der Reihe nach.
WinSCP lief jahrelang auf meiner DS916+ problemlos.
Jetzt bin ich umgestiegen von der DS916+ auf die RS1221+, dh. ich habe die HDDs ausgebaut und erfolgreich die Migration durchgeführt.
Alles gut, alles läuft, auch winSCP auf der RS1221+.

ABER jetzt wollte ich mit einer neuen HDD die DS916+ wieder aufsetzen, soll später als großes Backup dienen.
Ich habe manuell die letzte DSM Version 6.2.4-25556 installiert, also die letzte bevor DSM 7 kam.
Und ums Verrecken habe ich stundenlang winSCP auf der DS916 vorerst nicht zum Laufen gebracht!
Ich habe, ich weiß nicht wie oft, die Schritte dutzende Male wiederholt zum Erstellen vom id_rsa key Schlüssel und dann umgewandelt mit winSCP, da kommt der (FATALE) Hinweis: id_rsa kann nicht mit winSCP verwendet werden, wollen sie Umwandeln, ist bequem man braucht ja nur auf JA drücken und die .ppk Datei wird erzeugt. Beim A........h, früher ging das mit der jetzigen DSM 6.2.4-25556, jetzt kommt zwar auch eine .ppk aber ich bekam stundenlang die Fehlermeldung "Der verwendete Schlüssel wird vom Server abgelehnt!"
Dann gsd Freddy3108 Beitrag gefunden und ich kann das hier bei mir bestätigen, bei der Einstellung die Standardmässig in WinSCP auf 2048 steht, werden nicht funktionierende .ppk Dateien erzeugt. DAS WAR FRÜHER nie ein Problem.
Ich habe das auf der DSM 916+ damals so gemacht, dann auf der DS118 und auch auf der DS218+.
NUR jetzt mit der DSM 6.2.4-25556 gehts nicht mehr!
WinSCP MUSS umgeschaltet werden auf 4096 dann kommen auch funktionierende .ppk Dateien wieder heraus welche auch DSM 6.2.4-25556 akzeptiert.

Ich hatte schon voreilig geschrieben, dass DSM 7 läuft bei mir auf der DS118 und winSCP geht, ABER ich hatte das über eine bestehende DSM 6.x Version drüberinstalliert! Möglicherweise ist das ident wie die Migration auf der RS1221+ und der Fehler taucht nicht auf, nur bei Neuinstallationen.
Sollte also jemand bei DSM 7 das gleiche Problem haben, schaltet unbedingt auf 4096 um und verwendet NICHT die Funktion mit der autom Umwandlung!
Wie Freddy3108 korrekt erkärt hat, bitte den erzeugten id_rsa mit winSCP holen durch klicken rechts auf ERWEITERT >
neues Fenster > links bei SSH > Authentifizierung wählen > jetzt wird WERKZEUGE ca. in der Mitte aktiv - Anklicken > Neues Schlüsselpaar mit Puttygen generieren... anklicken > neues Fenster > HIER JETZT RECHTS UNTEN UMSCHALTEN VON 2048 auf 4096 bits!
Punkt kann links auf RSA bleiben, wichtig ist nur im rechten Feld die dort stehenden 2048 löschen und 4096 Eintragen!
Danach oben im Menü auf Conversions klicken > Import key > die id_rsa Datei auswählen > wenn gesetzt wurde passphrase eingeben > Kontrollieren ob RECHTS UNTEN IMMER NOCH 4096 steht! Manchmal springt das zurück auf 2048, dann nochmal 4096 eintippen!
Jetzt auf SAVE PRIVATE KEY klicken > als Dateiname manuell eintippen id_rsa.ppk ----> Diese Datei wird jetzt auch funktionieren und nicht abgelehnt werden!

ppk_datei_nur_mit_4096_manuell_erzeugen!.png

Nochmal, ich habe jahrelang problemlos einfach die Frage von WinSCP ob ich die .ppk Datei erzeugen möchte mit JA beantwortet und da ist standardmässig im Hintergrund 2048 eingstellt, daher funktioniert das jetzt nicht mehr. Früher war das kein Problem, da hat es auch mit 2048 funktioniert, da aber auf der Konsole beim Erzeugen der id_rsa Datei -b 4096 eingegeben wird, MUSS das jetzt auch hier beim Umwandeln auf die .ppk Datei so eingestellt sein!
Bitte diese Automatikfrage ob winSCP gleich die id_rsa umwandeln soll in .ppk NICHT verwenden, sondern mit Conversions "händisch" mit 4096 die .ppk Datei erzeugen, die funktioniert dann auch. Siehe Erklärung @Freddy3108 oben und das Bild hier.
 

Andy+

Benutzer
Mitglied seit
25. Jan 2016
Beiträge
3.904
Punkte für Reaktionen
116
Punkte
129

Kurt-oe1kyw

Benutzer
Mitglied seit
10. Mai 2015
Beiträge
6.907
Punkte für Reaktionen
570
Punkte
234
ah ja, das kommt vom schneller Schreiben als Denken :geek:

Danke für deinen Hinweis Andy+, das ist natürlich ein Schreib-/Satzfehler, ich meinte damit ich nutze seit Jahren winSCP auf dem PC um damit auf die Konsolen meiner DSen /jetzt RS zu gelangen und so verbinde ich vom PC wo winSCP drauf läuft mich mit den Konsolen der NAS-Geräte.
Und ich konnte mich immer auf die Konsole verbinden, auch auf der neuen RS1221+ welche die migrierten HDDs der DS916+ verbaut hat.
Dadurch wurde alles übernommen, nur die DS916 musste ich ja jetzt neu Aufsetzen und da ist dann die Problematik zu Tage getreten mit der jetzt neuen, aber falsch erstelleten .ppk Datei durch die falsche "bits" Einstellung.
Erst nach Umstellung auf 4096 bits wurde dann die .ppk Datei "richtig" erstellt und ich konnte wieder wie früher auf die Konsole der DS916+
 

Witzker

Benutzer
Mitglied seit
16. Dez 2017
Beiträge
119
Punkte für Reaktionen
2
Punkte
24
Halleluja
das ist ja eine Anleitung!:oops: so wie es leider in diesem Forum üblich ist;)

Ich habe es unter DSM 7.0.1-42218
so gemacht:

Mit putty als admin einloggen

sudo -i

sudo synouser -setpw root PASSWORD

cd..

vi /etc/ssh/sshd_config

# löschen aus der Zeile: PermitRootlogin yes

:wq

reboot

Start WinSCP

Mit root und neuem PASSWORD einloggen


Ergebnis:

1641729640365.png

Noch viel Spaß beim weiter chatten
 
Zuletzt bearbeitet:

Kurt-oe1kyw

Benutzer
Mitglied seit
10. Mai 2015
Beiträge
6.907
Punkte für Reaktionen
570
Punkte
234
Das hört sich gut an, die Frage ist ob man dann tatsächlich auch die vollen root Zugriffe hat oder sich "nur" Einloggen kann.
Nach deiner Beschreibung, kannst du bitte Versuchen die Datei usbno_guid.map zu editieren und ob sich diese geänderte/editierte Datei dann mit deiner Vorgehensweise auch wieder neu auf der DS speichern lässt.
Danke fürs Ausprobieren und Berichten.
 

Witzker

Benutzer
Mitglied seit
16. Dez 2017
Beiträge
119
Punkte für Reaktionen
2
Punkte
24
Die Schritte sind ja einfach und schnell gemacht.
Ich würde dich daher bitte das selbst zu versuchen und event. Hier zu berichten.

Der Grund warum ich da hinein wollte ist das ich irrtümlich mit Syncthing den standardmäßig vorgeschlagenen Ordner /volume1/@appdata/syncthing bestätigt habe und nicht den richtigen den ich dafür erstellt habe.
Den Ordner auf der Syno habe ich ohne root nicht gesehen! Um die dort dann fälschlicherweise synchronisierten Daten zu löschen

Nachdem oben beschrieben einloggen konnte ich den Inhalt ohne Probleme auch gleich löschen, was darauf hindeutet, dass es dafür Rechte gab.

Daher denke ich das es für Dein Vorhaben nicht schlecht aussieht.
Bin gespannt.

PS: da fällt mir gerade noch ein Ich habe die Datei /etc/sudoers wieder zurückgeändert habe in der ich vorher versucht habe dem admin rootrechte zu geben
also ich konnte die Datei editieren!!
 
Zuletzt bearbeitet:
NAS-Central - Ihr Partner für NAS Lösungen
NAS-Central - The Home of NAS

Kaffeautomat

Wenn du das Forum hilfreich findest oder uns unterstützen möchtest, dann gib uns doch einfach einen Kaffee aus.

Als Dankeschön schalten wir deinen Account werbefrei.

:coffee:

Hier gehts zum Kaffeeautomat