Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

I am writing an application for smartphones to provide very limited SSH usage. The user cannot perform arbitrary actions when logged in. They can run a specific script(s) only.

For various reasons it is not possible to implement passwordless login so the password must be provided from the smartphone for login. However I have to questions about the security flaws/problems with what I'm doing.

  1. I don't want to give the users (in house employees) the SSH password directly, so they can't SSH from their homes and do what they like on the server. So my plan is for the user to enter their own password and use this as a key to store on the smartphone the (AES) encrypted SSH password. Only me or a server admin can enter this password on their phones, after downloading the application. This way they cannot login from unauthorized devices. Is this a good idea? I can't think of any security flwas in this.

  2. I am thinking about giving all smartphone users one user account on the server, so they all log in to the same user by SSH. Is this a bad idea too?

share|improve this question
    
Is the limited shell usage in the client or on the server? (Make sure the answer is the latter if this is a security means.) –  Legolas Mar 20 '12 at 6:49
add comment

3 Answers

up vote 7 down vote accepted

Giving all users a shared account is not something I would consider. You would not be able to know for certain which user did what on the system, multiple people will be sharing the same account concurrently... All in all, it's bound to get messy at some point.

Imagine if one of them loses their phone, and you are forced to lock everyone out when you find out, not to mention that whoever finds the phone can log in and do harm and you would have a hard time figuring what was done by that user.

I would prefer the first option. Configure each app manually before giving access to employees, save and encrypt the key pair, or the password on the device and let them choose a password for unlocking application access. This way if a phone gets lost or stolen, you can simply de-authorize the affected key / account.

share|improve this answer
add comment

Are you constrained to allowing the users direct access to SSH?
That does put you in a pretty difficult spot, both with authenticating the users as was mentioned, and with restricting the actual actions they can perform.

I would suggest a different solution - have a server component, that emulates SSH, and then proxies the actions back to the real SSH. You could even implement that as a web service, it would probably be simpler even for the client app.

This way, it is trivial to enforce the restrictions on the actions you want to allow (simply do not support the unallowed actions), block home SSH usage (since it's not really SSH), and authenticating individual users is a lot easier too.

share|improve this answer
add comment

Once you give the users the device, they should be able to get the ssh password/key from the mobile app off their device if want. You can make it more difficult (and its not trivial), but a sophisticated user could get at it. Thus you need to have server side restrictions.

For example, you can attempt to lock down ssh so for example the account has minimal permissions (e.g., no permissions ro run a shell, can only run one command, etc). Be careful about how you do this, try breaking it (depending on the allowed commands (or whether you allow arguments) they may be able to get to a shell). But its more secure than nothing.

However, maybe you should not be giving users ssh permissions via an app. How about write a simple server/web service that only has permissions to do the one thing you want done? Agree with others that sharing credentials on mobile devices is a bad idea.

share|improve this answer
    
Ha, I beat you again :) –  AviD Mar 19 '12 at 17:38
add comment

Your Answer

 
discard

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.