Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I am working on migrating an application from OpenVMS to RedHat Linux 6. The application is a green screen terminal application. The users will log into Linux via SSH and the application should automatically start but they should never have access to the shell. Once the application closes or crashes it should automatically log them out. What is the best way to approach this?

I've tried creating a new user with the following command.

useradd -s /sbin/nologin test

I then added ftp & to the users .bash_profile in the hope it would open the ftp console immediately and then once they quit it would log them out. However upon authentication on SSH the session is killed. Any ideas?

share|improve this question

Use a Match block for this group of users and ForceCommand to force the execution of the OpenVMS program using a wrapper script that uses its own exit to log out the user.

  Forces the execution of the command specified by ForceCommand, ignoring any command supplied by the client and ~/.ssh/rc if present.  The command is invoked by using the user's login shell with the -c
  option.  This applies to shell, command, or subsystem execution.  It is most useful inside a Match block.  The command originally supplied by the client is available in the SSH_ORIGINAL_COMMAND environment
  variable.  Specifying a command of “internal-sftp” will force the use of an in-process sftp server that requires no support files when used with ChrootDirectory.

Since that won't be a login shell, there's no need to logout, just exit:

Match Group oldies
    ForceCommand /usr/local/bin/wrapper

An example wrapper script might look like:

# cat /usr/local/bin/wrapper
#!/usr/bin/env bash

dialog --title "Message"  --yesno "Wrapper around your OpenVMS program" 6 25

exit 0

This is valid for ssh access.

You can also force the execution of the same wrapper script from /etc/passwd:

bob:x:1100:1100:Sponge Bob:/home/bob:/usr/local/bin/wrapper

and have the same functionality from a login console.

share|improve this answer
So do I need to add the user using useradd -s /sbin/nologin {username} still? Or will this handle that automatically? Thanks – greyfox Apr 21 '14 at 20:36
See my last edit. – dawud Apr 21 '14 at 20:44
Okay, one last question, will this still be able to read the users .bash_rc and .bash_profile? There will be several variables set the application will need. Thanks for the help! – greyfox Apr 21 '14 at 21:12
You could set those variables in the wrapper script itself. – dawud Apr 21 '14 at 21:28

Why don't you just set the application as the user's shell? That means it is the only thing that gets run when they log in, and (barring some sort of access within the application itself) they can't really do anything else.

share|improve this answer

The "green screen" application I've supported for the past 12 years accomplishes this via a modified .bash_profile and a wrapper script to start the application.

enter image description here

After the systems are built and service users created, we modify the default .bash_profile in the /etc/skel directory. This ensures that new users created on the system pick up the login settings.

Let's call the application "peach"

Inside the .bash_profile,

# Source any peach-specific variables
. /etc/default/peach

# Set up the search paths:

# Set up the shell environment:
        set +u
        trap "echo 'logout'" 0

# Run the peach application or start script:

The actual "run-peach" wrapper script will look like:


set -e

<blah blah> # do stuff, set MOAR variables
/opt/peach/bin/peach # run application binary

The set -e and trap are important here.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.