DS 414: Kein Zugriff via SSH

[Stanger]

Hallo zusammen,
vorweg, ich bin totaler Laie bzgl. DSM und Linux.

Ich versuche derzeit via SSH auf die Diskstation zuzugreifen was damit scheitert daß ich bei "ssh user@meineip" die Fehlermeldung "Permission denied" als Rückmeldung bekomme.
Client ist ein Linux Mint Cinnamon 17.3 Rechner.

Firewall am Client habe ich testweise schonmal deaktiviert aber ohne Erfol beim erneuten Verbindungsaufbau.
Alternativ habe ich auch mal das Standard-Admin Konto getestet -> ebenso ohne Erfolg.

Ping zur DS ist Ok. In der DS Oberfläche habe ich auch schon geguckt ob da was fehlt -> tappe derzeit im Dunklen.

Bitte um Hilfe.
mfg
Stanger

 

[dil88]

Ist ssh im DSM-Webfrontend aktiviert worden?

 

[Stanger]

SSH ist aktiviert ja. Unter Terminal & SNMP.

Stanger

 

[Fusion]

Kannst mal ssh -v(vv) user@DS-IP ausführen und die Ergebnisse posten. Die Anzahl der v(erbose) erhöht die "Geschwätzigkeit" des Clients.

 

[Stanger]

Hi Fusion

da kommt bei mir

bash: Syntaxfehler beim unerwarteten Wort »(«

Die IP und den Benutzernamen habe ich eingegeben - muß bei v bzw. vv noch was angepasst werden ?

mfg
Stanger

 

[Fusion]

Du musst entweder -v oder -vv oder -vvv verwenden. Die Klammer war nur zur Verdeutlichung und ist nicht teil des Befehls.

 

[Stanger]

Hallo,
ist mir auch gerade gekommen als du bereits geantwortet hattest.

Nach Eingabe des Befehls kam folgendes:

OpenSSH_6.6.1, OpenSSL 1.0.1f 6 Jan 2014
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to IP [IP] port 22.
debug1: Connection established.
debug1: permanently_set_uid: 0/0
debug1: identity file /root/.ssh/id_rsa type -1
debug1: identity file /root/.ssh/id_rsa-cert type -1
debug1: identity file /root/.ssh/id_dsa type -1
debug1: identity file /root/.ssh/id_dsa-cert type -1
debug1: identity file /root/.ssh/id_ecdsa type -1
debug1: identity file /root/.ssh/id_ecdsa-cert type -1
debug1: identity file /root/.ssh/id_ed25519 type -1
debug1: identity file /root/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.6.1p1 Ubuntu-2ubuntu2.7
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.8p1-hpn14v6
debug1: match: OpenSSH_6.8p1-hpn14v6 pat OpenSSH* compat 0x04000000
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr umac-128-etm@openssh.com none
debug1: kex: client->server aes128-ctr umac-128-etm@openssh.com none
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ECDSA ee:c0:*entfernt*
The authenticity of host 'IP (IP' can't be established.
ECDSA key fingerprint is ee:c0:*entfernt*.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'IP' (ECDSA) to the list of known hosts.
debug1: ssh_ecdsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Trying private key: /root/.ssh/id_rsa
debug1: Trying private key: /root/.ssh/id_dsa
debug1: Trying private key: /root/.ssh/id_ecdsa
debug1: Trying private key: /root/.ssh/id_ed25519
debug1: Next authentication method: password
Primeeval@x.x.x.x's password: 
debug1: Authentication succeeded (password).
Authenticated to IP([IP]:22).
debug1: channel 0: new [client-session]
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug1: client_input_global_request: rtype hostkeys-00@openssh.com want_reply 0
debug1: SSH2_MSG_KEXINIT received
debug1: SSH2_MSG_KEXINIT sent
debug1: kex: server->client aes128-ctr umac-128-etm@openssh.com none
debug1: kex: client->server aes128-ctr umac-128-etm@openssh.com none
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ECDSA ee:c0*enttfernt*
debug1: Host 'IP' is known and matches the ECDSA host key.
debug1: Found key in /root/.ssh/known_hosts:2
debug1: ssh_ecdsa_verify: signature correct
debug1: set_newkeys: rekeying
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: set_newkeys: rekeying
debug1: SSH2_MSG_NEWKEYS received
debug1: Sending environment.
debug1: Sending env LANG = de_DE.UTF-8
Permission denied, please try again.
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug1: client_input_channel_req: channel 0 rtype eow@openssh.com reply 0
debug1: channel 0: free: client-session, nchannels 1
Connection to IP closed.
Transferred: sent 4868, received 3280 bytes, in 0.1 seconds
Bytes per second: sent 39514.9, received 26624.7
debug1: Exit status 1

mfg
Stanger

 

[Fusion]

ok, und wo ist da jetzt ein permission denied bzw überhaupt ein Fehler? Ich sehe da nix in die Richtung

 

[laserdesign]

@Fusion, du hast nicht herunter gescrollt.

 

[Fusion]

Hatte ich, aber irgendwie war wohl die Seite nicht ganz geladen. Na ja, genau diesen Fehler kenne ich jetzt noch nicht. Kann noch -vv und -vvv probieren, aber ansonsten müßte ich auch erstmal auf die Suche gehen

 

[Stanger]

Nur um jetzt nicht das einfachste zu übersehen, muß ich irgendwelche Zertifikate von der DS auf den Client runterladen und installieren ?
Bin wie gesagt absoluter Newbie mit Linux und DSM via Shell.
Stanger

 

[Fusion]

Nein, Zertifkate brauchst du nur, wenn du dich direkt als root anmelden willst.
Solange du nur den Admin oder andere Benutzer anmelden willst geht auch Passwort.

Nachtrag:
DS Firewall muss natürlich angepaßt oder ausgeschaltet sein.

 

[AdRay]

Welches Kennwort hast du für den User verwendet?
seit DSM 6.0 muss man sich mit Username und dem Kennwort des admin-Kontos anmelden.
Man kann sich nun nicht mehr mit `root´ und dem admin-Kennwort anmelden.

Das admin-Kennwort darf nicht leer sein, auch wenn das Konto deaktiviert ist.

Oder hat's inzwischen geklappt?


MfG
Ray

 

[Stanger]

Welches Kennwort hast du für den User verwendet?

Das Kennwort für den User lautet: 4892ckk230kkll

Nein, ernsthaft, ich habe den standard Admin-Account (admin) deaktiviert und verwende einen anderen Login mit Passwort aus der Gruppe der admins.

Oder hat's inzwischen geklappt?

Nein, leider immer noch nicht.

mfg
Stanger

 

[AdRay]

ja, siehst du. Das meine ich
ich möchte nicht dein Kennwort wissen, sondern welches du verwendet hast.
Aber nach meiner Erfahrung musst du genau das admin-Kennwort nehmen und nicht eins aus der Gruppe der Admins.

Probier das mal aus.
Beliebiger Nutzer aus Admin-Gruppe und Admin-Kennwort, nicht das des Nutzers

 

[Stanger]

Ich habe dich schon verstanden

Leider das gleiche Bild:

Permission denied, please try again.
user@192.168.x.y's password:

mfg
Stanger

 

[the other]

Moinsen,
habe hier das gleiche Setting (andere Diskstation, aber Linux und Zugriff auf NAS per ssh). Ich kann die Einschätzung, dass ssh nur für admin-Gruppen user funktioniert bzw. unbedingt ein admin Passwort eingegeben werden muss, nicht teilen.
Bei mir kann ich (wenn in /etc/passwd auf NAS korrekt konfiguriert) mit jedem user und dem user Passwort auf das NAS einloggen, dann halt mit genau den Rechten, die ich dem jeweiligen user auf der Synology gegeben habe.
Was dagegen nicht funktioniert, ist einen user mit dem admin Passwort einzuloggen:
Permission denied, please try again.

Versuche ich es aber mit dem zum user gehörenden Passwort, dann keine Meldung (obwohl der user nicht Mitglied der Gruppe admins auf der Synology).
Hast du das schon versucht?
grüßle
the other

 

[the other]

Nachtrag: um nicht falsch verstanden zu werden...(habe ich echt oben blöd geschrieben!)
Im Terminal auf dem Desktop melde ich mich als admin der Synology mit dem admin Passwort an (als user geht nur nach Änderung der /etc/passwd auf der synology mittels nano, AFAIK). Als user nicht. Per Filezilla, Gigolo, etc gebe ich aber den jeweiligen user an, und dann dazu das zugeteilte Userpasswort.
Kontrolliere doch auch mal, was für die admins unter /etc/passwd eingetragen ist. Am Ende der Zeile admin sollte

/bin/sh

stehen...

Grüßle
the other