Frage Sie können sich nicht über SSH bei Konten anmelden, die die / bin / bash-Shell auf dem Synology NAS verwenden


Ich versuche, bash als Standard-Shell auf einem ARM-Linux zu installieren, der auf einem Embedded-Gerät (Synology DS212 + NAS) läuft. Aber da stimmt etwas wirklich nicht, und ich kann nicht herausfinden, was es ist.

Symptome:

1) Root hat / bin / bash als Standard-Shell und kann sich normal über SSH einloggen:

$ grep root /etc/passwd
root:x:0:0:root:/root:/bin/bash

$ ssh root@NAS
root@NAS's password:
Last login: Sun Dec 16 14:06:56 2012 from desktop
# 


2) joeuser hat / bin / bash als Standard-Shell und erhält "Permission denied", wenn versucht wird, sich über SSH anzumelden:

$ grep joeuser /etc/passwd
joeuser:x:1029:100:Joe User:/home/joeuser:/bin/bash

$ ssh joeuser@localhost
joeuser@NAS's password:
Last login: Sun Dec 16 14:07:22 2012 from desktop
Permission denied, please try again.
Connection to localhost closed.


3) joeusers Shell zurück in / bin / sh ändern:

$ grep joeuser /etc/passwd
joeuser:x:1029:100:Joe User:/home/joeuser:/bin/sh

$ ssh joeuser@localhost
Last login: Sun Dec 16 15:50:52 2012 from localhost
$ 


Um die Sache noch merkwürdiger zu machen, kann ich mich als joeuser einloggen /bin/bash Verwenden der seriellen Konsole (!). Auch ein su - joeuser als root funktioniert gut, so dass die bash binary selbst gut funktioniert.

In einem Akt der Verzweiflung änderte ich Jousers UID auf 0 / etc / passwd, aber auch nicht, also scheint es nicht etwas mit der Erlaubnis zu tun zu haben.

Sieht so aus, als ob bash eine extra Überprüfung durchführt, die sshd nicht mag, und die Verbindungen für Nicht-root-Benutzer blockiert. Vielleicht eine Art Überprüfung der Benutzerfreundlichkeit - oder Terminal-Emulation - die SIGCHLD auslöst, aber nur, wenn sie über ssh aufgerufen wird.

Ich habe bereits jedes einzelne Element auf sshd_config durchlaufen und SSHD auch in den Debug-Modus gesetzt, aber nichts Seltsames gefunden. Hier ist meins /etc/ssh/sshd_config:

LogLevel DEBUG
LoginGraceTime 2m
PermitRootLogin yes
RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile      %h/.ssh/authorized_keys
ChallengeResponseAuthentication no
UsePAM yes
AllowTcpForwarding no
ChrootDirectory none
Subsystem       sftp    internal-sftp -f DAEMON -u 000


Und hier ist die Ausgabe von /usr/syno/sbin/sshd -d, zeigt den fehlgeschlagenen Versuch von Joeuser, sich einzuloggen, mit / bin / bash als Shell:

debug1: Config token is loglevel
debug1: Config token is logingracetime
debug1: Config token is permitrootlogin
debug1: Config token is rsaauthentication
debug1: Config token is pubkeyauthentication
debug1: Config token is authorizedkeysfile
debug1: Config token is challengeresponseauthentication
debug1: Config token is usepam
debug1: Config token is allowtcpforwarding
debug1: Config token is chrootdirectory
debug1: Config token is subsystem
debug1: HPN Buffer Size: 87380
debug1: sshd version OpenSSH_5.8p1-hpn13v11
debug1: read PEM private key done: type RSA
debug1: private host key: #0 type 1 RSA
debug1: read PEM private key done: type DSA
debug1: private host key: #1 type 2 DSA
debug1: read PEM private key done: type ECDSA
debug1: private host key: #2 type 3 ECDSA
debug1: rexec_argv[0]='/usr/syno/sbin/sshd'
debug1: rexec_argv[1]='-d'
Set /proc/self/oom_adj from 0 to -17
debug1: Bind to port 22 on ::.
debug1: Server TCP RWIN socket size: 87380
debug1: HPN Buffer Size: 87380
Server listening on :: port 22.
debug1: Bind to port 22 on 0.0.0.0.
debug1: Server TCP RWIN socket size: 87380
debug1: HPN Buffer Size: 87380
Server listening on 0.0.0.0 port 22.

debug1: Server will not fork when running in debugging mode.
debug1: rexec start in 6 out 6 newsock 6 pipe -1 sock 9
debug1: inetd sockets after dupping: 4, 4
Connection from 127.0.0.1 port 52212
debug1: HPN Disabled: 0, HPN Buffer Size: 87380
debug1: Client protocol version 2.0; client software version OpenSSH_5.8p1-hpn13v11
SSH: Server;Ltype: Version;Remote: 127.0.0.1-52212;Protocol: 2.0;Client: OpenSSH_5.8p1-hpn13v11
debug1: match: OpenSSH_5.8p1-hpn13v11 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.8p1-hpn13v11
debug1: permanently_set_uid: 1024/100
debug1: MYFLAG IS 1
debug1: list_hostkey_types: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: AUTH STATE IS 0
debug1: REQUESTED ENC.NAME is 'aes128-ctr'
debug1: kex: client->server aes128-ctr hmac-md5 none
SSH: Server;Ltype: Kex;Remote: 127.0.0.1-52212;Enc: aes128-ctr;MAC: hmac-md5;Comp: none
debug1: REQUESTED ENC.NAME is 'aes128-ctr'
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: expecting SSH2_MSG_KEX_ECDH_INIT
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: KEX done
debug1: userauth-request for user joeuser service ssh-connection method none
SSH: Server;Ltype: Authname;Remote: 127.0.0.1-52212;Name: joeuser
debug1: attempt 0 failures 0
debug1: Config token is loglevel
debug1: Config token is logingracetime
debug1: Config token is permitrootlogin
debug1: Config token is rsaauthentication
debug1: Config token is pubkeyauthentication
debug1: Config token is authorizedkeysfile
debug1: Config token is challengeresponseauthentication
debug1: Config token is usepam
debug1: Config token is allowtcpforwarding
debug1: Config token is chrootdirectory
debug1: Config token is subsystem
debug1: PAM: initializing for "joeuser"
debug1: PAM: setting PAM_RHOST to "localhost"
debug1: PAM: setting PAM_TTY to "ssh"
debug1: userauth-request for user joeuser service ssh-connection method password
debug1: attempt 1 failures 0
debug1: do_pam_account: called
Accepted password for joeuser from 127.0.0.1 port 52212 ssh2
debug1: monitor_child_preauth: joeuser has been authenticated by privileged process
debug1: PAM: establishing credentials
User child is on pid 9129
debug1: Entering interactive session for SSH2.
debug1: server_init_dispatch_20
debug1: server_input_channel_open: ctype session rchan 0 win 65536 max 16384
debug1: input_session_request
debug1: channel 0: new [server-session]
debug1: session_new: session 0
debug1: session_open: channel 0
debug1: session_open: session 0: link with channel 0
debug1: server_input_channel_open: confirm session
debug1: server_input_global_request: rtype no-more-sessions@openssh.com want_reply 0
debug1: server_input_channel_req: channel 0 request pty-req reply 1
debug1: session_by_channel: session 0 channel 0
debug1: session_input_channel_req: session 0 req pty-req
debug1: Allocating pty.
debug1: session_new: session 0
debug1: session_pty_req: session 0 alloc /dev/pts/1
debug1: server_input_channel_req: channel 0 request shell reply 1
debug1: session_by_channel: session 0 channel 0
debug1: session_input_channel_req: session 0 req shell
debug1: Setting controlling tty using TIOCSCTTY.

debug1: Received SIGCHLD.
debug1: session_by_pid: pid 9130
debug1: session_exit_message: session 0 channel 0 pid 9130
debug1: session_exit_message: release channel 0
debug1: session_by_tty: session 0 tty /dev/pts/1
debug1: session_pty_cleanup: session 0 release /dev/pts/1
Received disconnect from 127.0.0.1: 11: disconnected by user
debug1: do_cleanup
debug1: do_cleanup
debug1: PAM: cleanup
debug1: PAM: closing session
debug1: PAM: deleting credentials


Hier haben Sie die volle Ausgabe von sshd -dd, zusammen mit ssh -vv.

Bash:

# bash --version
GNU bash, version 3.2.49(1)-release (arm-none-linux-gnueabi)
Copyright (C) 2007 Free Software Foundation, Inc.

Die Bash-Binärdatei wurde aus der Quelle kompiliert. Ich habe auch versucht, eine vorkompilierte Binärdatei aus der Optware-Verteilung, hatte aber genau das gleiche Problem. Ich habe nach fehlenden gemeinsamen Bibliotheken gesucht objdump -xaber sie sind alle da.

Irgendwelche Ideen, was das verursachen könnte "Zugang verweigert, versuche es bitte erneut."Ich tauche fast im Bash-Quellcode, um Nachforschungen anzustellen, aber versuche Stunden zu vermeiden, etwas zu jagen, das albern sein könnte.

BEARBEITEN: Hinzufügen weiterer Informationen über Bash und das System

$ ls -la /bin/bash
-rwxr-xr-x    1 root     root        724676 Dec 15 23:57 /bin/bash

$  file /bin/bash
/bin/bash: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.14, stripped

$  uname -a
Linux NAS 2.6.32.12 #2661 Mon Nov 12 23:10:15 CST 2012 armv5tel GNU/Linux synology_88f6282_212+

$ grep bash /etc/shells
/bin/bash
/bin/bash2

30
2017-12-16 21:34


Ursprung


ls -l /bin/bash - Michael Hampton♦
Ist / bin / bash in / etc / shells aufgelistet? - tink
Ja, es ist in / etc / shells aufgeführt. Und Berechtigungen 0755, oben hinzugefügt. - Gui Ambros
Höchstwahrscheinlich wird etwas in seiner .bashrc-Datei ausgeführt. Kannst du ~ joeuser / .bashrc catchen und seine Profilskripte durchsuchen? Sie können auch versuchen, / bin / bash auszuführen, während Sie als eingeloggt sind. - vicfn
No ~ joeuser / .ssh und keine Profilskripte. Es ist ein leerer Benutzer, den ich gerade zum Testen erstellt habe. - Gui Ambros


Antworten:


Zukünftige Referenz: Nachdem ich zu viele Stunden damit verbracht habe, dieses Problem zu erforschen und zu debuggen, habe ich endlich die Ursache entdeckt.

Die von Synology verwendete OpenSSH-Version ist eine hochgradig angepasste Version nicht verhalten sich wie der ursprüngliche Code. Es hat viele Hacks und Ad-hoc-Anpassungen - z. B. zusätzliche Prüfung vor dem Akzeptieren einer Anmeldung, um zu sehen, ob der SSH-Dienst in der Weboberfläche aktiviert ist, oder spezielle Zeichen (;, |, ') aus rsync-Befehlen oder .. . warte darauf... Vermeiden Sie, dass normale Benutzer eine andere Shell verwenden als / bin / sh oder / bin / ash. Ja, hart codiert innerhalb der Binärdatei.

Hier ist das Stück Code von OpenSSH 5.8p1, wie es von Synology auf ihren Quellcode verteilt wurde (DSM4.1 - Zweig 2636), Datei session.c:

void do_child(Session *s, const char *command)
{
...

#ifdef MY_ABC_HERE
   char szValue[8];
   int RunSSH = 0;
   SSH_CMD SSHCmd = REQ_UNKNOWN;

   if (1 == GetKeyValue("/etc/synoinfo.conf", "runssh", szValue, sizeof(szValue))) {
           if (strcasecmp(szValue, "yes") == 0) {
                   RunSSH = 1;
           }
   }

   if (IsSFTPReq(command)){
           SSHCmd = REQ_SFTP;
   } else if (IsRsyncReq(command)){
           SSHCmd = REQ_RSYNC;
   } else if (IsTimebkpRequest(command)){
           SSHCmd = REQ_TIMEBKP;
   } else if (RunSSH && IsAllowShell(pw)){
           SSHCmd = REQ_SHELL;
   } else {
           goto Err;
   }

   if (REQ_RSYNC == SSHCmd) {
           pw = SYNOChgValForRsync(pw);
   }
   if (!SSHCanLogin(SSHCmd, pw)) {
           goto Err;
   }
   goto Pass;

 Err:
   fprintf(stderr, "Permission denied, please try again.\n");
   exit(1);

 Pass:
   #endif /* MY_ABC_HERE */
...
}


Wie Sie sich vorstellen können, die IsAllowShell(pw) war der Schuldige:

static int IsAllowShell(const struct passwd *pw)
{
     struct passwd *pUnPrivilege = NULL;
     char *szUserName = NULL;
     if (!pw || !pw->pw_name) {
             return 0;
     }
     szUserName = pw->pw_name;
     if(!strcmp(szUserName, "root") || !strcmp(szUserName, "admin")){
             return 1;
     }
     if (NULL != (pUnPrivilege = getpwnam(szUserName))){
             if (!strcmp(pUnPrivilege->pw_shell, "/bin/sh") || 
                     !strcmp(pUnPrivilege->pw_shell, "/bin/ash")) {
                     return 1;
             }
     }
     return 0;
}


Kein Wunder, warum ich so ein komisches Verhalten hatte. Nur shells / bin / sh und / bin / ash würden für andere Benutzer akzeptiert als Wurzel oder Administrator. Und das unabhängig von der uid (ich hatte auch getestet Joeuser UID = 0, und es hat nicht funktioniert. Jetzt ist es offensichtlich, warum).

Sobald die Ursache gefunden war, war die Fehlerbehebung einfach: Entfernen Sie einfach den Anruf zu IsAllowShell (). Ich brauchte eine Weile, um die richtige Konfiguration zu finden, um openssh und all seine Abhängigkeiten zu kompilieren, aber es hat am Ende gut funktioniert.

Wenn jemand daran interessiert ist, das Gleiche zu tun (oder andere Kernel-Module oder Binärdateien für Synology zu kompilieren), Hier ist meine Version von Makefile. Es wurde mit getestet OpenSSH-5.8p1-Quelleund funktioniert gut mit Modellen mit Marvell Kirkwood mv6281 / mv6282 CPU (wie DS212 +). Ich benutzte einen Host mit Ubuntu 12.10 x64.

Fazit: schlechte Praxis, schrecklicher Code und ein gutes Beispiel dafür nicht machen. Ich verstehe manchmal, OEMs müssen spezielle Anpassungen entwickeln, aber sie sollten zweimal überlegen, bevor sie zu tief graben. Nicht nur das führt zu nicht mehr zu erhaltendem Code für sie, sondern es entstehen auch viele unvorhergesehene Probleme auf der Straße. Zum Glück gibt es GPL, um sie ehrlich zu halten - und offen.


37
2018-01-21 00:35



Stellar arbeiten, Sir, bei der Untersuchung dieses Problems und den Vorhang aus der Synology Bühne zurückziehen. Ich muss zugeben, dass ich bis jetzt sehr viel über meine Diskstation gedacht hatte, da es sehr nützlich war und nach dem Bootstrapping laufen jetzt sogar einige Skripte für mich unter dem neuen Taskplaner. Aber Sie haben hier einige Schwachstellen im kurzsichtigen Design aufgedeckt. Ich bin immer noch zufrieden mit der Diskstation, werde aber Ihre Post behalten. Upvoted sowohl Post als auch Antwort. - Bernard Dy
Upvoted für die Mühe. Wenn ich keine Müsli-Verbindungen machen will, möchte ich einfach die Standard-Shell auf ändern /bin/sh, gibt es einen Weg, es zu tun? - Vicary
Warum Synology dies tun würde, ist total jenseits von mir :( - Gerhard Burger
Ich habe umbenannt /bin/ash zu /bin/ash.real und verlinkt zsh beim /bin/ash... bisher scheint alles in Ordnung ... o_o - x1a0
Registriert nur, um Ihre Antwort zu verbessern. - Tamás Zahola


Um das Problem zu umgehen, und da ich bash via ipkg installiert habe und ich kann nicht sicher sein, / opt wird immer verfügbar sein (mounted correct), ich einfach die folgenden in meine .profile

[ -x /opt/bin/bash ] && exec /opt/bin/bash

während / etc / passwd enthält / bin / Asche als Shell.


7
2018-03-11 09:21





Mal schauen. Es ist isoliert auf eine einzige Shell, und Sie sehen sich die sshd-Debug-Ausgabe an, es sind also keine schreibbaren Berechtigungsprobleme mit ~ joeuser / .ssh. Das ist derjenige, der die meisten Menschen erreicht.

Haben Sie versucht, einen zusätzlichen normalen Benutzer (d. H. Nicht joeuser) zu erstellen, um sicherzustellen, dass das gleiche Problem auftritt? Das würde es für die Konfiguration des Benutzers gegenüber der systemweiten Konfiguration isolieren.

Wenn es sich um ein systemweites Problem handelt, werden mir als nächstes die freigegebenen Konfigurationsdateien wie / etc / profile angezeigt, die von allen bereitgestellt werden. Möglicherweise gibt es einen bedingten Block, der nicht auslöst, wenn der Benutzername root ist. (nicht effektive userid, da du schon getestet hast)

Überprüfen Sie dmesg auf Segmentierungsfehlerberichte, falls Sie dies nicht bereits getan haben, nur für den Fall, dass etwas noch seltsamer vor sich geht.


1
2018-01-06 06:40



Danke, Andrew. Auch überprüft dmesg und absolut nichts. Die Erstellung eines brandneuen Benutzers hat auch nicht geholfen, es handelt sich also eindeutig um ein systemweites Problem. Und joeuser kann sich normal anmelden, wenn ich die Shell zurück in / bin / asche ändere, was irgendein / etc / profile oder anderes ausschließt (was ich auch überprüft habe, btw). Es ist nur mit Nicht-Root, mit bash, via ssh. Als dieser Punkt ist es nicht einmal ein echtes Problem (ich kann damit leben, wie es jetzt ist), aber es ärgert mich zugeben, dass ich nicht in der Lage war, die Ursache für dieses seltsame Verhalten zu finden. Es ist schließlich ein deterministisches System; Dort Muss sei eine Art Erklärung ... - Gui Ambros


probiere / etc / ssh / sshd_config
Suche nach AllowUsers

Wenn es da ist, versuche es mit joeuser, nur mit Benutzername

es kann auch in pam blockiert werden ... Ich weiß nicht, welche Datei es ist ...


1
2018-01-09 12:21



Nicht der Fall. Wenn es ein Problem mit AllowUsers wäre, würde ich mich nicht mit Joeuser anmelden, wenn ich die Shell in / bin / Asche ändere. Dies scheint nichts mit sicherheitsrelevanten oder anderen Konfigurationen zu tun zu haben. Es ist wahrscheinlich eine Art, wie bash Pseudo-Terminals über ssh behandelt, im Gegensatz zu Asche, Csh usw. - Gui Ambros


Ihre modifizierte Version von openssh sucht nach einem /bin/sh Schale?

Einfache Lösung dann:

ln -fs / bin / bash / bin / sh


1
2018-04-08 21:44



Dies würde die Shell für alle Benutzer ändern, und nicht nur für diejenigen, die bash benötigen. Auch jedes neue Upgrade würde den symbolischen Link entfernen (obwohl das Beheben von openssh das gleiche Problem hat). Wie auch immer, das wurde wie oben beschrieben gelöst. - Gui Ambros
OK stimmt, aber da ich der einzige Benutzer auf meinem NAS bin, funktioniert diese Lösung für mich. Wie auch immer, danke für das, was du herausgefunden hast. - Ponytech


Versuchen Sie, Bash neu zu installieren und sehen Sie, ob das hilft.


0
2017-12-17 08:02



Nops, ich habe bash von zwei verschiedenen Quellen (eine von der Distribution von Optware, und ich habe auch 3.2 selbst aus der Quelle kompiliert), und dasselbe Problem. Ich ging bis zum äußersten, sogar bash 4.2 und die Patches (alle 39 von ihnen) und Cross-Compiling. Genau dasselbe Verhalten. Arbeitet mit Root, Zugang verweigert für andere. Meine letzte Vermutung ist die OpenSSH-Binärdatei, die standardmäßig von der Synology-Firmware installiert wird. Dies ist das einzige Stück, das ich noch nicht berührt habe. Ich werde versuchen, die neueste Quelle und das Cross-Compiling herunterzuladen, um zu sehen, was passiert. - Gui Ambros
Seltsam nicht sicher aber das scheint authconfig Problem zu sein. Läuft ldap auch auf dem Server? Können Sie mir zum Zeitpunkt des Anmeldeversagens eine Echtzeitprotokollausgabe der sicheren und der Nachrichtendatei senden? - Pratap
Melden Sie sich auch als root beim Server an und lassen Sie die Shell des Benutzers / bin / bash und versuchen Sie, mit su - username auf den Benutzer zu wechseln. Zeig mir auch das Ergebnis. - Pratap


Falls jemand darüber stolpert, weil sie den gleichen Fehler gemacht haben wie ich:

Ja: $ sudo usermod -s /bin/bash your_username

Nein: $ sudo usermod -s bash your_username

Die zweite wird dazu führen, dass eine Berechtigung verweigert wird, wenn man sich anschickt.


0
2017-12-11 19:53