Re: secure file transfer
In proftpd.conf: RequireValidShell off ;-) I would be careful about doing that. That might open ftp access for accounts you dont want to have access. Plus some applications create special accounts without shells like mysql,inetd,etc. mysql:x:103:102:MySQL Server:/var/lib/mysql:/bin/false You don't want to sacrifice security for convenience. ___ (@ @) --oOo--(_)--oOo--- Jon McCainEmail: [EMAIL PROTECTED] Sr. ProgrammerVoice: 912-355-3213 DavLong Business Solutions Fax: 912-355-3575 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: secure file transfer
Renato Lozano wrote: Hi All, I am trying to implement a way of transfering files securely over the Internet using sftp which is part of the ssh2 protocol. A down side of implementing this is that users logging on can browse the whole filesystem. I have done some research and found a way to chroot users so they won't be able to browse the filesystem (http://chrootssh.sourceforge.net/). Can someone please suggest if there are any other ways of implementing a secure file transfer without patching sshd ??? Nato I had the same concerns a few months back. I wanted to use sftp but I disliked the fact that they can see the whole filesystem although debian's default permission on the important files prevents anyone from changing them. I did not want to patch ssh either. It was so complex and I wanted to be keep to a standard ssh so as to keep up with the security updates to ssh. So I used vpn and ftp. The firewall is set to block the ftp ports for anything from the internet. Using vpn gives the user a local ip and thus allows ftp to get through plus the traffic is encrypted. Proftp lets you chroot the user to their home dir. You can remove the sftp-server program to disable sftp but you can't turn off the scp commands. They are part of ssh. So someone could still use something like winscp and be able to browse everything. You can break scp by making the users shell a menu script (i.e. /usr/bin/yourmenu instead of /usr/bin/bash) so they can not get to a $ prompt. You also have to define your menu script as a shell (/etc/shell) so regular ftp will still work. -- ___ (@ @) --oOo--(_)--oOo--- Jon McCainEmail: [EMAIL PROTECTED] Sr. ProgrammerVoice: 912-355-3213 DavLong Business Solutions Fax: 912-355-3575 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: secure file transfer
Renato Lozano wrote: Hi All, I am trying to implement a way of transfering files securely over the Internet using sftp which is part of the ssh2 protocol. A down side of implementing this is that users logging on can browse the whole filesystem. I have done some research and found a way to chroot users so they won't be able to browse the filesystem (http://chrootssh.sourceforge.net/). Can someone please suggest if there are any other ways of implementing a secure file transfer without patching sshd ??? Nato I had the same concerns a few months back. I wanted to use sftp but I disliked the fact that they can see the whole filesystem although debian's default permission on the important files prevents anyone from changing them. I did not want to patch ssh either. It was so complex and I wanted to be keep to a standard ssh so as to keep up with the security updates to ssh. So I used vpn and ftp. The firewall is set to block the ftp ports for anything from the internet. Using vpn gives the user a local ip and thus allows ftp to get through plus the traffic is encrypted. Proftp lets you chroot the user to their home dir. You can remove the sftp-server program to disable sftp but you can't turn off the scp commands. They are part of ssh. So someone could still use something like winscp and be able to browse everything. You can break scp by making the users shell a menu script (i.e. /usr/bin/yourmenu instead of /usr/bin/bash) so they can not get to a $ prompt. You also have to define your menu script as a shell (/etc/shell) so regular ftp will still work. -- ___ (@ @) --oOo--(_)--oOo--- Jon McCainEmail: [EMAIL PROTECTED] Sr. ProgrammerVoice: 912-355-3213 DavLong Business Solutions Fax: 912-355-3575 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
re: scp and ftp
I'm not sure if this message made it through. Our ISP was having problems this morning. Sorry if you get this message twice. 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, permission are set so they could not overwrite important files. I simply don't want them to be able to read stuff not in their own home. Files like /etc/passwd,/etc/shadow,etc. Anything with information someone could use to locally exploit the machine. But you can use pscp from a windows machine and poke around and download files from places other than your home directory. If there is another email list that this is more appropriate for, let me know. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: scp and sftp
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 putty program pscp to get a file from /etc. pscp [EMAIL PROTECTED]:/etc/passwd passwd.txt Maybe it's simply just not a feature of openssh. I think I'll investigate that chroot patch to sshd someone mentioned. I think they said it was for woody, but I'll see if it works with potato. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
re: scp and sftp
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, permission are set so they could not overwrite important files. I simply don't want them to be able to read stuff not in their own home. Files like /etc/passwd,/etc/shadow,etc. Anything with information someone could use to locally exploit the machine. But you can use pscp from a windows machine and poke around and download files from places other than your home directory. If there is another email list that this is more appropriate for, let me know. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
re: scp and ftp
I'm not sure if this message made it through. Our ISP was having problems this morning. Sorry if you get this message twice. 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, permission are set so they could not overwrite important files. I simply don't want them to be able to read stuff not in their own home. Files like /etc/passwd,/etc/shadow,etc. Anything with information someone could use to locally exploit the machine. But you can use pscp from a windows machine and poke around and download files from places other than your home directory. If there is another email list that this is more appropriate for, let me know. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: scp and sftp
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 putty program pscp to get a file from /etc. pscp [EMAIL PROTECTED]:/etc/passwd passwd.txt Maybe it's simply just not a feature of openssh. I think I'll investigate that chroot patch to sshd someone mentioned. I think they said it was for woody, but I'll see if it works with potato. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
re: scp and sftp
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, permission are set so they could not overwrite important files. I simply don't want them to be able to read stuff not in their own home. Files like /etc/passwd,/etc/shadow,etc. Anything with information someone could use to locally exploit the machine. But you can use pscp from a windows machine and poke around and download files from places other than your home directory. If there is another email list that this is more appropriate for, let me know. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
re: scp and sftp
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 around this by using pscp to upload their own .bash_profile. Even if I fix it so I have them chroot'd on their home would not prevent this since this file is in their home. 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. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: scp and sftp
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 ftp (since they are going over the internet) but not allow them to change to directories above the home. Proftp allowed me to chroot them to the home but scp/sftp does not. I can use vpn to let them safely use ftp over the internet. That's only way they can use ftp since the firewall blocks ftp from the internet. But that stills leaves the scp hole. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
scp and sftp
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? I don't see anything in the sshd config files. If you can't, how can I disable the scp functionality? I'm not talking about scp from the linux box. The users don't have shell access so that's not a problem. I'm referring to remote people using a scp client to access my linux machine. You can disable sftp ability by removing the sftp-server program but the scp server part seems to be part of sshd. I did not see anything about this issue on the openssh web site. Anybody got any suggestions? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
scp and sftp
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? I don't see anything in the sshd config files. If you can't, how can I disable the scp functionality? I'm not talking about scp from the linux box. The users don't have shell access so that's not a problem. I'm referring to remote people using a scp client to access my linux machine. You can disable sftp ability by removing the sftp-server program but the scp server part seems to be part of sshd. I did not see anything about this issue on the openssh web site. Anybody got any suggestions? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Kernel 2.4 SOS
Craig wrote: Goodday ladies and fellas I have potato installed on a box that will be a proxy and firewall. I needed to have the facility of port forwarding so i was told to install kernel 2.4. Does kernel 2.4 have some special feature of port forwarding that the 2.2.x kernels don't have? I don't see why mess with 2.4 at all when kernel 2.2.17 (potato rev0) or higher will handle port forwarding just fine. And by just using potato, you can keep up with the security updates easier. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Kernel 2.4 SOS
Craig wrote: Goodday ladies and fellas I have potato installed on a box that will be a proxy and firewall. I needed to have the facility of port forwarding so i was told to install kernel 2.4. Does kernel 2.4 have some special feature of port forwarding that the 2.2.x kernels don't have? I don't see why mess with 2.4 at all when kernel 2.2.17 (potato rev0) or higher will handle port forwarding just fine. And by just using potato, you can keep up with the security updates easier.
