Find the answer to your Linux question:
Results 1 to 6 of 6
Enjoy an ad free experience by logging in. Not a member yet? Register.
  1. #1

    ssh: starting different application instead of bash - secure?


    Hi,

    not sure if that's the right category here.
    I have the following setup:

    We are using a text based application (written in C), which requires users to login with username and password. The server gets connected remotely. To make it easy, but also secure I set up the following:
    users are connecting automatically via ssh via certificate without password.

    But instead of starting bash, I start the C application by configuring it in /etc/passwd for the respective account.

    So the user is starting a putty-session with autoconnect, an ssh connection is created and then the C application presents a login. If the application terminates, the ssh sessions gets closed automatically. (I'm not doing anything for that - not sure if that behaviour is reliable.)

    Is that a setup which is secure?
    Do I run any risk, that the user can start somehow a bash before or after the tailor made application?
    Remote comands in Putty seems to get ignored properly (like /bin/bash)

    Best
    Tjareson

  2. #2
    Linux Guru
    Join Date
    Dec 2013
    Location
    Victoria, B.C. Canada
    Posts
    2,103
    Ssh tries to execute any command passed to it by executing the shell in the password file so as long as your program handles all input correctly you'll be fine. Things to watch for are buffer overruns and parsing of executable commands. They shouldn't be able to do anything the program doesn't permit.

  3. #3
    Quote Originally Posted by gregm View Post
    Ssh tries to execute any command passed to it by executing the shell in the password file [...]
    Would that mean that the application mentioned in the password file is getting a remote command from e.g. putty as parameter when started via passwd?

    I've never checked that really, it would mean that someone knowing it is probably able to start the application in debug mode, which isn't a security issue but would cause unnecessary log file size.

    Not sure if passwd allows for parameters itself, when starting an application. Then I would adjust the programm to ignore all others command line option, in case a certain one is given already in passwd.

  4. $spacer_open
    $spacer_close
  5. #4
    Linux Guru
    Join Date
    Dec 2013
    Location
    Victoria, B.C. Canada
    Posts
    2,103
    If you pass options to ssh it will think they are meant for ssh so if the debug mode is invoked with -d or something option it should be ok. If it's an optarg something like DEBUG then it could be a problem.

    I don't think you can add parameters to the shell field in passwd but I haven't tried.

  6. #5
    Linux Engineer
    Join Date
    Jan 2005
    Location
    Saint Paul, MN
    Posts
    818
    Put your shell (your C program's executable) into /etc/shells on the remote machine. Change your user's shell to use that shell. Or you can have the user's add that program on their ssh command.

  7. #6

    Question

    -->
    Hi,
    I need to get back to this topic from 3 years ago: the mentioned c application is running safely when started out of passwd (after ssh login instead of bash) so far.

    For support reasons I was thinking now to start the application inside of screen in multiuser mode. So instead of putting the application in the passwd, I would like to start a bash script there which is starting screen in multiuser mode, which then starts the application:

    ssh:
    passwd: startscript
    ________I-- startscript: screen -c /home/xyz/application
    _____________I-- application

    That way I can attach with screen -RRx user/pid to the "application session" of a user for e.g. support reason or training.
    My issue coming along with that: I need to make absolutely sure that the user is not able to get outside of screen.
    One hole I saw would be to set via Ctrl-a : the screen commandline to /bin/bash and execute it by requesting a new window with Ctrl-a c. Then the user gets a bash - very bad.
    So I've disabled all screen keybindings except for detaching from the session.

    Are there any other ways to further secure screen to avoid starting anything else than given as parameter when starting it?

    My concern is, that I didn't find any general screen command which disables all, so I can only enable the ones I would like to allow.
    Instead I needed to disable whatever is there seperately. In case a new version with new keybindings gets released my configuration would probably have a security hole, as the new keybinding isn't disabled then.

    The c application itself is quite secure, supporting username password and one-time-password, but that all doesn't help much if the user would find a way out of the screen wrapper.

    regards
    Tjareson

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •