Không thể đăng nhập qua SSH vào bất kỳ tài khoản nào bằng / bin / bash shell trên Synology NAS

Tôi đang cố gắng cài đặt bash làm vỏ mặc định trên ARM Linux chạy trên thiết bị nhúng (Synology DS212 + NAS). Nhưng có điều gì đó thực sự sai, và tôi không thể hiểu nó là gì.

Triệu chứng:

1) Root có / bin / bash làm shell mặc định và có thể đăng nhập bình thường qua 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 có / bin / bash làm vỏ mặc định và nhận được "Quyền bị từ chối" khi cố gắng đăng nhập qua 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) thay đổi vỏ của kẻ thù trở lại / 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
$ 

Để làm cho mọi thứ trở nên kỳ lạ hơn, tôi có thể đăng nhập như joeuser bằng /bin/bashcách sử dụng bảng điều khiển nối tiếp (!). Cũng su - joeusernhư một root hoạt động tốt, vì vậy bản thân nhị phân bash đang hoạt động tốt.

Trong một hành động tuyệt vọng, tôi đã thay đổi uid của joeus thành 0 trên / etc / passwd, nhưng cũng không hoạt động, vì vậy nó dường như không phải là một sự cho phép liên quan.

Có vẻ như bash đang thực hiện một số kiểm tra bổ sung mà sshd không thích và chặn các kết nối cho người dùng không root. Có thể một số loại kiểm tra độ tỉnh táo - hoặc mô phỏng thiết bị đầu cuối - đang kích hoạt SIGCHLD, nhưng chỉ khi được gọi qua ssh.

Tôi đã xem qua từng mục trên sshd_config và cũng đặt SSHD ở chế độ gỡ lỗi, nhưng không tìm thấy gì lạ. Đây là của tôi /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

Và đây là đầu ra từ /usr/syno/sbin/sshd -d, cho thấy nỗ lực thất bại của joeuser khi cố gắng đăng nhập, với / bin / bash là 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

Ở đây bạn có đầu ra đầy đủ của sshd -dd, cùng với ssh -vv .

Bash:

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

Các nhị phân bash được biên dịch chéo từ nguồn. Tôi cũng đã thử sử dụng nhị phân được biên dịch sẵn từ bản phân phối Optware , nhưng có cùng một vấn đề. Tôi đã kiểm tra các thư viện chia sẻ bị thiếu bằng cách sử dụng objdump -x, nhưng tất cả đều ở đó.

Bất kỳ ý tưởng nào có thể gây ra " Quyền bị từ chối, vui lòng thử lại. "? Tôi gần như đang lặn trong mã nguồn bash để điều tra, nhưng cố gắng tránh hàng giờ để theo đuổi thứ gì đó có thể là ngớ ngẩn.

EDIT: thêm thông tin về bash và hệ thống

$ 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

Để tham khảo trong tương lai: sau quá nhiều giờ nghiên cứu và gỡ lỗi vấn đề này, cuối cùng tôi đã phát hiện ra nguyên nhân gốc rễ.

Phiên bản OpenSSH được Synology sử dụng là phiên bản tùy biến cao, không hoạt động như mã gốc. Nó có rất nhiều hack và các tùy chỉnh đặc biệt - ví dụ: kiểm tra bổ sung trước khi chấp nhận đăng nhập để xem liệu dịch vụ SSH có được bật trong giao diện web hay tước các ký tự đặc biệt (;, |, ') từ các lệnh rsync, hoặc .. . Đợi nó ... tránh người dùng thông thường sử dụng shell khác với / bin / sh hoặc / bin / ash . Vâng, cứng mã hóa trong nhị phân.

Đây là đoạn mã từ OpenSSH 5.8p1, được phân phối bởi Synology trên mã nguồn của họ (DSM4.1 - nhánh 2636) , tệp 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 */
...
}

Như bạn có thể tưởng tượng, đó IsAllowShell(pw)là thủ phạm:

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

Không có thắc mắc tại sao tôi đã trải qua một hành vi kỳ lạ như vậy. Chỉ shell / bin / sh và / bin / ash mới được chấp nhận cho người dùng khác với root hoặc admin . Và điều này bất kể uid (tôi đã thử nghiệm cũng tạo joeuser uid = 0, và nó không hoạt động. Bây giờ thì rõ ràng tại sao).

Sau khi xác định được nguyên nhân, việc khắc phục rất dễ dàng: chỉ cần xóa cuộc gọi đến IsAllowShell () . Phải mất một thời gian để tôi có được cấu hình phù hợp để biên dịch chéo và tất cả các phụ thuộc của nó, nhưng cuối cùng nó vẫn hoạt động tốt.

Nếu bất cứ ai quan tâm đến việc làm tương tự (hoặc cố gắng biên dịch chéo các mô-đun hạt nhân hoặc nhị phân khác cho Synology), thì đây là phiên bản Makefile của tôi . Nó đã được thử nghiệm với nguồn OpenSSH-5,8p1 và hoạt động tốt với các mô hình chạy CPU Marvell Kirkwood mv6281 / mv6282 (như DS212 +). Tôi đã sử dụng máy chủ chạy Ubuntu 12.10 x64.

Điểm mấu chốt: thực hành tồi, mã khủng khiếp, và một ví dụ tuyệt vời về những điều không nên làm. Tôi hiểu đôi khi các OEM cần phát triển các tùy chỉnh đặc biệt, nhưng họ nên suy nghĩ kỹ trước khi đào quá sâu. Điều này không chỉ dẫn đến mã không thể nhầm lẫn cho họ, mà còn tạo ra tất cả các loại vấn đề không lường trước được. Rất may GPL tồn tại để giữ cho họ trung thực - và cởi mở.

Để khắc phục sự cố và vì tôi đã cài đặt bash qua ipkg và tôi không thể chắc chắn / opt sẽ luôn khả dụng (được gắn chính xác), tôi chỉ cần đặt phần sau vào .profile của mình

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

while / etc / passwd chứa / bin / tro làm vỏ.

Hãy xem nào. Nó bị cô lập với một vỏ duy nhất, cộng với việc bạn đang xem đầu ra gỡ lỗi sshd, do đó, đây không phải là vấn đề cấp phép có thể ghi trên thế giới với ~ joeuser / .ssh. Đó là người được hầu hết mọi người.

Bạn đã thử tạo thêm một người dùng bình thường (không phải là joeuser) để đảm bảo rằng nó gặp phải vấn đề tương tự chưa? Điều đó sẽ cách ly nó với cấu hình của người dùng so với cấu hình toàn hệ thống.

Nếu đó là sự cố toàn hệ thống, điều tiếp theo tôi sẽ xem xét là các tệp cấu hình được chia sẻ như / etc / profile được mọi người sử dụng. Có thể có một khối điều kiện không kích hoạt nếu tên người dùng là root. (không hiệu quả với userid, vì bạn đã thử nghiệm điều đó)

Kiểm tra dmesg để biết các báo cáo lỗi phân đoạn nếu bạn chưa có, chỉ trong trường hợp có điều gì đó thậm chí còn kỳ lạ hơn đang diễn ra.

thử / etc / ssh / sshd_config
tìm kiếm cho phép Người dùng

Nếu nó ở đó hãy thử thêm joeuser ở đó, chỉ cần tên người dùng

ngoài ra nó có thể bị chặn trong pam ... Tôi không nhớ đó là tập tin nào ...

Phiên bản sửa đổi của openssh tìm /bin/shvỏ?

Giải pháp dễ dàng sau đó:

ln -fs / bin / bash / bin / sh

Hãy thử cài đặt lại Bash và xem nếu nó giúp.

Trong trường hợp bất cứ ai vấp phải điều này bởi vì họ đã phạm cùng một lỗi tôi đã làm:

Vâng: $ sudo usermod -s /bin/bash your_username

Không: $ sudo usermod -s bash your_username

Lần thứ 2 sẽ dẫn đến sự cho phép bị từ chối khi ssh'ing.