Synology NAS'ta / bin / bash kabuğunu kullanan hiçbir hesapta SSH ile giriş yapamıyorum

Bash'ı gömülü bir aygıtta (Synology DS212 + NAS) çalışan bir ARM Linux'a varsayılan kabuk olarak yüklemeye çalışıyorum. Ama gerçekten yanlış bir şey var ve ne olduğunu çözemiyorum.

Semptomlar:

1) Kök varsayılan kabuk olarak / bin / bash'a sahiptir ve SSH ile normal şekilde giriş yapabilir:

$ 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, varsayılan kabuk olarak / bin / bash değerine sahiptir ve SSH ile giriş yapmaya çalışırken "Reddedildi" ifadesini alır:

$ 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) joeuser'ın kabuğunu geri / bin / sh'a değiştir:

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

İşleri daha da garip hale getirmek /bin/bashiçin, seri konsolu (!) Kullanarak joeuser olarak giriş yapabilirim . Ayrıca bir su - joeuserkök olarak iyi çalışır, bu yüzden bash çiftinin kendisi de iyi çalışır.

Bir umutsuzluk eyleminde, joeuser'ın kullanıcı kimliğini / etc / passwd konumunda 0 olarak değiştirdim, ama aynı zamanda çalışmadı, bu yüzden izinle ilgili bir şey gibi görünmüyor.

Sshd'nin beğenmediği bazı ekstra kontroller yapıyor ve root dışı kullanıcılar için bağlantıları engelliyor gibi görünüyor. Belki bir tür akıl sağlığı denetimi - ya da terminal emülasyonu - bu SIGCHLD'i tetiklemektedir, ancak yalnızca ssh ile çağrıldığında.

Sshd_config'deki her bir öğeyi çoktan geçtim ve SSHD'yi hata ayıklama moduna geçirdim, ancak garip bir şey bulamadım. İşte benim /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

Ve işte, çıktısı /usr/syno/sbin/sshd -d, giriş yapan joeuser girişiminin, kabuk olarak / bin / bash olan girişimini gösteren:

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

Burada ssh-vv ile birlikte sshd -dd'nin tam çıktısına sahipsiniz .

Bash:

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

Beşli ikili, kaynaktan çapraz olarak derlendi. Ayrıca Optware dağıtımından önceden derlenmiş bir ikili dosya kullanmayı da denedim , ancak aynı sorunu yaşadım . Kayıp paylaşılan kütüphaneleri kullanarak kontrol ettim objdump -xama hepsi orada.

Buna neden olabilecek herhangi bir fikir " İzin reddedildi, lütfen tekrar deneyin. "? Neredeyse araştırmak için bash kaynak koduna dalıyorum, ancak aptal olabilecek bir şeyi kovalamak için saatlerce kaçmaya çalışıyorum.

EDIT: bash ve sistem hakkında daha fazla bilgi eklemek

$ 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

Gelecekte referans olması için: bu konuyu araştırarak ve hata ayıklamakla çok uzun saatler geçtikten sonra, nihayetinde kök nedenini keşfettim.

Synology tarafından kullanılan OpenSSH versiyonu mu yüksek seviyede özelleştirilmiş versiyonudur değil orijinal kodu gibi davranırlar. Çok sayıda saldırı ve geçici uyarlama var - örneğin, SSH hizmetinin web arayüzünde etkin olup olmadığını görmek için bir giriş yapmadan önce ek kontrol veya rsync komutlarından özel karakterleri (;, |, ') çıkarmak veya .. bekleyin ... normal kullanıcıların / bin / sh veya / bin / ash 'dan farklı bir kabuk kullanmasını engelleyin . Evet, kod içinde ikili kodlanmış.

İşte açık kaynak kodunda Synology tarafından dağıtılan OpenSSH 5.8p1 kodunun parçası (DSM4.1 - branş 2636) , dosya 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 */
...
}

Tahmin edebileceğiniz gibi, IsAllowShell(pw)suçlu oldu:

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

Neden böyle garip bir davranış sergilediğimi merak etmiyorum. Kök veya admin'den farklı kullanıcılar için sadece / bin / sh ve / bin / ash mermileri kabul edilir . Ve bu, ne olursa olsun, bir kullanıcı adı (aynı zamanda joeuser uid = 0 yaptığını da test etmiştim ve işe yaramadı. Şimdi, neden olduğu açıktır).

Nedeni bir kez belirledikten sonra düzeltme kolaydı: sadece çağrıyı IsAllowShell () ile kaldırın . Openssh ve tüm bağımlılıklarını çapraz derleme için doğru konfigürasyonu elde etmek biraz zaman aldı, ancak sonunda iyi çalıştı.

Herhangi biri aynı şeyi yapmakla ilgileniyorsa (veya diğer Synology için ikili modülleri veya ikili dosyaları derlemeye çalışırsanız), işte Makefile sürümüm . OpenSSH-5.8p1 kaynağı ile test edildi ve Marvell Kirkwood mv6281 / mv6282 CPU çalıştıran modellerle (DS212 + gibi) iyi çalışıyor. Ubuntu 12.10 x64 çalıştıran bir ana bilgisayar kullandım.

Alt satır: Kötü uygulama, korkunç kod ve ne yapılmaması gerektiğine dair mükemmel bir örnek . Bazen OEM'lerin özel özelleştirmeler geliştirmeleri gerektiğini anlıyorum, ancak çok derin kazmadan önce iki kez düşünmeleri gerekiyor. Bu sadece onlar için sürdürülemez bir kodla sonuçlanmamakta, aynı zamanda yol boyunca öngörülemeyen her türlü sorunu da yaratmaktadır. Neyse ki GPL onları dürüst ve açık tutmak için var.

Sorunu gidermek için ve baskg'ı ipkg aracılığıyla kurduğumdan ve her zaman kullanılacağından emin olamıyorum (doğru monte edilmiş), sadece .profile dosyasına şunu yazdım

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

/ etc / passwd kabuk olarak / bin / ash içerir.

Bakalım. Tek bir kabuğa izole edilmiştir, ayrıca sshd hata ayıklama çıktısına bakıyorsunuz, bu nedenle ~ joeuser / .ssh ile yazılabilir dünya izin sorunları değil. Çoğu insanı alan kişi bu.

Aynı sorunu yaşadığından emin olmak için ek bir normal kullanıcı (yani joeuser değil) oluşturmayı denediniz mi? Bu, sistem konfigürasyonuna karşı kullanıcının konfigürasyonuna göre izole eder.

Sistem genelinde bir sorun varsa, bir sonraki bakacağım şey herkes tarafından elde edilen / etc / profile gibi paylaşılan yapılandırma dosyaları. Kullanıcı adı root ise ateşlemeyen koşullu bir blok olabilir. (etkili kullanıcı kimliği yok, çünkü zaten bunun için test ettiniz)

Daha önce yapmadıysanız, hatta daha da tuhaf bir şeyler olduğunda bile segmentasyon hata raporları için dmesg'i kontrol edin.

AllowUsers için / etc / ssh / sshd_config araması deneyin

orada ise joeuser eklemeyi deneyin, sadece kullanıcı adı

Ayrıca Pam içinde engellenmiş olabilir ... Hangi dosya olduğunu hatırlamıyorum ...

Openssh'ın değiştirilmiş versiyonu bir /bin/shkabuk mu arıyor ?

O zaman kolay çözüm:

ln-fs / bin / bash / bin / sh

Bash'i yeniden yüklemeyi deneyin ve bunun yardımcı olup olmadığını görün.

Birisi bunun karşısında tökezlerse yaptığım aynı hatayı yaptıkları için:

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

yok hayır: $ sudo usermod -s bash your_username

İkincisi, içeri girerken reddedilen bir izinle sonuçlanacaktır.