Hi ! I just notice this behaviour (I guess I was not paying enough attention). While working on setting up integration testing for a project of mine, that works through ssh, I had issues that I could not reproduce on my development machine. The problem stemmed in the fact that the CI system running the test suite is a user with its shell set to /usr/sbin/nologin (Buildbot, on a Debian system, but OpenBSD's _buildslave user has a similar with its shell set to /sbin/nologin). When a user is set-up this way, setting a forced command in its ~/.ssh/authorized_keys file is pointless. Indeed ssh launches the forced command through a shell. Which shell is launched is determined with getpwnam, which returns /usr/sbin/nologin. Thus the failure. I was wondering why SSH uses a shell to start a forced command (one hypothesis I have is to set up a proper environment for the subsequent session (setting PATH, HOME, ...), which I think SSH does not do. Does this not counter-act the purpose of forced command ? On the other side what are the real benefits, security-wise, of setting the users shell to /sbin/nologin (or similar command from), apart from: preventing local log in or preventing the use system(2) (why does this still exists !?), but which may not be a small threat given how many scripting languages still binds it. Any comments ? Any ways to circumvent this ? Or shouldn't ssh not use a shell to launch forced commands ? I looked in the archive, and its seems to me this issue has not been raised before. My apologies if it has. Regards, Nicolas.