similar to: restricting rsync over ssh on the server side.

Is it possible to cooperate with dovecot within its Maildir, and if so, what's required? In this particular case, we're thinking of trying to allow notmuch to operate directly on the dovecot Maildir, and at the moment, the only modifications notmuch makes are to change maildir flags. Would locking dovecot-uidlist.lock be sufficient, perhaps via liblockfile? Also, is there some reliable

I was hoping someone might be able to tell me the current status of direct rendering support? Is it possible to run Xen on a machine and have X DRI (Direct Rendering) work in at least one of the domains? Thanks -- Rob Browning rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu GPG starting 2002-11-03 = 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4

Is it true that when running rsync via ssh (i.e. rsync -e ssh ...) the rsyncd.conf file is not applicable on the remote since rsync is launched via the ssh exec call once connected rather than from rsyncd as in a direct connect. If so, I am trying to find the best way to restrict rsync -e ssh on the remote machine. Prepending the authorized_keys entry with command='rsync ...' 1024...

On Sat, 11 Nov 2023, Bob Proulx wrote: > I am supporting a site that allows members to upload release files. I > have inherited this site which was previously existing. The goal is > to allow members to file transfer to and from their project area for > release distribution but not to allow general shell access and not to > allow access to other parts of the system. > >

I'm having trouble with the rsync wrapper's I've found online: rsync_wrapper[8458]: SSH_ORIGINAL_COMMAND environment variable apparently not set rsync: connection unexpectedly closed (0 bytes read so far) rsync error: error in rsync protocol data stream (code 12) at io.c(189) I'm not sure if this is a problem of incompatibility between my RHES3 and the wrappers I've found or

Hello I've searched quite a bit, but have so far been unsuccessful in finding an answer to a question I have concerning the upload of files via rsync over SSH. When downloading, I have been able to make use of SSH's benefits, yet still keep the rsync server safe from a shell accessible with a private SSH key lacking a passphrase by restricting the public key used by the rsync client to

Hello everyone, I know this is not correct place to ask this question but please help if you know As mentioned some tutorial, i install git version 1.7.3.4 in home directory (/var/chroot/home/content/xx/xxxxxxx/git). then I initialize git repository by git init --bare in my samplerepo.git then i add code in .bashrc file as follow export GIT_BIN=${HOME}/git export

Hello, I'm trying to setup Rsync over SSH with openSSH running port 2222 with a remote RSA public key authentification and a restricted shell to avoid the user to browse my server via SSH, only be able to run rsync server. 1) i've built a regular rsync server over TCP/873 Worked fine, check my conf : motd file = /etc/rsyncd.motd log file = /var/log/rsyncd.log pid

I am thinking of configuring a service where multiple users have their own private keys to do rsync over ssh. I don't want each of these users to have their own UID. I want them each to share a UID, but to have space on the ssh server isolated from any other user. Let us assume that I also wish to prevent them from using any service other than rsync. Is this possible? Is a sensible approach

Hello all, in order to connect to my SSH servers from untrusted devices like company computers or my smartphone, I set up 2FA with google-authenticator hooked into PAM. However, this is not really 2FA at least for the smartphone, since I use the same device for generating the TANs and it is also at least inconvenient to always require a new TAN for each connection. I do not want to solely rely

On 12.11.23 03:52, Damien Miller wrote: > On Sat, 11 Nov 2023, Bob Proulx wrote: > >> I am supporting a site that allows members to upload release files. I >> have inherited this site which was previously existing. The goal is >> to allow members to file transfer to and from their project area for >> release distribution but not to allow general shell access and not

Hello List, I'am using the ForceCommand in my sshd configuration to log all the user actions on my device. ForceCommand /usr/bin/log-session.sh The Log Session Script itself is working fine for logging. But now I want also use SCP to copy files and this won't work together with the ForceCommand above. The copied file is created but its zero byte on the target. scp file.tar.gz

Hi Using SSH_ORIGINAL_COMMAND in AuthorizedKeys is so helpful, I'd like to know if it might be possible to access it in the AuthorizedKeysCommand context (via env ?). Is this possible ? can anybody give me advice on going into this ? If possible, I'll use this SSH_ORIGINAL_COMMAND to send client specifics information to the AuthorizedKeysCommand script. Currently, the only alternative

https://bugzilla.mindrot.org/show_bug.cgi?id=2253 Bug ID: 2253 Summary: No "$@"-like SSH_ORIGINAL_COMMAND leads to escaping, arg-sep and metachar issues Product: Portable OpenSSH Version: 6.6p1 Hardware: Other OS: Linux Status: NEW Severity: enhancement Priority: P5

Hi, I'm trying to use rsync through ssh to pull files from PCs that need to be backup up. I set up the passwordless authentication and things work fine there. However there's a problem when I try to seal off the SSH access to restrict it to limited rsync only using the "command=" in authorized_keys. That by itself works, however not in combination with spaces in the file names.

Hi everyone. I'm looking for a way to identify my SSH's users according to their public key; I mean I would like to have their name logged in my bash session (in a shared unix account). I put this in my .profile: export HISTTIMEFORMAT="[%Y-%m-%d %H:%M:%S - $SSH_USER] " So now I'm trying to make OpenSSH fill the "SSH_USER" variable. First I have to exclude the

This is a new branch of an old thread, made necessary because the email system here purges sent messages after a period of time so I can't reply to the last message in the thread. The operative portion of that last message (retrieved from the archives and dated July 3, 2023) follows: /*****/ So I set up a fresh key to use for this test, and gave it similar parameters. I wasn't aware of

I am supporting a site that allows members to upload release files. I have inherited this site which was previously existing. The goal is to allow members to file transfer to and from their project area for release distribution but not to allow general shell access and not to allow access to other parts of the system. Currently rsync and old scp has been restricted using a restricted shell

On 05.07.23 02:50, Damien Miller wrote: > Some possibilities: > 1. the receive.ksh script is faulty in some way that causes it to invoke > sftp-server How would the script even *know* that the client requested the SFTP subsystem? Is a subsystem's executable/path, supposedly internally overwritten with the forced command at that point, exposed through $SSH_ORIGINAL_COMMAND ?

Hi, I am using rsync to keep two directores on two servers in sync. Machine A, the "client" is the one where the rsync process is invoked, which then logs into Machine B, the "server" as root with ssh and a key. The key is restricted in /root/.ssh/authorized_keys to a script that checks wither $SSH_ORIGINAL_COMMAND matches the rsync --server command that I expect, such as, for