# [Solved] Locking down SSH (no sftp, remote commands, etc)

## randalla

Hopefully someone can help me with this. We have an internal server that runs custom software we have written. The setup we have is that users telnet in (which is being phased out) and they are immediately brought into the shell application menu. At this point, they don't have the ability to break out of the menu without terminating their connection. All the kill variations are restricted (control-c, etc) so they can't try to break out. This is all controlled by the .bash_profile, which ends with exit.

Now, while with telnet this all works, we need to expose this system to external clients, and we can't have them using Telnet. Instead, we want to use ssh to have it secure, but it raises a huge amount of security concerns such as:

- users being able to copy files to the system via ssh/scp/sftp

- users being able to initiate remote commands on the system, where they could read configurations, or other files they have not business being in.

- trying to open tunnels to other machines inside of our network

The software we want them to use is built on some old, and archaic, designs and are not overly changeable. There's no set list of commands that a user can use since new micro programs are made on a constant basis by the software engineer. To that end, we need to lock down the connection method as much as possible to now allow anything more than accessing the menu program from executing, and from there we're pretty locked down.

So, I need to set up ssh for users in a special group that can only log in and can't execute remote commands nor upload/download any files from the system from any method described above (scp/sftp/rsync/etc). We also need to make sure that admin users are not affected by this as we do need to issue remote commands, copy/download files to the systems, etc. The end users will should have no ability to modify even their own folders.

If ssh is not my solution, what should I look into as an alternate?

Adam.Last edited by randalla on Sat Feb 28, 2009 1:57 am; edited 1 time in total

----------

## defenderBG

ssh allows someone to login to your computer and work as if he/she is physicly on it. To be sure that the user can't copy a specific file, he should not be able to read it (different group). if the user can't read the file, he will be unable to copy it via sftp.

What you should do is make a new group and allow as less as possible. this answer is as broad as your question. if you can give a more specific question, I will be glad to answer it.

ps: my personal opinion is that this setup is not a very good one. it might be better if you try to use some policy based approach to solve the problem. A quite minimalistic one is keynote: http://www1.cs.columbia.edu/~angelos/keynote.html which is in portage as well.

----------

## randalla

 *defenderBG wrote:*   

> ssh allows someone to login to your computer and work as if he/she is physicly on it. To be sure that the user can't copy a specific file, he should not be able to read it (different group). if the user can't read the file, he will be unable to copy it via sftp.
> 
> What you should do is make a new group and allow as less as possible. this answer is as broad as your question. if you can give a more specific question, I will be glad to answer it.
> 
> ps: my personal opinion is that this setup is not a very good one. it might be better if you try to use some policy based approach to solve the problem. A quite minimalistic one is keynote: http://www1.cs.columbia.edu/~angelos/keynote.html which is in portage as well.

 

What I want is pretty simple. I want people to be able to log into our system, only be able to execute one program, and have that program be able to rely on it's sub programs. I don't want them to be able to look at the system in any way other than that, including uploading/downloading files. This connection needs to be secure. Telnet works for this, yet it is not secure. SSH opens too much to the end user than we want.

Yes, I can lock down permissions all over the place, but there's a lot that still needs to be readable, such as many things in the /etc folder. As it is, our program is archaic and does not like permissions linux permissions in it's own right making things quite difficult in other areas. Still, if we can isolate the user, then that would solve the problem until the whole system gets rewritten.

----------

## scherz0

A combination of Match and ForceCommand may be what you are looking for.   At user login, the command will be executed, and when it ends the connection will be closed.

man sshd_config for more info, including other restriction such as PermitTunnel.

----------

## randalla

 *scherz0 wrote:*   

> A combination of Match and ForceCommand may be what you are looking for.   At user login, the command will be executed, and when it ends the connection will be closed.
> 
> man sshd_config for more info, including other restriction such as PermitTunnel.

 

I've looked at the man for sshd_config and ssh_config, and I did see Match in there, as well as ForceCommand. Are there any examples out there of someone using Match? I'll continue looking if either way.

----------

## i0

 *randalla wrote:*   

> 
> 
> I've looked at the man for sshd_config and ssh_config, and I did see Match in there, as well as ForceCommand. Are there any examples out there of someone using Match? I'll continue looking if either way.

 

example to /etc/ssh/sshd_config

```
# override default of no subsystems

Subsystem   sftp   /usr/lib/misc/sftp-server

Match Group users

        ChrootDirectory /home/%u

        X11Forwarding no

        AllowTcpForwarding no

        ForceCommand internal-sftp

```

Also you can use: Match User username

Beware of locking Yourself out to chroot jail.

Create user with some other group than users.

For example:

```

groupadd username

adduser -g username -G wheel -m username

```

This user in not in users group so he/she is not in chroot jail and since he/she is in wheel group he/she can su to root.

And another thing:

Jail (/home/%u) must be must be owned by root and not group or world-writable (according to man sshd_config).

That is a minus because user cannot write to its home directory.

Maybe it is better if: ChrootDirectory /home

And also user home should be definied in /etc/passwd as relative to ChrootDirectory.

Eg: if ChrootDirectory /home then users home should be /username

----------

## randalla

 *i0 wrote:*   

>  *randalla wrote:*   
> 
> I've looked at the man for sshd_config and ssh_config, and I did see Match in there, as well as ForceCommand. Are there any examples out there of someone using Match? I'll continue looking if either way. 
> 
> example to /etc/ssh/sshd_config
> ...

 

I truly appreciate all this. I was able to get what I wanted following most of the instructions you posted here. What I didn't do was the chroot jail because the amount of files that would need to be recreated in the jail would make it not worthwhile. I'm now binding a specific group to only use one program, which when terminated exits the session, logging the user off. This prevents remote command execution and sftp. With the tunneling turned off, it's pretty much perfect (we don't run X11 on this machine, so that shouldn't be an issue, even though we have it turned off too).

I feel much better about opening this resource to our clients.

Regards,

Adam.

----------

## cazort

A different solution from this one that I've seen implemented, is to specify the program you want to run as the user's shell, in the place of bash or any other shell.  Then, this program will execute immediately when they connect, and the connection will end when the program ends.

I'm skeptical of solutions like this though...probably because I've actually had a pretty easy time breaking out of them.  In a sufficiently complex program, a sufficiently curious and diligent user will often be able to find a way to execute commands or do other things they're not supposed to do.  If your users aren't deliberately trying to hack it though, it might be fine as a temporary setup.

----------

## randalla

 *cazort wrote:*   

> A different solution from this one that I've seen implemented, is to specify the program you want to run as the user's shell, in the place of bash or any other shell.  Then, this program will execute immediately when they connect, and the connection will end when the program ends.
> 
> I'm skeptical of solutions like this though...probably because I've actually had a pretty easy time breaking out of them.  In a sufficiently complex program, a sufficiently curious and diligent user will often be able to find a way to execute commands or do other things they're not supposed to do.  If your users aren't deliberately trying to hack it though, it might be fine as a temporary setup.

 

The users are effectively doing what you describe here. They log in and they are forced into the program I've specified. When the program terminates, they are then logged out of the system at that point. What they can do in the program is pretty limited, and is locked down pretty tight by it's programmer. I've tried to break out of the solution before executing the program and all that I get is the default output of the program for my attempts:

x11 forwarding -> permission denied

tunnelling -> it doesn't happen

remote commands (ssh user@server uptime) -> master program runs, command is ignored

logging in -> master program runs, breaking out disconnects the session

sftp/scp -> permission denied

I can't find ways out. If you want to attempt it, though, feel free to contact me privately and I'd be willing to work it out for you to show me how you can get out of it.

----------

## Hu

One other aspect may need consideration, depending on the determination and proficiency of your users.  Your custom program is not designed to allow them to drop out to a shell, but there is the possibility that it may mishandle some inputs in such a way that they can run code of their choosing, allowing them to drop out of the forced command.  For example, if the forced command failed to validate the length of a supplied string before copying it, the user could initiate a stack overrun to branch to an address of their choosing.  In the worst case, this could be exploited to exec a shell.

If you are concerned about this, look into SELinux or GRsecurity to confine the incoming process.  You may also get some protection by ensuring the forced command is built with stack smashing protection (SSP) and is a position independent executable (PIE).  Each of these measures make it more likely that an attempted stack overrun will simply crash the program, rather than giving the attacker control over its execution.

----------

