Hi,

I've a user in a chroot jail who can only do ssh and scp.
For ssh and scp, i dedicated a network port : 1234.

There is a dedicated sshd daemon on each server that listen on port 1234 and allow only this user.

But how can i prevent this user to try to connect on an other port than 1234, for exemple, with /usr/bin/ssh -P 22 localhost ?

This is the last "security hole known" for this user.

I would think that adding this user to the DenyUsers line in the sshd_config file should do the trick.

Thanks for the answer.
To be fully paranoïd, i would prevent this user trying to connect with an other identity.

I guess I'm not sure what you're worried about here. There should be no way this user can create a new account (unless they've already gained root access) and there really isn't any way you can stop this user if they manage to steal another users account name and password. You could move ssh to a key-based authentication system, which would make stealing another account significantly harder, but that is about the extent of what you can do.

Maybe if you fully explain your situation and what you're worried about, we can give some better advice.

We have several network.
Between this networks, only applications streams are open on the firewalls. For admin tasks, we use dedicated physical terminals.

My goal is to create a "dedicated network" inside my network for file transfert. Port 1234 will be open between some networks, where 22 musn't.

For exemple, imagine that somebody success in stealing an account/password on the high sensitive network. Imagine that this personn success in connecting on the public server with the chrooted account. So, he'll can use the "1234 network" to go to the sensitive machine, then log on it with a more powerfull account doing ssh powerfullaccount@localhost.

I'm not used to explain so much in english, so i hope i'm clear ;-)

I think i just found the solution (i have to test it before) : chmod and chown on /usr/bin/ssh, and allow user to sudo -u userssh /usr/bin/ssh_for_user.sh

ssh_for_user.sh is a script which parse command line form unauthorized options (such -P XXXX).
If it's good, userssh will try to connect : /usr/bin/ssh -P 1234 user@machine

Is this solution seems good?

Believe me, your English is MUCH better than my French, and you are clear.

The solution you outline makes some sense and it certainly would throw up a roadblock or two.

I think a potentially better way to approach this would be to replace usernames and password authentication on the highly sensitive computers with key-based authentication. If you also remove a users ability to create a key pair, that would mean that a user would have to talk to an administrator to get the key pair. It would be more administrative hassle for you, but it would allow you to more completely control who has access to what machine.

Of course I'm assuming that it would be more difficult for a person to steal a key than it would be to steal a username and password. If you make the keys with a passphrase, then they would have to steal both the key file and the passphrase (which isn't transmitted across the network so they can't sniff it).

Thanks for the advices.