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.




Network Security Secure-Shell
[Top] [All Lists]

Re: SSH and SFTP

Subject: Re: SSH and SFTP
Date: Fri, 29 Sep 2006 02:28:58 -0700
OpenSSH-4.4 now supports something near to what you're looking for,
using Match and ForceCommand.

Here's an excerpt from the changelog in the release message:

This release includes the following new functionality and fixes:

* Implemented conditional configuration in sshd_config(5) using the
 "Match" directive. This allows some configuration options to be
 selectively overridden if specific criteria (based on user, group,
 hostname and/or address) are met. So far a useful subset of post-
 authentication options are supported and more are expected to be
 added in future releases.

* Add support for Diffie-Hellman group exchange key agreement with a
 final hash of SHA256.

* Added a "ForceCommand" directive to sshd_config(5). Similar to the
 command="..." option accepted in ~/.ssh/authorized_keys, this forces
 the execution of the specified command regardless of what the user
 requested. This is very useful in conjunction with the new "Match"
 option.

* Add a "PermitOpen" directive to sshd_config(5). This mirrors the
 permitopen="..." authorized_keys option, allowing fine-grained
 control over the port-forwardings that a user is allowed to
 establish.

* Add optional logging of transactions to sftp-server(8).

* ssh(1) will now record port numbers for hosts stored in
 ~/.ssh/authorized_keys when a non-standard port has been requested.


--

You should be able to perform your requested functionality now. :)

On 9/25/06, Brian <queries33@gmail.com> wrote:
Joshua Feather wrote:
> I'm curious if anyone knows of a way to configure openssh on a
> Solaris(8/9) and Linux system (RH4) to use port 22 for ssh and 522 for
> sftp usikng only one installed client rather that installing seperate
> instances to utilize seperate ports...any help woul dbe greatly
> appreciated!

There are a few 'solutions' but these will require that you have separate sshd
instances and id's for both sftp and ssh for every user. ie: as someone else
pinted out, use two separate config files conf22 and conf522.

Essentially you have to use separate userids on these systems so that userA-ssh
is 'locked' inside a restricted shell (eg:rbash) such that they cannot use sftp
or other file copying utilities (this is not trivial... esp if they need access
to editors, etc).  The other account (userA-sftp) uses either rssh or scponly
as the 'shell' and so cannot login interactively using that account.

Finally add user*-ssh to group sshAllow and user*-sftp to sftpAllow, then use
Deny/AllowGroup in the relevant sshd_config to prevent users gaining access to
the other sshd (they are the same process after all and without this step they
can still login using the other process and matching id...)

eg:
userA-ssh member of sshAllow
userA-sftp member of sftpAllow

in sshd_config22:
DenyGroups sftpAllow
AllowGroups sshAllow

and in sshd_config522:
DenyGroups sshAllow
AllowGroups sftpAllow

But, as I said, it's not bulletproof (can be v difficult to lock users down
depending on what other access they require to the system), requires multiple
userids/person (never good for auditing), in some cases users may need to
remember multiple pwds or other tokens*, auditing requires extra steps to
'normalise' the user access, etc etc.

*That said, the users could use the same keypair for both accounts, and so
login to either system with the one identity file...policies permitting.

I haven't checked the order in which sshd checks the config - for users that
have both groups configured, does openssh process the deny first, or the allow,
or in the order specified in the file?  Maybe just use the Deny option to
forbid users in that category from using the wrong sshd instance... ie:test
whatever you implement to ensure it does what you'd expect...

rssh: http://www.pizzashack.org/rssh/
scponly: http://www.sublimation.org/scponly/


-- g'luck brian


<Prev in Thread] Current Thread [Next in Thread>