Tag Info

New answers tagged

0

If you must use regular FTP, then if all the following conditions are met, you wouldn't be doing that bad in my opinion: Restrict access to the FTP site to only certain trusted IP addresses to prevent hijacking of the FTP account for other purposes Ensure the username and password for the FTP account are not used for anything else and cannot be used to ...


1

Taking from another angle. How comfortable are you with someone outside your company having access to those files even if they are encrypted? If you're nervous then rightly so. You don't want to use FTP. It's not at all safe to use FTP as a transport medium over the internet. FTP should have been phased out years ago. FTP passwords are transmitted in the ...


7

A few things: Not only do you need to protect the data being transfered, but access to the system you're transfering to. A standard FTP session will transmit credentials in the clear. If an attacker obtains these credentials they can gain access to the system you're uploading to. This will allow them to access anything on the server that account is ...


2

Use FTPS then. The problem you face is more for eye dropping on the data. If the attacker can uncrypt your file you will face big trouble. If you really need FTP think to give the user a VPN connection. That would encrypt the transfer.


0

If you have the option to use rsync, you may have some additional controls over permissions. In particular, check out text under the --perms option. Thus spake the man page: In summary: to give destination files (both old and new) the source permissions, use --perms. To give new files the destina- tion-default permissions (while ...


1

Look at lsyncd(http://code.google.com/p/lsyncd/). It will provide inotify=>action part for your solution. It will look like this: cat /etc/lsyncd.conf settings { logfile = "/var/log/lsyncd.log", statusFile = "/var/run/lsyncd.status", nodaemon = false, insist = true, } -- config action my_config = { delay = 10, maxProcesses ...


0

If you add your sftp-server umask option -u with parameter 0222, new uploaded files will be created with above mentioned umask, which means they will not have write access for their files, so they will not be able to delete the files. The line in your sshd_config will look something like this: Subsystem sftp internal-sftp -u 0222


0

In the end, I had to use ACLs. I'm not sure if I'm doing something structurally wrong, but ownership of a grandparent directory does not seem to immediately imply control over grandchild files. Through means of this answer I was able to figure it out: sudo setfacl -Rdm user:B:rwx /sftpchroots/filesbyA/ sudo setfacl -Rm user:B:rwx /sftpchroots/filesbyA/


0

1) The usage of the $? variable is not correct. The problem is that you need to store the return value ($?) immediately after executing the sftp command. Otherwise you will get return value of another command. E.g.: rm /directory_which/does_not_exists echo $? echo "Deleting directory ..." is totaly different than: rm /directory_which/does_not_exists echo ...


4

Use sftp's option -b (with a batchfile or bash's Process Substitution) and you'll get mkdir's return code. sftp -b <(echo "mkdir test_folder") user@remotehost:/ echo $? Output: Changing to: / sftp> mkdir test_folder Couldn't create directory: Failure 1 or use this: echo "mkdir test_folder" | sftp -b - user@remotehost:/ echo ${PIPESTATUS[1]} ...


2

Only write permission on the containing directory is needed to delete a file. Neither ownership nor permissions of the file itself come into play. EDIT: In the case of subdirectories being created via SFTP, this can be achieved in several ways: by making them world writeable (normally not desirable for security reasons) by making them group writeable and ...


0

My first thought would be to reach for my trusty POSIX ACLs: setfacl -m u:someone:rwx /home/user. However, you may also want to consider making a subdirectory inside the chrooted directory to put the files into; that will remove the strict "root-only" requirement on the chroot path that SSH imposes.


0

As specified in the sshd_config man page: ChrootDirectory Specifies the pathname of a directory to chroot(2) to after authentication. At session startup sshd(8) checks that all components of the pathname are root-owned directories which are not writable by any other user or group. After the chroot, sshd(8) changes the working directory to the ...


2

From https://wiki.archlinux.org/index.php/SFTP_chroot, emphasis mine: Write access to chroot dir ...if a user is able to write to the chroot directory then it is possible for them to escalate their privileges to root and escape the chroot. One way around this is to give the user two home directories - one "real" home they can write to, and one SFTP home ...


0

This is the answer: http://ubuntuforums.org/showthread.php?t=2081637&p=12342713#post12342713 I needed a dev folder under chroot and create a rsyslog file. Finally, it works :D !! I'm really happy hehehe. Thanks a lot !



Top 50 recent answers are included