SSH Problem bei Migration eines Mailservers

[kartaga]

Hallo,

ich habe zwei Diskstations im lokalen Nezt und möchte von einem Mailserver auf einen Mailserver Plus auf der neuen DS migrieren.
Dazu gibt es für DSM 6 eine Anleitung, damit die Remoteverbindung zwischen den Diskstations erstellt werden kann:
https://www.synology.com/de-de/know...te_Synology_Mail_Server_to_MailPlus_Server#t3


Soweit so gut. Ich habe die Prozedur nach einigen Schwierigkeiten nun durch, aber es funktioniert nicht.
Woran könnte es wohl liegen?
Zu Info: den Schlüssel habe ich händisch neu eingtippt, da Copy Paste in PuTTY nicht ging. Ich hoffe, da ist mir kein Fehler unterlaufen.


Hier mal, was PuTTY mir zum Ende (also Punkt 10 in der Anleitung) ausgibt:






login as: admin
admin@192.168.178.38's password:
admin@DiskStation:~$ sudo -i
Password:
root@DiskStation:~# ssh root@192.168.178.34
The authenticity of host '192.168.178.34 (192.168.178.34)' can't be established.
ECDSA key fingerprint is SHA256:RaNIFFw8EX..............ausgegraut.......................xA8tDvaA.
Are you sure you want to continue connecting (yes/no)? y
Please type 'yes' or 'no': yes
Warning: Permanently added '192.168.178.34' (ECDSA) to the list of known hosts.
root@192.168.178.34's password:
Permission denied, please try again.
root@192.168.178.34's password:
Permission denied, please try again.
root@192.168.178.34's password:





Ich hoffe, ihr könnt mir helfen. Danke.

 

[mexx81]

Ich nehme an root@192.168.178.34 ist eine andere Diskstation. root ist im DSM nicht erlaubt SSH zu nutzen. Du musst Deinen Administrator nehmen und dann root-Rechte erwerben. So wie beim Login auf die 192.168.178.38. Da hast Du es richtig gemacht und Dich erst mit "admin" angemeldet und dann via sudo -i root rechte bekommen. Also statt root@192.168.178.34 %das administratorkonto%@192.168.178.34 und dann sudo -i.

 

[kartaga]

Hallo Mexx,

ich habe versucht "stupide" die Anleitung von Synology zu befolgen und da steht unter Punkt 10:
"Führen Sie "ssh root@[Remote-IP]" aus, um zu überprüfen, ob die Verbindung ordnungsgemäß funktioniert."

Ich gehe also davon aus, daß es mit "ssh root@[Remote-IP]" funktionieren muss, bevor ich den Mailserver migrieren kann.

Zu deinen Gegenfragen: ja es sind zwei Diskstations.
Die 34er jst die neue, die 38er ist die alte von der aus der Mailserver migriert werden soll.

Ich hoffe, ihr könnt hier nochmal was zu sagen.




:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

Folgendes als Ergänzung.
wenn ich "ssh admin@ip-adresse" benutze und mich dann mit sudo -i auf root bringe, gitb es keine Fehlermeldung.
Ob das, aber das ist, was ich machen muss, um hinterher Migrieren zu können, weiss ich nicht :-(





login as: admin
admin@192.168.178.38's password:
admin@DiskStation:~$ sudo -i
Password:
root@DiskStation:~#
root@DiskStation:~# ssh 192.168.178.34
root@192.168.178.34's password:
Permission denied, please try again.
root@192.168.178.34's password:
Permission denied, please try again.
root@192.168.178.34's password:
Permission denied (publickey,password).
root@DiskStation:~# ssh admin@192.168.178.34
admin@192.168.178.34's password:
admin@SynoServer:~$ sudo -i
Password:
root@SynoServer:~#

 

[mexx81]

Mach es doch bitte erstmal so, wie ich sage. Du wirst root niemals per SSH nutzen können. Das ist auch gängige Praxis. SSH dürfen nur Admins und die werden dann zum root. In der Anleitung wird über SSH nur eine Vertrauensstellung aufgebaut. Mach Alles wie in der Anleitung, nur eben die SSH Sitzungen via Putty nicht mit root.

 

[kartaga]

Hallo Mexx,

gut, das habe ich ja gemacht. Konntest du ja eben schon sehen.


Dann bin ich auf die neue DS gegangen und habe den Migrationsdienst des Mail-Plus-Servers ausführen wollen.

An der Stelle komme ich aber nicht weiter. Es kommt nur eine Infobox, wo sinngemäss drin steht:


1. Netzwerksicherungsdienst auf Remoteserver aktivieren (sollte aktiv sein)
2. richtige Einstellungen vornehmen (sollten richtig sein...es gibt ja nur IP, admin, admin-password)
3. es wird ein Link zu der obigen Anleitung gezeigt (also die Anleitung, wo die obige Prozedur beschrieben wird)


Mmh, ich drehe mich im Kreis :-(

 

[mexx81]

Also Du machst erst :

(angepasste Anleitung um SSH auf eine DS und von DS via SSH auf eine andere)
login as: admin
admin@192.168.178.38's password:
admin@192.168.178.38:~$ sudo -i
Password:
root@192.168.178.38:~#


Dann admin auf auf die andere:

root@192.168.178.38:~# ssh admin@192.168.178.34
admin@192.168.178.34's password:
Password:
admin@192.168.178.34:~$ sudo -i
Password:
root@192.168.178.34:~#

Bis hier hin reden wir noch nicht von der Mailmigration. Bis hier hin reden wir nur über "wie komme ich per SSH auf eine DS und werde Root?" und von "wie komme ich von einer SSH Sitzung via SSH auf eine andere DS?"

Denn wenn ich Deinen Anfangseintrag lese, scheiterte es ja bereits dabei.

Die Anleitung scheint recht alt zu sein. Warum gehst Du nicht einfach diesen Weg?

 

[kartaga]

Hallo Mexx,

also per SSH auf die beiden Diskstations zu kommen funktionoiert ja, so wiei du es beschrieben hast. Ging ja auch oben schon. Ich habe ja extra die Putty-Einträge hierhin kopiert.


Bis gestern bin ich vollkommen ohne SSH oder PuTTY ausgekommen. Ich will ncihts anderes erreichen, als den Mailserver zu migrieren.
Die "doofe" Anleitung, ist alles was ich bisher zur Verfügung hatte ;-(, wenn es einfacher geht...sehr gerne ;-)


Wenn ich den frisch installierten MailServer-Plus öffne, dann kommt bei mir dieses Fenster:



Ich habe die Option also erst mal gar nicht zur Verfügung.

 

[Tommes]

Man kann sich sehr wohl direkt als root am Terminal einer DS anmelden, wenn man denn einen RSA-Key verwendet. Und genau das hat der TE ja auch durchführen wollen, nachdem er den RSA-Key erzeugt hat. Ich denke, das das händische Eintippen des echo‘s nicht geklappt hat. Im Terminal kann man einen Text mit der Maus markieren, welchen man dann mit STRG + C in die Zwischenablage kopieren kann. Im Terminal der anderen DS kann man den Inhalt der Zwischenablage durch einen rechtsklick auf der Maus wieder einfügen.

Tommes

 

[kartaga]

Hallo Tommes,

ja, es kann sein, dass der KEy nicht korrekt gespeichert wurde.

Wenn ich nun nochmal echo mit dem korrigierten Key ausführe, muss ich die bisherige Datei erst löschen? Oder kann ich das quasi "drüber-kopieren".

Sorry für die doofen Fragen. Aber mir fehlt einfach die Erfahrung in Bezug auf SSH und PuTTY.

 

[Tommes]

Den Eintrag zu löschen wäre wohl sympathischer, ich kann dir von hieraus aber grad nicht den Weg beschreiben das zu berwerkstelligen. Müsstest bis heut Abend warten... oder du probierst es einfach mal!

 

[kartaga]

...ich habe mit "rm" die Datei auf der neuen Diskstation gelöscht. Den Key hatte ich ja noch gespeichert und per Paste nun mit dem echo-Befehl einen neuen Key auf der neuen Diskstation erstellt.

Egebnis: es hat sich nichts geändert.


Beim Versuch die Verbindugn aufzubauen kommt:
ssh_exchange_identification read connection reset by peer

Daraus werde ich nicht schlau.
Im Internet habe ich gelesen, das könne mit der IP-Blockierung zusamenhängen.
Dann habe ich testweise Firewall und IP-Blockierung ausgechaltet...kein Unterschied.

 

[blurrrr]

Hachja... immer wieder schön diese kleinen NAS-Wunderboxen die alles können und wo alles soooo einfach ist... und dann kam die Realität

Wenn Du der Anleitung "so" folgen willst, musst Du erstmal beim SSH-Dienst in der Config eine Option dafür setzen: sshd.conf -> "#PermitRootLogin", sonst geht es nämlich schlichtweg nicht. Da das aber nicht so schön ist (und da darf man ruhig mal auf den Onkel mexx hören), solltest Du den Login genauso wie beim Quell-NAS vornehmen. Nämlich "erst" mit dem "administrativen" User und danach zu "root" wechseln. Machen wir das nochmal bildlich für Dich (ich klau mal einfach von Dir ):

Schritt 1)

login as: admin
admin@192.168.178.38's password:
admin@DiskStation:~$ sudo -i
Password:
root@DiskStation:~#

Schritt 2)

root@DiskStation:~# ssh admin@192.168.178.34
admin@192.168.178.34's password:
admin@192.168.178.34:~$ sudo -i
Password:
root@192.168.178.34:~#

Und weil es grade so unglaublich angebracht ist: "so klappt's auch mit dem Nachbarn!"

EDIT: Keys kopieren kann man übrigens auch einfach über die Zwischenablage, wenn ein "direkter" Root-Zugriff nicht möglich ist. Wie gesagt, wenn Du der Anleitung im Detail folgen willst, s.o. "PermitRootLogin", aber danach dann bitte wieder auf beiden Geräten auskommentieren (mit "#").

 

[Tommes]

@blurrrr
Komisch ist nur, das wir innerhalb Ultimate Backup einen SSH-Zugang zu entfernten Diskstation‘s sowie rsync-kompatiblen Servern als root aufbauen können, ohne die sshd.conf zu verbiegen. Wir generieren und tauschen hierfür einfach nur einen RSA-Schlüssel aus. Weiterhin kann ich mich mittels dieses RSA-Schlüssels z.B. mit PuTTy oder WinSCP direkt als root aufschalten, ohne den Umweg über den admin zu gehen. Kannst dir Ultimate Backup gerne mal anschauen und das testen... dort ist auch ein Hilfetext hinterlegt, der den manuellen RSA-Schlüsselaustausch beschreibt.

Ergänzung:
Die von dir beschriebene Methode wird nur benötigt, solange man noch keinen RSA-Schlüssel erstellt hat. Die Erstellung des Schlüssels gilt immer nur für den aktuell angemeldeten Benutzer, im hier vorliegenden Fall ist das root! Nachdem der Schlüssel für root erstellt und ausgetauscht wurde kann man sich direkt als root anmelden!

Tommes

 

[blurrrr]

@Tommes: jo, ist schon klar, wäre halt der direkte Weg gewesen Danke für den Hinweis mit dem Ultimate Backup (da kommt man hier im Forum ja sowieso nicht dran vorbei ), aber die Synos sind bei mir i.d.R. nur Backup-"Target" und werden meistens nicht gesichert, oder brauchen schlichtweg kein Backup

 

[kartaga]

Mahlzeit,

ich befürchte, die Posts gehen nun teilweise etwas am Thema vorbei :-(
Ich MUSS ja den Schlüssel für den ROOT-Zugriff anlegen, damit der Mailserver Plus die Migrationsaufgabe durchführen kann (beid der Migration soll ja alles automatisch passieren, da kann ich nichts über die Konsole beeinflussen).


Ich "denke"/ "hoffe", ich habe den Schlüssel korrekt erzeugt und auf der neuen DS abgelegt. Leider funktioniert es trotzdem nicht.
Für eine Fehlersuche fehlen mit die UNIX/SSH Kenntnisse.

Wenn ich wüsste wie, würde ich nun Fehlersuche betreiben, aber ich weiss halt nicht wie...
- Überprüfen, ob eine Datei mit dem Schlüssel angelegt wurde
- ist der Schlüssel korrekt?
- es gibt verschiedene "Grade" für den Schlüssel, kann das einen Einfluss haben? Ich habe es auf "einfach" stehen...?
- ist der Schlüssel eventuell korrekt hinterlegt, aber sonst irgendetwas blockiert den root-Zugriff...?

....

 

[blurrrr]

Je nachdem wie man es gestalten möchte. In der Regel wird die Key-Authentifizierung zur passwortlosen Authentifizierung zwischen 2 Systemen genutzt (so scheint das - denke ich mal - auch bei Dir der Fall zu sein). Ob die Keys dann entsprechend korrekt hinterlegt sind, kannst Du einfach testen indem Du Dich von einem System auf das anderen verbindest. Das sollte dann einfach "instant" klappen, ohne weitere Abfragen.

EDIT: Das ganze sollte dann so aussehen:

root@s1:~# ssh root@s2
root@s2:~#

 

[kartaga]

Hallo blurrrr,

das ist mir klar, aber dann bekomme ich eine Fehlermeldung:
ssh_exchange_identification read connection reset by peer

Das habe ich aber oben schon geschrieben.


Weisst du, warum ich diese Fehlermedung bekomme und nicht etwa nur ein simples "access denied"???

 

[kartaga]

Hi Tommes,

du hast ja auch mehrere DS im Einsatz. Ich gehe mal davon aus, daß du keinen Schlüssel hinterlegt hast.
Könntest du bitte mal gucken, welche Fehlermeldung du bekommst, wenn du

root@s1:~# ssh root@s2
root@s2:~#

ausführst?

Ich will einfach nur wissen, ob mein Schlüssel bereits Beachtung findet, oder ob auch du dann die von mir gepostete Fehlermeldung bekommst:
ssh_exchange_identification read connection reset by peer

Das wäre echt nett

 

[goetz]

Hallo,
schau mal was
ssh -v root@<IP>
an Infos liefert (evtl. auch -vvv).

Gruß Götz

 

[blurrrr]

Sind denn beide Systeme auf dem gleichen Stand (DSM)? Zusätzlich könnte auch in Blick in die auth.log helfen (am besten via tail: "tail -f /var/log/auth.log" in einer eigenen Konsole) und dazu das von goetz vorgeschlagene "-v" beim Aufbau der SSH-Verbindung. Bei den ganzen "Versuchen" solltest Du auch immer die Liste der blockierten Hosts im Auge behalten

EDIT: Ach und bitte nochmal den Auszug von "arp -a" (von Deiner Windows-Kiste, da brauchen wir nur die Einträge von Deiner LAN-Schnittstelle und die beiden betroffenen IP-Adressen)