No se puede iniciar sesión mediante SSH en ninguna cuenta utilizando /bin/bash Shell en Synology NAS

Question

No se puede iniciar sesión mediante SSH en ninguna cuenta utilizando /bin/bash Shell en Synology NAS

Preguntado el 16 de Diciembre, 2012: Cuando se hizo la pregunta
8798 visitas: Cuantas visitas ha tenido la pregunta
5 Respuestas: Cuantas respuestas ha tenido la pregunta
Resuelta: Estado actual de la pregunta

Estoy intentando instalar bash como Shell por defecto en un Linux ARM que se ejecuta en un dispositivo embebido (Synology DS212+ NAS). Pero hay algo realmente mal, y no puedo averiguar lo que es.

Síntomas:

1) Root tiene /bin/bash como Shell por defecto, y puede iniciar sesión normalmente a través de 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 tiene /bin/bash como Shell por defecto, y recibe "Permiso denegado" cuando intenta iniciar sesión a través de 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) cambiar el Shell de joeuser de nuevo a /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
$

Para hacer las cosas aún más extrañas, puedo iniciar sesión como joeuser utilizando /bin/bash utilizando la consola serie (!). También un su - joeuser como root funciona bien, por lo que el propio binario bash está funcionando bien.

En un acto de desesperación, cambié el uid de joeuser a 0 en /etc/passwd, pero tampoco funcionó, así que no parece ser algo relacionado con los permisos.

Parece que bash está haciendo alguna comprobación extra que a sshd no le gusta, y bloquea las conexiones para usuarios no root. Tal vez algún tipo de comprobación de cordura - o emulación de terminal - que está disparando el SIGCHLD, pero sólo cuando se llama a través de ssh.

Ya he revisado todos y cada uno de los elementos de sshd_config, y también he puesto SSHD en modo depuración, pero no he encontrado nada extraño. Aquí está mi /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

Y aquí está la salida de /usr/syno/sbin/sshd -d , mostrando el intento fallido de joeuser intentando iniciar sesión, con /bin/bash como 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

Aquí tiene el salida completa de sshd -dd, junto con ssh -vv .

Bash:

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

El binario bash se compiló de forma cruzada a partir del código fuente. También probé a utilizar un binario precompilado de la base de datos Distribución de Optware pero tenía exactamente el mismo problema. Comprobé si faltaban bibliotecas compartidas utilizando objdump -x pero están todos ahí.

¿Alguna idea de lo que podría estar causando esto " Permiso denegado, por favor inténtelo de nuevo. "? Estoy casi buceando en el código fuente de bash para investigar, pero tratando de evitar horas persiguiendo algo que puede ser una tontería.

EDITAR: añadir más información sobre bash y el 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

Preguntado el 16 de Diciembre, 2012 por Gui Ambros

2 votos

ls -l /bin/bash

Comentado el 16 de Diciembre, 2012 por Michael Hampton

0 votos

¿ Aparece /bin/bash en /etc/shells ?

Comentado el 17 de Diciembre, 2012 por tink

0 votos

Sí, aparece en /etc/shells. Y permisos 0755, añadido anteriormente.

Comentado el 17 de Diciembre, 2012 por Gui Ambros

Mostrar 3 comentarios más

Answer 1

5 Respuestas

Answer 2

50voto

Gui Ambros Puntos 518

Para futuras referencias: después de demasiadas horas investigando y depurando este problema, finalmente descubrí la causa root.

La versión de OpenSSH utilizada por Synology es una versión muy personalizada, que no no comportarse como el código original. Tiene un montón de hacks y personalizaciones ad-hoc - por ejemplo, la comprobación adicional antes de aceptar un inicio de sesión para ver si el servicio SSH está habilitado en la interfaz web, o la eliminación de caracteres especiales (;, |, ') de los comandos rsync, o... espera... evitar que los usuarios normales utilicen un Shell distinto de /bin/sh o /bin/ash. . Sí, codificado en el binario.

Este es el fragmento de código de OpenSSH 5.8p1, distribuido por Synology en su código fuente (DSM4.1 - rama 2636) Archivo 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 */
...
}

Como puede imaginar, el IsAllowShell(pw) era el culpable:

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

No es de extrañar que experimentara un comportamiento tan extraño. Sólo se aceptaban los shells /bin/sh y /bin/ash para usuarios distintos de root o admin . Y esto independientemente del uid (había probado también haciendo joeuser uid=0, y no funcionó. Ahora es obvio por qué).

Una vez identificada la causa, la solución era fácil: sólo había que eliminar la llamada a IsAllowShell() . Me llevó un tiempo conseguir la configuración correcta para compilar openssh y todas sus dependencias, pero al final funcionó bien.

Si alguien está interesado en hacer lo mismo (o intentar compilar de forma cruzada otros módulos del kernel o binarios para Synology), esta es mi versión de Makefile . Se probó con OpenSSH-5.8p1 fuente y funciona bien con modelos con CPU Marvell Kirkwood mv6281/mv6282 (como DS212+). He utilizado un host con Ubuntu 12.10 x64.

En resumidas cuentas: malas prácticas, código terrible y un gran ejemplo de lo que no hacer. Entiendo que a veces los OEM necesiten desarrollar personalizaciones especiales, pero deberían pensárselo dos veces antes de profundizar demasiado. Esto no sólo resulta en un código imposible de mantener para ellos, sino que también crea todo tipo de problemas imprevistos en el futuro. Afortunadamente, la GPL existe para mantenerlos honestos y abiertos.

Respondido el 21 de Enero, 2013 por Gui Ambros (518 Puntos )

6 votos

Un trabajo estelar señor, al investigar este tema y descorrer el telón del escenario Synology. Debo admitir que había pensado muy bien de mi Diskstation hasta ahora, ya que ha sido muy útil y una vez bootstrapped ahora incluso se ejecuta algunos scripts para mí bajo el nuevo programador de tareas. Pero usted ha revelado algunos defectos en el diseño miope aquí. Todavía estoy contento con el Diskstation, pero voy a mantener su puesto en mente. Upvoted tanto post y respuesta.

Comentado el 10 de Septiembre, 2013 por mbillard

0 votos

Upvoted por el esfuerzo. Si no quiero molestarme en hacer conexiones de cereal, sólo quiero cambiar el Shell por defecto a /bin/sh ¿hay alguna forma de hacerlo?

Comentado el 26 de Febrero, 2015 por Vicary

2 votos

Por qué Synology haría esto es totalmente más allá de mí :(

Comentado el 8 de Mayo, 2016 por Anuj Chitroda

Mostrar 1 comentarios más

Answer 3

8voto

Tom Regner Puntos 151

Para evitar el problema, y dado que instalé bash a través de ipkg y no puedo estar seguro de que /opt esté siempre disponible (montado correctamente), simplemente puse lo siguiente en mi .profile

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

mientras que /etc/passwd contiene /bin/ash como Shell.

Respondido el 11 de Marzo, 2013 por Tom Regner (151 Puntos )

Answer 4

1voto

Andrew B Puntos 9763

Veamos. Está aislado a un solo Shell, además estás viendo la salida de depuración de sshd, así que no son problemas de permisos de escritura en ~joeuser/.ssh. Ese es el que consigue la mayoría de la gente.

¿Has probado a crear un usuario normal adicional (es decir, no joeuser) para asegurarte de que experimenta el mismo problema? Eso lo aislaría a la configuración del usuario frente a la configuración de todo el sistema.

Si se trata de un problema que afecta a todo el sistema, lo siguiente que yo miraría son los archivos de configuración compartidos como /etc/profile de los que todos tienen acceso. Podría haber un bloque condicional que no se dispara si el nombre de usuario es root. (no userid efectiva, puesto que ya ha probado para eso)

Comprueba los informes de fallos de segmentación en dmesg si aún no lo has hecho, por si acaso hay algo aún más raro.

Respondido el 6 de Enero, 2013 por Andrew B (9763 Puntos )

0 votos

Gracias Andrew. También comprobado dmesg, y absolutamente nada. Crear un nuevo usuario tampoco ayudó, así que claramente es un problema de todo el sistema. Y joeuser puede iniciar sesión normalmente si cambio el Shell de nuevo a /bin/ash, que descarta cualquier /etc/profile u otro (que también he comprobado, por cierto). Es sólo con no root, usando bash, vía ssh. En este punto ni siquiera es un problema real (puedo vivir con ello como es ahora), pero me molesta admitir que no he sido capaz de encontrar la causa de este extraño comportamiento. Es un sistema determinista después de todo; hay debe ser algún tipo de explicación...

Comentado el 17 de Enero, 2013 por Gui Ambros

Answer 5

1voto

BiG_NoBoDy Puntos 36

Prueba /etc/ssh/sshd_config
buscar AllowUsers

si está ahí intenta añadir joeuser allí, sólo nombre de usuario

tambien puede estar bloqueado en pam... No recuerdo qué archivo es ...

Respondido el 9 de Enero, 2013 por BiG_NoBoDy (36 Puntos )

0 votos

No es el caso. Si fuera un problema con AllowUsers, no me dejaría entrar con joeuser cuando cambio el Shell a /bin/ash. Esto no parece estar relacionado con nada relacionado con la seguridad, o cualquier otra configuración. Es probablemente algún tipo de cómo bash maneja pseudo terminales a través de ssh, frente a ash, csh, etc.

Comentado el 17 de Enero, 2013 por Gui Ambros

Answer 6

0voto

PratapSingh Puntos 467

Intenta reinstalar Bash y mira si eso ayuda.

Respondido el 17 de Diciembre, 2012 por PratapSingh (467 Puntos )

0 votos

Nops, tengo bash de dos fuentes diferentes (uno de la distribución Optware, y también compilado 3.2 de la fuente a mí mismo), y el mismo problema. Llegué al extremo de incluso conseguir bash 4.2 y aplicar los parches (los 39), y compilar de forma cruzada. Exactamente el mismo comportamiento. Funciona con root, Permiso denegado para los demás. Mi última conjetura es el binario OpenSSH, que es el mismo instalado por defecto por el firmware de Synology. Esta es la única pieza que aún no he tocado. Intentaré descargar el último código fuente y hacer una compilación cruzada, a ver qué pasa.

Comentado el 18 de Diciembre, 2012 por Gui Ambros

2 votos

No estoy seguro, pero parece ser un problema de authconfig. ¿Se está ejecutando también ldap en el servidor? ¿Puede enviarme la salida de registro en tiempo real de archivo seguro y el mensaje en el momento del fallo de inicio de sesión.

Comentado el 18 de Diciembre, 2012 por PratapSingh

2 votos

También inicia sesión como root en el servidor y deja que el usuario Shell sea /bin/bash e intenta cambiar al usuario usando su - nombredeusuario. Muéstrame la salida de esto también.

Comentado el 18 de Diciembre, 2012 por PratapSingh

No se puede iniciar sesión mediante SSH en ninguna cuenta utilizando /bin/bash Shell en Synology NAS

Respuestas

Preguntas Destacadas

Etiquetas mas usadas

EnMiMaquinaFunciona.com

Powered by:

No se puede iniciar sesión mediante SSH en ninguna cuenta utilizando /bin/bash Shell en Synology NAS

Respuestas

Preguntas relacionadas

Preguntas Destacadas

Etiquetas mas usadas

En nuestra red

EnMiMaquinaFunciona.com

Powered by: