☰

SSH chroot 디렉터리에서 ssh 명령을 실행할 때 uid 721001106을 가진 사용자가 존재하지 않습니다.

tag-icon • tag-icon debian ssh chroot sshd sssd
SSH chroot 디렉터리에서 ssh 명령을 실행할 때 uid 721001106을 가진 사용자가 존재하지 않습니다.

SSSD 인증으로 데비안 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 작업을 수행하는 것이 좋을 것입니다 :)

관련 정보