☰

SSH chrootディレクトリでsshコマンドを実行すると、uid 721001106を持つユーザーは存在しません。

tag-icon • tag-icon debian ssh chroot sshd sssd
SSH chrootディレクトリでsshコマンドを実行すると、uid 721001106を持つユーザーは存在しません。

SSSD認証でDebian 8を実行しています。認証が機能し、sshが正しく機能します。すべてのライブラリなどをSSH chrootdirectoryにコピーし、エラーのあるSSHを除くすべてのアプリケーションが機能します。

uidが721001106のユーザーはいません。

すべてのライブラリとファイルをインポートしたことを確認するためにltraceを実行しました。次に、可能なすべてのファイルシンボリックリンクを試しました。

追跡=オープンLtrace

open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
open("/lib/x86_64-linux-gnu/libselinux.so.1", O_RDONLY|O_CLOEXEC) = 3
open("/usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.0", O_RDONLY|O_CLOEXEC) = 3
open("/lib/x86_64-linux-gnu/libdl.so.2", O_RDONLY|O_CLOEXEC) = 3
open("/lib/x86_64-linux-gnu/libz.so.1", O_RDONLY|O_CLOEXEC) = 3
open("/lib/x86_64-linux-gnu/libresolv.so.2", O_RDONLY|O_CLOEXEC) = 3
open("/usr/lib/x86_64-linux-gnu/libgssapi_krb5.so.2", O_RDONLY|O_CLOEXEC) = 3
open("/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
open("/lib/x86_64-linux-gnu/libpcre.so.3", O_RDONLY|O_CLOEXEC) = 3
open("/usr/lib/x86_64-linux-gnu/libkrb5.so.3", O_RDONLY|O_CLOEXEC) = 3
open("/usr/lib/x86_64-linux-gnu/libk5crypto.so.3", O_RDONLY|O_CLOEXEC) = 3
open("/lib/x86_64-linux-gnu/libcom_err.so.2", O_RDONLY|O_CLOEXEC) = 3
open("/usr/lib/x86_64-linux-gnu/libkrb5support.so.0", O_RDONLY|O_CLOEXEC) = 3
open("/lib/x86_64-linux-gnu/libkeyutils.so.1", O_RDONLY|O_CLOEXEC) = 3
open("/lib/x86_64-linux-gnu/libpthread.so.0", O_RDONLY|O_CLOEXEC) = 3
open("/proc/filesystems", O_RDONLY)     = 3
open("/dev/null", O_RDWR)               = 3
open("/etc/nsswitch.conf", O_RDONLY|O_CLOEXEC) = 3
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
open("/lib/x86_64-linux-gnu/libnss_compat.so.2", O_RDONLY|O_CLOEXEC) = 3
open("/lib/x86_64-linux-gnu/libnsl.so.1", O_RDONLY|O_CLOEXEC) = 3
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
open("/lib/x86_64-linux-gnu/libnss_nis.so.2", O_RDONLY|O_CLOEXEC) = 3
open("/lib/x86_64-linux-gnu/libnss_files.so.2", O_RDONLY|O_CLOEXEC) = 3
open("/etc/passwd", O_RDONLY|O_CLOEXEC) = 3
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
open("/lib/x86_64-linux-gnu/libnss_sss.so.2", O_RDONLY|O_CLOEXEC) = 3
open("/var/lib/sss/mc/passwd", O_RDONLY|O_CLOEXEC) = 3
usage: ssh [-1246AaCfgKkMNnqsTtVvXxYy] [-b bind_address] [-c cipher_spec]
           [-D [bind_address:]port] [-E log_file] [-e escape_char]
           [-F configfile] [-I pkcs11] [-i identity_file]
           [-L [bind_address:]port:host:hostport] [-l login_name] [-m mac_spec]
           [-O ctl_cmd] [-o option] [-p port]
           [-Q cipher | cipher-auth | mac | kex | key]
           [-R [bind_address:]port:host:hostport] [-S ctl_path] [-W host:port]
           [-w local_tun[:remote_tun]] [user@]hostname [command]
+++ exited with 255 +++

ユーザーと一緒にidを実行すると、同じUIDなどが得られますが、名前情報は異なります。

Chrootなし：

uid=721001106([email protected]) gid=721000513(domain [email protected]) groups=721000513(domain [email protected]),721001108([email protected])

Chrootから：

uid=721001106 gid=721000513 groups=721000513,721001108

私の質問は、なぜこれが起こるのか、どこで読もうとし、失敗するのかです。

ああ、私もmount --bind /proc /path/to/jail/procを実行しましたが、まだ違いはありません...

次は何を試すかというアイデアはありますか？

とても感謝しています、

ルーク

答え1

私は同じ問題があり、getent passwdとgetentグループがLDAPからユーザーを返さないことがわかりました。この問題に対する解決策は、chrootディレクトリにgetentを出力することです。

getent passwd > /<chroot directory>/etc/passwd
getent group >  /<chroot directory>/etc/group

答え2

もっと詳しく見て、chroot領域にマウントをバインドすることに同意すると、ssh、scp、およびsftpを使用してsssdと通信できます。

このように：

cd /FileTransfer
mkdir -p var/lib/sss/pipes
cd var/lib/sss
mount --rbind /var/lib/sss/pipes pipes/ 
cp -p /etc/nsswitch.conf /FileTranser/etc

お役に立てば幸い

答え3

scpがユーザーUIDに対してgetpwuid（）を呼び出そうとし、sssdがchrootの外部で実行されているため失敗します。 scpだけがこのチェックを実行でき、sftpまたはsshは実行できません。

if ((pwd = getpwuid(userid = getuid())) == NULL)
   fatal("unknown user %u", (u_int) userid);

後で使わなかったなんておかしいですね。この確認なしで scp をビルドして動作することを確認できます。しかし、sssdでchrootを実行するのが良いでしょう:)

関連情報