Synology NASで/ bin / bashシェルを使用しているアカウントにSSH経由でログインできない


30

組み込みデバイス(Synology DS212 + NAS)で実行されているARM Linuxにデフォルトのシェルとしてbashをインストールしようとしています。しかし、本当に間違っていることがあり、それが何なのかわかりません。

症状:

1)ルートにはデフォルトのシェルとして/ bin / bashがあり、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にはデフォルトのシェルとして/ bin / bashがあり、SSH経由でログインしようとすると「Permission denied」を受け取ります。

$ 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のシェルを/ 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
$ 


さらに奇妙なことに/bin/bash、シリアルコンソール(!)を使用してjoeuserとしてログインできます。また、su - joeuserルートとしてのa は正常に動作するため、bashバイナリ自体も正常に動作しています。

絶望の中で、/ etc / passwdでjoeuserのuidを0に変更しましたが、機能しなかったため、許可に関連するものではないようです。

bashはsshdが気に入らない追加のチェックを行っており、非rootユーザーの接続をブロックしているようです。たぶん、ある種の健全性チェック(または端末エミュレーション)がSIGCHLDをトリガーしますが、これはssh経由で呼び出された場合のみです。

すでにsshd_configのすべての項目を調べ、SSHDをデバッグモードにしましたが、奇妙なことは何も見つかりませんでした。ここに私の/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


そして、ここからの出力は/usr/syno/sbin/sshd -d、/ bin / bashをシェルとして使用して、joeuserがログインしようとして失敗したことを示しています。

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


ここでは、持っているのsshdのフル出力は一緒にssh -vvと、-DD

バッシュ:

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

bashバイナリは、ソースからクロスコンパイルされました。また、Optwareディストリビューションからコンパイル済みのバイナリを使用してみましたが、まったく同じ問題がありました。共有ライブラリが見つからないかどうかをチェックしましたobjdump -xが、すべて揃っています。

この「許可が拒否されました。もう一度試してください。」の原因となる可能性のあるアイデアはありますか?私はほとんど調査するためにbashのソースコードに飛び込みますが、馬鹿げているかもしれない何かを追いかける時間を避けようとしています。

編集: bashとシステムに関する情報を追加する

$ 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

2
ls -l /bin/bash
マイケルハンプトン

/ bin / bashは/ etc / shellsにリストされていますか?
ティンク

はい、/ etc / shellsにリストされています。上記のアクセス許可0755。
グイアンブロス

ほとんどの場合、彼の.bashrcファイルで何かが実行されています。〜joeuser / .bashrcを猫にして、彼のプロファイルスクリプトを確認できますか また、彼としてログインした状態で/ bin / bashを実行してみることもできます。
vicfn

〜joeuser / .sshおよびプロファイルスクリプトはありません。テストのために作成したばかりの空のユーザーです。
グイアンブロス

回答:


39

将来の参考のために:この問題の調査とデバッグにあまりにも多くの時間を費やした後、最終的に根本原因を発見しました。

Synologyが使用するOpenSSHバージョンは高度にカスタマイズされたバージョンであり、元のコードのようには動作しませ。多くのハックとアドホックなカスタマイズがあります-たとえば、ログインを受け入れる前に追加のチェックを行って、SSHサービスがWebインターフェイス内で有効になっているかどうかを確認したり、rsyncコマンドから特殊文字(;、|、 ')を削除したりします。 。それを待ちます... 通常のユーザーが/ bin / shや/ bin / ashとは異なるシェルを使用するのを避けます。ええ、バイナリ内でハードコードされています。

Synologyがソースコード(DSM4.1-ブランチ2636)で配布しているOpenSSH 5.8p1のコードを以下に示します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 */
...
}


ご想像のとおりIsAllowShell(pw)、犯人は次のとおりです。

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


なぜ私がそのような奇妙な行動を経験していたのも不思議ではありません。rootまたはadminとは異なるユーザーには、シェル/ bin / shおよび/ bin / ashのみが受け入れられます。そして、これはuidに関係なく(joeuser uid = 0を作成することもテストしましたが、機能しませんでした。今ではその理由は明らかです)。

原因を特定すると、修正は簡単でした。IsAllowShell()への呼び出しを削除するだけです。opensshとそのすべての依存関係をクロスコンパイルするための適切な構成を取得するにはしばらく時間がかかりましたが、最終的にはうまく機能しました。

誰かが同じことを行うことに興味がある場合(またはSynologyの他のカーネルモジュールまたはバイナリをクロスコンパイルしようとしている場合)、ここにMakefileのバージョンがありますOpenSSH-5.8p1 sourceでテストされ、Marvell Kirkwood mv6281 / mv6282 CPU(DS212 +など)を実行しているモデルで適切に動作します。Ubuntu 12.10 x64を実行しているホストを使用しました。

結論:悪い習慣、ひどいコード、やるべきでないことの素晴らしい例。OEMが特別なカスタマイズを開発する必要があることを理解していますが、深く掘り下げる前に、よく考えてください。これにより、管理不能なコードが生成されるだけでなく、将来的にあらゆる種類の予期しない問題が発生します。ありがたいことに、GPLは正直に、そしてオープンに保つために存在しています。


4
この問題を調査し、Synologyステージからカーテンを引き戻す作業において、Stellar氏。Diskstationは非常に便利で、ブートストラップされた後、新しいタスクスケジューラでスクリプトを実行することもできるので、これまで非常に高く評価していたことを認めなければなりません。しかし、あなたは近視眼的な設計のいくつかの欠陥をここで明らかにしました。Diskstationにはまだ満足していますが、あなたの投稿を心に留めておきます。投稿と回答の両方を支持しました。
バーナードDy

努力に賛成。シリアル接続を行う必要がない場合、デフォルトのシェルをに変更したいだけです/bin/sh。それを行う方法はありますか?
Vicary

Synologyがこれを行う理由は完全に私を超えています。(
Gerhard Burger

に名前を変更/bin/ash/bin/ash.realてリンクzshしました/bin/ash...これまでのところ、すべてがうまくいくようです... o_o
x1a0

7

問題を回避し、ipkg経由で​​bashをインストールし、/ optが常に使用可能である(正しくマウントされる)ことを確認できないため、.profileに次のものを追加します。

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

/ etc / passwdにはシェルとして/ bin / ashが含まれています。


1

どれどれ。これは単一のシェルに分離されており、sshdデバッグ出力を見ているため、〜joeuser / .sshでの書き込み可能な権限の問題ではありません。それはほとんどの人を獲得するものです。

同じ問題が発生することを確認するために、追加の通常ユーザー(つまり、joeuserではない)を作成しようとしましたか?これにより、ユーザーの構成とシステム全体の構成に分離されます。

システム全体の問題である場合、次に注目するのは、/ etc / profileのような共有設定ファイルで、誰もがソースを取得します。ユーザー名がルートの場合、起動しない条件ブロックが存在する場合があります。(有効なユーザーIDではありません。既にテスト済みのため)

さらに奇妙なことが起こっている場合に備えて、dmesgでセグメンテーションエラーレポートを確認してください。


アンドリュー、ありがとう。dmesgもチェックしましたが、絶対に何もチェックしませんでした。まったく新しいユーザーの作成も役に立たなかったため、明らかにシステム全体の問題です。また、シェルを/ bin / ashに戻すと、joeuserは通常どおりログインできます。これにより、/ etc / profileまたはその他(これもチェックしました)が除外されます。sshを介してbashを使用する非ルートでのみです。この時点でそれは本当の問題でさえありません(私は今のままで生きることができます)が、この奇妙な振る舞いの原因を見つけることができなかったことを認めるのはいらいらします。結局、それは決定論的なシステムです。そこになければなりません ...説明のいくつかの並べ替えも
桂アンブロス

1


AllowUsersの/ etc / ssh / sshd_config 検索を試してください

そこにjoeuserを追加してみてください、ちょうどユーザー名

また、PAMでブロックされる可能性があります...どのファイルであるか思い出せません...


そうではありません。AllowUsersの問題である場合、シェルを/ bin / ashに変更してもjoeuserでログインできません。これは、セキュリティに関連するものやその他の構成に関連するものではないようです。これはおそらく、などbashのハンドルが灰対、ssh経由で端末を擬似する方法のいくつかの並べ替え、CSH、だ
桂アンブロス

1

彼らのopensshの修正版は/bin/shシェルを探しますか?

簡単な解決策:

ln -fs / bin / bash / bin / sh


これにより、bashが必要なユーザーだけでなく、すべてのユーザーのシェルが変更されます。また、新しいアップグレードではシンボリックリンクが削除されます(opensshの修正にも同じ問題があります)。とにかく、これは上記のように解決されました。
グイアンブロス

はい、本当ですが、NASで私が唯一のユーザーであるため、このソリューションは私にとっては有効です。とにかく発見したことを指摘してくれてありがとう。
ポニーテック

0

Bashを再インストールして、それが役立つかどうかを確認してください。


いいえ、私は2つの異なるソース(Optwareディストリビューションから1つ、およびソースから自分で3.2をコンパイルしました)からbashを受け取りました。同じ問題です。私はbash 4.2を入手してパッチ(39個すべて)を適用し、クロスコンパイルすらするという極端なことをしました。まったく同じ動作。ルートで動作、他のユーザーに対して許可が拒否されました。私の最後の推測はOpenSSHバイナリで、これはSynologyのファームウェアによってデフォルトでインストールされるものと同じです。これは私がまだ触れていない唯一の作品です。最新のソースをダウンロードしてクロスコンパイルし、何が起こるかを確認します。
グイアンブロス

2
不思議なことですが、これはauthconfigの問題のようです。ldapもサーバーで実行されていますか?ログイン失敗時のセキュアなメッセージファイルのリアルタイムログ出力を送信してください。
Pratap

2
また、サーバーにrootとしてログインし、ユーザーシェルを/ bin / bashにして、su-usernameを使用してユーザーに切り替えます。これの出力も見せてください。
プラタップ

0

私がやったのと同じ間違いをしたために誰かがこれに遭遇した場合:

はい: $ sudo usermod -s /bin/bash your_username

いいえ: $ sudo usermod -s bash your_username

2回目では、ssh'ing時に許可が拒否されます。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.