Impossibile accedere tramite SSH a nessun account utilizzando la shell / bin / bash su Synology NAS

Sto cercando di installare bash come shell predefinita su un ARM Linux in esecuzione su un dispositivo incorporato (Synology DS212 + NAS). Ma c'è qualcosa di veramente sbagliato, e non riesco a capire di cosa si tratti.

Sintomi:

1) Il root ha / bin / bash come shell predefinita e può accedere normalmente tramite SSH:

$ 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 ha / bin / bash come shell predefinita e riceve "Autorizzazione negata" quando tenta di accedere tramite SSH:

$ 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) cambiando la shell di joeuser in / bin / sh:

$ 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
$ 

Per rendere le cose ancora più strane, posso accedere come joeuser /bin/bashusando la console seriale (!). Anche a su - joeusercome root funziona bene, quindi il binario bash stesso funziona bene.

In un atto di disperazione, ho cambiato l'uid di joeuser in 0 su / etc / passwd, ma anche non ha funzionato, quindi non sembra essere qualcosa legato al permesso.

Sembra che bash stia facendo qualche controllo extra che sshd non ha gradito, e sta bloccando le connessioni per utenti non root. Forse una sorta di controllo della sanità mentale - o emulazione terminale - che sta innescando SIGCHLD, ma solo quando viene chiamato via ssh.

Ho già esaminato ogni singolo elemento su sshd_config e ho anche messo SSHD in modalità debug, ma non ho trovato nulla di strano. Ecco il mio /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

Ed ecco l'output di /usr/syno/sbin/sshd -d, che mostra il tentativo fallito di joeuser che tenta di accedere, con / bin / bash come 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

Qui hai l' output completo di sshd -dd, insieme a ssh -vv .

bash:

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

Il binario bash è stato compilato in modo incrociato dalla fonte. Ho anche provato a usare un binario precompilato dalla distribuzione Optware , ma ho avuto lo stesso identico problema. Ho controllato le librerie condivise mancanti usando objdump -x, ma sono tutte lì.

Qualche idea su cosa potrebbe causare questa " Autorizzazione negata, per favore riprova. "? Sto quasi per immergermi nel codice sorgente di Bash per indagare, ma sto cercando di evitare ore inseguendo qualcosa che potrebbe essere sciocco.

EDIT: aggiunta di ulteriori informazioni su bash e sul sistema

$ 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

Per riferimento futuro: dopo troppe ore alla ricerca e al debug di questo problema, ho finalmente scoperto la causa principale.

La versione OpenSSH utilizzata da Synology è una versione altamente personalizzata, che non si comporta come il codice originale. Ha molti hack e personalizzazioni ad-hoc - ad esempio, controlli aggiuntivi prima di accettare un login per vedere se il servizio SSH è abilitato nell'interfaccia web o rimuovere caratteri speciali (;, |, ') da comandi rsync, o .. aspettalo ... evitando agli utenti normali di usare una shell diversa da / bin / sh o / bin / ash . Sì, hard coded all'interno del binario.

Ecco il pezzo di codice di OpenSSH 5.8p1, distribuito da Synology sul loro codice sorgente (DSM4.1 - branch 2636) , file 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 */
...
}

Come puoi immaginare, IsAllowShell(pw)era il colpevole:

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;
}

Non c'è da stupirsi perché stavo vivendo un comportamento così strano. Solo shell / bin / sh e / bin / ash sarebbero accettati per utenti diversi da root o admin . E questo indipendentemente dall'UID (avevo testato anche facendo joeuser uid = 0, e non ha funzionato. Ora è ovvio il perché).

Una volta identificata la causa, la correzione è stata semplice: basta rimuovere la chiamata a IsAllowShell () . Mi ci è voluto un po 'per ottenere la giusta configurazione per cross-compilare openssh e tutte le sue dipendenze, ma alla fine ha funzionato bene.

Se qualcuno è interessato a fare lo stesso (o provare a compilare in modo incrociato altri moduli del kernel o binari per Synology), ecco la mia versione di Makefile . È stato testato con sorgente OpenSSH-5.8p1 e funziona bene con i modelli che eseguono CPU Marvell Kirkwood mv6281 / mv6282 (come DS212 +). Ho usato un host con Ubuntu 12.10 x64.

In conclusione: cattiva pratica, codice terribile e un ottimo esempio di cosa non fare. Capisco che a volte gli OEM debbano sviluppare personalizzazioni speciali, ma dovrebbero pensarci due volte prima di scavare troppo in profondità. Non solo ciò si traduce in un codice non mantenibile per loro, ma crea anche ogni sorta di problemi imprevisti lungo la strada. Per fortuna, GPL esiste per renderli onesti e aperti.

Per aggirare il problema, e poiché ho installato bash tramite ipkg e non posso essere sicuro / opt sarà sempre disponibile (montato correttamente), ho semplicemente inserito quanto segue nel mio .profile

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

mentre / etc / passwd contiene / bin / ash come shell.

Vediamo. È isolato in una singola shell, inoltre stai guardando l'output di debug di sshd, quindi non si tratta di problemi di autorizzazione scrivibili dal mondo con ~ joeuser / .ssh. Questo è quello che attira la maggior parte delle persone.

Hai provato a creare un utente normale aggiuntivo (ovvero non joeuser) per assicurarti che si verifichi lo stesso problema? Ciò lo isolerebbe alla configurazione dell'utente rispetto alla configurazione dell'intero sistema.

Se si tratta di un problema a livello di sistema, la prossima cosa che darei un'occhiata sono i file di configurazione condivisi come / etc / profile che vengono acquistati da tutti. Potrebbe esserci un blocco condizionale che non si attiva se il nome utente è root. (userid non efficace, dal momento che l'hai già provato)

Controlla dmesg per i rapporti sugli errori di segmentazione se non l'hai già fatto, nel caso in cui ci sia qualcosa di ancora più strano.

provare / etc / ssh / sshd_config
cercare AllowUsers

se è lì prova ad aggiungere joeuser lì, solo nome utente

inoltre potrebbe essere bloccato in pam ... Non ricordo quale file sia ...

La loro versione modificata di openssh cerca una /bin/shshell?

Soluzione semplice quindi:

ln -fs / bin / bash / bin / sh

Prova a reinstallare Bash e vedi se questo aiuta.

Nel caso qualcuno si imbatta in questo perché hanno fatto lo stesso errore che ho fatto:

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

no: $ sudo usermod -s bash your_username

Il secondo comporterà l'autorizzazione negata quando si entra.