> On Mon, 01 Apr 2002 10:35:35 -0500, Jon McCain
> <[EMAIL PROTECTED]> was runoured to have said:
> All of this has gotten me to thinking about another flaw in the way I
> have things set up. I'm preventing users from getting to a $ by running
> a menu from their profile.
> exec /u
> On Mon, 01 Apr 2002 10:35:35 -0500, Jon McCain
> <[EMAIL PROTECTED]> was runoured to have said:
> All of this has gotten me to thinking about another flaw in the way I
> have things set up. I'm preventing users from getting to a $ by running
> a menu from their profile.
> exec /
On Mon, Apr 01, 2002 at 10:35:35AM -0500, Jon McCain wrote:
> But changing permissions on the .bash_profile so they don't own it (and
> not in their group) should take care of that problem. They can read it
> all they want, just not change it.
A cleaner solution would be to make it immutable.
(a
On Mon, 2002-04-01 at 18:41, Jon McCain wrote:
> Chris Reeves wrote:
> >
> > Why not change the users' shell to /usr/bin/menu?
> >
>
> Because they need to be able to transfer files to their home
> directories. If you do this, then ftp,pscp,etc won't work. My original
> goal was to allow them
Chris Reeves wrote:
>
> Why not change the users' shell to /usr/bin/menu?
>
Because they need to be able to transfer files to their home
directories. If you do this, then ftp,pscp,etc won't work. My original
goal was to allow them transfer files to/from home directory with
something besides ft
On Mon, Apr 01, 2002 at 10:35:35AM -0500, Jon McCain wrote:
> But changing permissions on the .bash_profile so they don't own it (and
> not in their group) should take care of that problem. They can read it
> all they want, just not change it.
A cleaner solution would be to make it immutable.
(
On Mon, Apr 01, 2002 at 10:35:35AM -0500, Jon McCain wrote:
> All of this has gotten me to thinking about another flaw in the way I
> have things set up. I'm preventing users from getting to a $ by running
> a menu from their profile.
>
> exec /usr/bin/menu
>
> This works fine since the exec cau
All of this has gotten me to thinking about another flaw in the way I
have things set up. I'm preventing users from getting to a $ by running
a menu from their profile.
exec /usr/bin/menu
This works fine since the exec causes menu to become their shell
process.
But some smart user could get aro
On Mon, Apr 01, 2002 at 10:04:50AM -0300, Pedro Zorzenon Neto wrote:
> With the following commands, you can copy files without "scp":
>
> $ cat localfile | ssh somehost "cat > /somedir/remotefile"
> $ ssh somehost "cat /somedir/remotefile" > localfile
>
> So, it seems unusefull to disable "sc
I think some of you misunderstood me. I was not clear about my
concern. Users can ssh into my machine but their profiles are fixed to
run a menu of things I allow them to do. Thus they can't get to the $
prompt and thus can't cd to other directories to see what's there. And
even they did, permi
>
> > The user can change to directories above their home.
> > Is there a way to chroot them
>
> Use restricted bash shell for the user (/bin/rbash) in the
> /etc/passwd.
>
This does not seem to affect sshd. I changed a user to use rbash but I
could still go to a windows machine and use the pu
On Mon, 2002-04-01 at 18:41, Jon McCain wrote:
> Chris Reeves wrote:
> >
> > Why not change the users' shell to /usr/bin/menu?
> >
>
> Because they need to be able to transfer files to their home
> directories. If you do this, then ftp,pscp,etc won't work. My original
> goal was to allow them
Chris Reeves wrote:
>
> Why not change the users' shell to /usr/bin/menu?
>
Because they need to be able to transfer files to their home
directories. If you do this, then ftp,pscp,etc won't work. My original
goal was to allow them transfer files to/from home directory with
something besides f
On Mon, Apr 01, 2002 at 10:35:35AM -0500, Jon McCain wrote:
> All of this has gotten me to thinking about another flaw in the way I
> have things set up. I'm preventing users from getting to a $ by running
> a menu from their profile.
>
> exec /usr/bin/menu
>
> This works fine since the exec ca
On Sat, Mar 30, 2002 at 10:24:28PM -0500, Jon McCain wrote:
> I've been playing around with the scp and sftp components of putty and
> noticed what I consider a security hole. Winscp does the same thing.
> The user can change to directories above their home. Is there a way to
> chroot them like
All of this has gotten me to thinking about another flaw in the way I
have things set up. I'm preventing users from getting to a $ by running
a menu from their profile.
exec /usr/bin/menu
This works fine since the exec causes menu to become their shell
process.
But some smart user could get ar
On Mon, Apr 01, 2002 at 10:04:50AM -0300, Pedro Zorzenon Neto wrote:
> With the following commands, you can copy files without "scp":
>
> $ cat localfile | ssh somehost "cat > /somedir/remotefile"
> $ ssh somehost "cat /somedir/remotefile" > localfile
>
> So, it seems unusefull to disable "s
I think some of you misunderstood me. I was not clear about my
concern. Users can ssh into my machine but their profiles are fixed to
run a menu of things I allow them to do. Thus they can't get to the $
prompt and thus can't cd to other directories to see what's there. And
even they did, perm
>
> > The user can change to directories above their home.
> > Is there a way to chroot them
>
> Use restricted bash shell for the user (/bin/rbash) in the
> /etc/passwd.
>
This does not seem to affect sshd. I changed a user to use rbash but I
could still go to a windows machine and use the p
On Sat, Mar 30, 2002 at 10:24:28PM -0500, Jon McCain wrote:
> I've been playing around with the scp and sftp components of putty and
> noticed what I consider a security hole. Winscp does the same thing.
> The user can change to directories above their home. Is there a way to
> chroot them like
- Original Message -
From: "Jon McCain"
Sent: Sunday, March 31, 2002 8:54 AM
> The user can change to directories above their home.
> Is there a way to chroot them
Use restricted bash shell for the user (/bin/rbash) in the
/etc/passwd.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
wit
- Original Message -
From: "Jon McCain"
Sent: Sunday, March 31, 2002 8:54 AM
> The user can change to directories above their home.
> Is there a way to chroot them
Use restricted bash shell for the user (/bin/rbash) in the
/etc/passwd.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
wi
> I've been playing around with the scp and sftp components of putty
> and
> noticed what I consider a security hole. Winscp does the same thing.
> The user can change to directories above their home. Is there a way
> to
> chroot them like you can in an ftp config file?
scp is merely a way to use
On Sat, Mar 30, 2002 at 10:24:28PM -0500, Jon McCain wrote:
> I've been playing around with the scp and sftp components of putty and
> noticed what I consider a security hole. Winscp does the same thing.
> The user can change to directories above their home. Is there a way to
> chroot them like
> I've been playing around with the scp and sftp components of putty
> and
> noticed what I consider a security hole. Winscp does the same thing.
> The user can change to directories above their home. Is there a way
> to
> chroot them like you can in an ftp config file?
scp is merely a way to us
On Sat, Mar 30, 2002 at 10:24:28PM -0500, Jon McCain wrote:
> I've been playing around with the scp and sftp components of putty and
> noticed what I consider a security hole. Winscp does the same thing.
> The user can change to directories above their home. Is there a way to
> chroot them like
On Sun, 2002-03-31 at 05:24, Jon McCain wrote:
> I've been playing around with the scp and sftp components of putty and
> noticed what I consider a security hole. Winscp does the same thing.
> The user can change to directories above their home. Is there a way to
> chroot them like you can in an
On Sun, 2002-03-31 at 05:24, Jon McCain wrote:
> I've been playing around with the scp and sftp components of putty and
> noticed what I consider a security hole. Winscp does the same thing.
> The user can change to directories above their home. Is there a way to
> chroot them like you can in a
the commercial ssh server has an option to chroot to a user's home
directory. there are patches available to openssh to do it also,
though i don't know if they've been thoroughly audited. check out
http://mail.incredimail.com/howto/openssh/
you can make sftp-server the user's shell to only allow
the commercial ssh server has an option to chroot to a user's home
directory. there are patches available to openssh to do it also,
though i don't know if they've been thoroughly audited. check out
http://mail.incredimail.com/howto/openssh/
you can make sftp-server the user's shell to only allow
hi ya
i'd do it with automounter w/ ssh ???
mount remote:/home/httpd/html /mnt/html
scp /home/user/new_site.html /mnt/html
sync
umount /mnt/html
mount is not needed if it is configured to auotmount
and does NOT need shell account on the remote web server
you also cannot cd / on the remote
Jon McCain <[EMAIL PROTECTED]> cum veritate scripsit:
> I've been playing around with the scp and sftp components of putty and
> noticed what I consider a security hole. Winscp does the same thing.
> The user can change to directories above their home. Is there a way to
> chroot them like you c
hi ya
i'd do it with automounter w/ ssh ???
mount remote:/home/httpd/html /mnt/html
scp /home/user/new_site.html /mnt/html
sync
umount /mnt/html
mount is not needed if it is configured to auotmount
and does NOT need shell account on the remote web server
you also cannot cd / on the remote
Jon McCain <[EMAIL PROTECTED]> cum veritate scripsit:
> I've been playing around with the scp and sftp components of putty and
> noticed what I consider a security hole. Winscp does the same thing.
> The user can change to directories above their home. Is there a way to
> chroot them like you
34 matches
Mail list logo
