Ethical Hacking Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package. | Computer Forensics Training at InfoSec Institute Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors. |

| Subject: | Re: REQ: SSH behaviour dependent from the connecting client |
|---|---|
| Date: | Fri, 10 Sep 2004 09:16:40 -0500 |
Gianluca.Capitani@esa.int wrote on 09/09/2004 01:22:53 AM:
I'm currently trying to configure a couple of our ssh servers in a way
that they
will be able to provide only sftp service for all the users (with chroot) if the request is not coming from a well defined set
of
hosts (3 ? 4 machines). On the other hand, if the connection is coming
from this
limited set of hosts, the sftp-only or ssh-sftp will be permitted on a
user
basis. Something like: if [ SSH Client = trusted_host ] then Normal SSH behaviour else ONLY sftp with chroot for everybody fi Is this feasible? If yes, how this behaviour can be reached?
If you are using a host-based firewall then you ought to be able to redirect packets from your trusted source IPs to another port, running another SSHD. So you're basically then running two SSHDs each configured differently. How one of those configurations is different to allow only sftp with chroot is a hard one that I don't have a good answer to. Perhaps the second SSHD could run within another chroot environment with a different /etc/passwd listing everyone's shell as scponly? Perhaps you can modify the SSHD source where the user's shell is exec(2)ed and force it to only call scponly? Perhaps someone else on this list will come up with a better idea for us to digest? :) Personally, if I were to need this functionality I'd modify the SSHD source to make the shell switch at the exec(2) call, and then try to make the behavior possible through a new option to sshd_config so I could send diffs back to the OpenSSH team--making the change permanent in future versions of SSHD. Since I don't need this functionality, I'm not interested in doing it. Good luck! -- Michael Buselli
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | Re: running sftp without login via ssh ?, Derek Martin |
|---|---|
| Next by Date: | Re: Locking down ssh config in large env, Alvin Oga |
| Previous by Thread: | REQ: SSH behaviour dependent from the connecting client, Gianluca . Capitani |
| Next by Thread: | Re: REQ: SSH behaviour dependent from the connecting client, Albert Lunde |
| Indexes: | [Date] [Thread] [Top] [All Lists] |