I am running debian 8 with SSSD authentication. The authentication works and ssh works fine. I have copied all libraries etc over to my SSH chrootdirectory and all my applications work except ssh which has the error:

No user exists for uid 721001106

I have ran ltrace to ensure I got all the libraries and files. Next I tried symbolic links to the files where I could.

Ltrace where trace=open

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

When I run id with the user, I get the same UID's etc but the name information is different.

Without Chroot:

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

Within Chroot:

uid=721001106 gid=721000513 groups=721000513,721001108

My questions are, why is this happening and where is it trying to read from and failing.

Oh, also, I did a mount --bind /proc /path/to/jail/proc Still no difference...

Any ideas what to try next?

Many Thanks,


  • Outside of the chroot, how are the users and groups defined? Does it use LDAP, or is everything local?
    – KevinO
    Mar 12, 2019 at 5:28
  • Hi Kevin, so the users log into the server with SSH which is authenticated against a windows 2012R2 AD server. I've followed a tutorial which essentially uses sss instead of winbind. This all works ok and once logged in the ssh command works as expected. However when running the ssh command from a jailed user, the error occurs above. If I create a local user, and login to the jailed environment, the ssh command works perfectly. It's only with the AD logins. Mar 12, 2019 at 10:55

3 Answers 3


I was with the same problem and found that the getent passwd and getent group doesn't return the users from LDAP. The work around that a found was to output the getent in the chroot directory.

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

Did a bit more digging and if you are OK with a bind mount into the chroot area, you can get ssh, scp and sftp to talk to sssd.

Like this:

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

Hope that helps


Looks like it's scp that's trying to call getpwuid() for the users UID, and as sssd is running outside chroot it fails. It's only scp that makes this check nither sftp or ssh does it.

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

Strange thing is that they are not using it later. Thin I might build a scp without this check and see if it works. But would be nice to get chroot work with sssd :)


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .