Synology-Forum.nl
Firmware => Synology DSM BETA versies => Topic gestart door: TopGear_1542 op 08 oktober 2017, 10:02:47
-
Ik ben nu twee dagen bezig om in te loggen via SSH op DSM 6.2. Dit heb ik gedaan via MacOS 10.13 en WinSCP op Windows 10.
Hiervoor heb ik deze (https://www.synology-forum.nl/algemeen/nas-benaderen-met-ssh-winscp-putty/) tutorial gevolgd. Via WinSCP krijg ik de melding "Toegang geweigerd" en via MacOS krijg ik de melding "Permission denied". Hiervoor heb ik gekeken naar de firewall instellingen van de NAS waar ik op in wil loggen. Deze firewall laat voor poortnummer 22 op dit moment alles toe vanaf mijn netwerk. Uiteraard heb ik via Configuratiescherm >> Terminal een vinkje geplaatst bij SSH en daar heb ik via de knop [Geavanceerde instellingen] het beveiligingsniveau op laag gezet. Gewoon om uit te sluiten dat het daar aan zou kunnen liggen. Overigens heb ik het admin account weer tijdelijk ingeschakeld en zowel met gebruikersnaam "admin" als "root" geprobeerd in te loggen. Zoals je begrijpt, beide zonder succes.
-
Hm.....zal straks ff kijken.
-
Meestal, als je een upgrade krijgt , moet je /etc/sudoers weer aanpassen volgens m'n tut (https://www.synology-forum.nl/algemeen/nas-benaderen-met-ssh-winscp-putty/), dus nu weer:
[attachimg=1]
De regel admin ALL = NOPASSWD: ALL weer toevoegen:
[attachimg=2]
En als je uit vi bent, de write rechten weer voor die file weghalen: chmod -w /etc/sudoers
En WinSCP werkt weer met gebruiker root, dus waarschijnlijk heb je toch iets niet goedgedaan, in die 2 dagen. ;)
-
Om dat aan te kunnen passen heb je wel toegang tot een Linux terminal nodig via SSH voor zover mij bekend. En ook dat lukt niet via de MacOS terminal. Ik heb het IP adres wel al een keer laten blokkeren door de NAS. Het verzoek komt klaarblijkelijk dus wel aan bij de NAS. Ik word om een of andere reden alleen niet toe gelaten. M.a.w. hoe kom ik nu verder in de terminal?
In ieder geval goed om te weten dat het jou wel lukt. Is daarmee geen algemeen probleem.
-
Log je wel met een administrator in? Via een gewoon user account, zonder admin-rechten krijg je altijd een permission denied.
Werkte het bij DSM 6.1 wel met het gebruikte account?
-
Om dat aan te kunnen passen heb je wel toegang tot een Linux terminal nodig via SSH voor zover mij bekend.
Op Windows doe je dat met PuTTY (http://www.putty.org/), probeer het gewoon eens, dan weet je of het aan OS X ligt.
-
Op Windows doe je dat met PuTTY, probeer het gewoon eens, dan weet je of het aan OS X ligt.
Inmiddels een poging gewaagd met PuTTY. Onderstaande is het resultaat.
Log je wel met een administrator in? Via een gewoon user account, zonder admin-rechten krijg je altijd een permission denied.
Zoals je in de schermafdrukken kunt zien heb ik het geprobeerd met "root" en met "admin". Deze laatste heb ik voor de gelegenheid even weer geactiveerd.
Werkte het bij DSM 6.1 wel met het gebruikte account?
Het is lang geleden dat ik het nodig heb gehad. Ik weet het niet zeker.
Na de update naar DSM 6.2 beta krijg ik de opmerking dat er een abnormale gebruiker (ffsync) op mijn NAS aanwezig is (zie schermafbeelding). Heb ooit een pakket t.b.v. het syncen van Firefox op mijn NAS gehad. Deze is inmiddels verwijderd, maar blijkbaar niet volledig. Tenminste, ik ga er vanuit dat het daarmee te maken heeft. Deze gebruiker kan ik niet vinden a.d.h.v. de UI. Vandaar dat ik deze graag via de Terminal wil verwijderen.
-
Ik zie niet je PuTTY scherm dat je inlogt als admin en daarna sudo -i :!:
-
Of ik nu met “admin” of “root” inlog, bij beide krijg ik “Access denied”. Krijg daarom niet de gelegenheid voor een tweede commando als “sudo -i”
-
Misschien ben je ondertussen geblokkeerd ?
Kijk even of dat zo is in DSM.
-
Nee, ik heb het IP adres toegevoegd aan de lijst “Toestaan”. En, nee, na extra controle staat er geen IP bij de lijst “Blokkeren”. Begrijp er niets van.
-
Ik ook niet.......even in de denktank. ;D
-
Thanx! Al het meedenken is welkom
Heb in de firewall aangegeven dat het hele subnet inmiddels toegang heeft tot alle diensten van de NAS.
-
Probeer eens een enkele reset (https://www.synology.com/nl-nl/knowledgebase/DSM/tutorial/General/How_to_reset_your_Synology_NAS#t2).
-
Of ik nu met “admin” of “root” inlog, bij beide krijg ik “Access denied”.
Daarom vroeg ik ook of het vroeger wel lukte. Het is al sinds DSM 6.0 niet meer mogelijk om met root in te loggen. Dat staat ook en de handleiding waar je in de eerste post naar verwijst. Daarom verbaast het me dat ik root steeds weer tegenkom in je screenshots.
admin is wel goed, maar ook gewoon een ander administrator account.
-
Het staat me bij dat ook het bestand waarin het certificaat op je PC opgeslagen wordt, moeilijk doet als het certificaat op de host veranderd. (~/.ssh/known_hosts). Snelste test is om dat te testen is door met een andere url in te loggen.
Op de mac b.v. niet met het "account@IP" maar met "account@nasnaam.local". Als die naam nieuw is, krijg je altijd een nieuwe certificaat vraag.
In twijfel mag je die file altijd wissen om met een schone lei te kunnen beginnen.
Edit:
Ik weet niet hoe putty hier op reageert, maar in de terminal valt dit toch op door de volgende waarschuwing:
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the RSA host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
06:ea:f1:f8:db:75:5c:0c:af:15:d7:99:2d:ef:08:2a.
Please contact your system administrator.
Add correct host key in /home/user/.ssh/known_hosts to get rid of this message.
Offending key in /home/user/.ssh/known_hosts:4
RSA host key for domain.com has changed and you have requested strict checking.
Host key verification failed.
Dus dit is het niet bij jou.
-
Een enkele reset heeft uitkomst geboden. Het is inmiddels gelukt om in te loggen op de terminal. Dankjewel!
Nu heb ik een lijst van gebruikers opgevraagd en zie inderdaad dat de gebruiker “ffsync” (Firefox) er in staat.
Welk commando kan ik gebruiken om deze gebruiker te verwijderen. Het commando “deluser -r ffsync” werkt namelijk niet. En dan schiet mijn kennis van linux toch tekort.
-
Nu heb ik een lijst van gebruikers opgevraagd
Hoe ? In PuTTY ?
Ik zou niet graag een gebruiker via PuTTY verwijderen, DSM (ook Linux based) werk n.l. iets anders dan andere varianten van Linux.
Hoe is die gebruiker in eerste instantie opgezet ? Niet via DSM Configuratie Scherm > Gebruikers ?
-
Hoe die gebruiker er gekomen is, staat in een eerdere post:
Heb ooit een pakket t.b.v. het syncen van Firefox op mijn NAS gehad. Deze is inmiddels verwijderd, maar blijkbaar niet volledig.
Hij is dus al op een ongebruikelijke, en waarschijnlijk dus verkeerde, manier aangemaakt.
Edit: Als dat een serieus pakket was, dan zal er in de read-me (of elders) ook staan hoe je alles moet verwijderen.
-
O ja, das waar maar, is off-topic, wordt nu waarschijnlijk hacken, en dan maar hopen dat het goed gaat. ;D
Je zou, om te beginnen, een cat kunnen doen van /etc/passwd om te kijken of die user daar in zit dus, als root:
cat /etc/passwd | grep ffsync
-
Even geGoogled en dit commando gevonden voor DSM om een user te deleten in CLI:
/usr/syno/sbin/synouser --del <user>
echter, ik ga niet zeggen of dit gaat werken, het is wat @Briolet ook zegt "Hij is dus al op een ongebruikelijke, en waarschijnlijk dus verkeerde, manier aangemaakt." dus.....
-
ffsync is Free File Sync.
Er is geen Package FFS dus @TopGear_1542 heeft waarschijnlijk die gebruiker aangemaakt om onder die gebruiker mappen te koppelen en te syncen?
-
Ik had “cat /etc/passwd” inmiddels uigevoerd en vond daar inderdaad de user “ffsync” en bijbehorende toepassing “Firefox Sync Server”. Omdat ik na het uitvoeren van “sudo -i” en dus als user root met twee verschillende linux commando’s het niet voor elkaar kreeg om de user te verwijderen, heb ik de stoute schoenen aangetrokken en een harde reset uitgevoerd. Inmiddels gecontroleerd of de user nu verwijderd is. Dat is het geval. Ben dus van de user af. Bedankt voor jullie hulp. Draadje mag gesloten worden wat mij betreft.
-
Wat bedoel je met harde reset?
-
Opnieuw DSM geïnstalleerd zonder de HDD’s te wissen. Of terug naar fabrieksinstellingen.
-
Zo....dat is drastisch :o
-
Tja, uiteindelijk had ik met een half uurtje á drie kwartier alles weer ingeregeld. Voelt altijd goed om een verse installatie te doen.
-
Op het Engelse forum zijn er ook mensen die problemen met SSH hebben gemeld, misschien heeft de beta iets vergeten te doen ::)
https://forum.synology.com/enu/viewtopic.php?f=288&t=135888
-
Daar zijn beta's ook voor: het ontdekken van bugs.
Uit dat Engelse verhaal begrijp ik dat als je 2FA gebruikt, dit ook voor SSH inlog aanstaat, maar het niet goed geïmplementeerd is, waardoor het mis gaat.
De andere problemen zijn geen echte problemen. 6.2 herstelt een beveiliging die de mensen zelf onklaar gemaakt hebben. (de sudoers file)
-
Mij zegt 2FA niets. Vraag me daarom af of dit mij ook het probleem was. In ieder geval bedankt voor het melden!
-
Twee-Faktor-Autentikatie (2FA)
-
Ok, ja die staat bij mij standaard aan. Dus dat kan inderdaad het geval zijn geweest bij mij.
-
Ik weet niet hoe het komt maar, ik had geen enkel probleem met SSH, alleen even /etc/sudoers (voor WinSCP) moeten aanpassen maar, dat is niets nieuws bij grote updates of upgrades.
Maar goed, dat had ik al eerder aangegeven.
-
Ik heb net de beta op mijn 212j gezet. Inloggen met SSH geeft inderdaad een foutmelding:
$ ssh briolet@nas2
briolet@nas2's password:
Could not chdir to home directory /var/services/homes/briolet: Permission denied
-sh: /var/services/homes/briolet/.profile: Permission denied
briolet@BackupNas:/$ exit
logout
-sh: /var/services/homes/briolet/.bash_logout: Permission denied
Connection to nas2 closed.
Dit is een probleem die er ook bij de 5.0, 6.0 en de 6.1 beta was. Een administrator heeft geen toegang tot "/var/services/homes" Na de betas was dit steeds opgelost.
sudo -i werkt echter wel en dan kun je wel overal bij. Ze dwingen je gewoon om alles via root te doen en niet via een administrator. Alleen storend dat je nu steeds langs die foutmeldingen heen moet.
-
Klopt, die meldingen krijg ik ook als ik inlog echter, bij @TopGear_1542 was het een SSH inlog probleem.
-
En na aanzetten van 2FA:
$ ssh briolet@nas2
briolet@nas2's password:
Permission denied, please try again.
briolet@nas2's password:
Ik kom er inderdaad niet meer in, zoals het Engelse forum aangeeft. Die bug is gemeld. Voorlopig 2FA uit laten als je SSH gebruikt. Of de daar genoemde fix toepassen.
Edit: Uit het Engelse forum:
For me I edited /etc/ssh/sshd_config and changed the ChallengeResponseAuthentication setting from no to yes. Then I did a "killall -1 sshd".
For some reason ChallengeResponseAuthentication was off, but that needs to be on if you have 2FA on now in 6.2 because it'll prompt for your 2FA code after entering the password.
Met deze fix loopt de inlog:
$ ssh briolet@nas2
Password:
Enter 6-digit code:
Voelt toch vreemd dat je een 2FA toevoegt aan een SSH inlog, maar dit niet test voor een release.
-
Ik las dat de default waarde van ChallengeResponseAuthentication yes is. Op de mac staat die waarde ook op yes.
Op de nas is er no van gemaakt. Na wat zoeken vond is een reden (https://access.redhat.com/solutions/336773) waarom dat vaak in no veranderd wordt. Als je er niets mee doet, kan dit een achterdeurtje voor een andere aanvullende authenticatie worden.
Omdat DSM 6.1 ook al 2FA kent, heb ik daar ook eens de ChallengeResponseAuthentication op yes gezet. Daar heeft het geen effect. Het is dus echt iets nieuws dat SSH in 6.2 ook 2FA kan gebruiken. Alleen staat hierover niets in de releasenotes. Dit is blijkbaar een feature waar ze mee geëxperimenteerd hebben, maar nog niet beslist hebben om in te bouwen.
Het ssh commando kent ook de optie "ChallengeResponseAuthentication". Misschien kun je dan ook binnenkomen als het in de config op no staat (Heb geen zin dit te testen ;)):
ssh -o ChallengeResponseAuthentication=yes briolet@nas2