similar to: [Bug 1815] RemoteCommand and PseudoTTY config options

https://bugzilla.mindrot.org/show_bug.cgi?id=1815 Summary: RemoteCommand and PseudoTTY config options Product: Portable OpenSSH Version: 5.1p1 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P2 Component: ssh AssignedTo: unassigned-bugs at mindrot.org ReportedBy:

https://bugzilla.mindrot.org/show_bug.cgi?id=1815 Damien Miller <djm at mindrot.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #9 from Damien Miller <djm at mindrot.org> --- Close all resolved bugs after 7.3p1 release

Hey there, I often want different behavior in my ssh client depending on whether I'm logging into an interactive session or running a remote non-interactive command. We can see at, say, https://unix.stackexchange.com/a/499562/305714 that this isn't a unique wish, and existing solutions are kind of baroque. Typical reasons to do this are to immediately go into a screen or tmux session; for

https://bugzilla.mindrot.org/show_bug.cgi?id=3209 Bug ID: 3209 Summary: Make overriding RemoteCommand on the cli easier Product: Portable OpenSSH Version: 8.3p1 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 Component: ssh Assignee: unassigned-bugs at

https://bugzilla.mindrot.org/show_bug.cgi?id=2558 Bug ID: 2558 Summary: Add RemoteCommand option to ssh client Product: Portable OpenSSH Version: 7.2p1 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 Component: ssh Assignee: unassigned-bugs at mindrot.org

https://bugzilla.mindrot.org/show_bug.cgi?id=2103 Bug ID: 2103 Summary: remote command as an option in ssh_config Classification: Unclassified Product: Portable OpenSSH Version: 6.2p1 Hardware: Other OS: Linux Status: NEW Severity: enhancement Priority: P5 Component: ssh

I'm running OpenSSH 5.1p1 on openSUSE 10.3 (i586) and I want to setup chroot jails for certain SFTP-only users. I use the following lines in my sshd_config file: Match Group sftponly ChrootDirectory /home/chroot-%u ForceCommand internal-sftp It works great. The problem is that some of my users need umask 002 for their uploads. I tried a few ways to achieve this: * set umask in sshrc,

Or just create bash (or whatever your favorite shell equivalent is) alias? alias issh=?sah -F ~/.ssh/altcinfig? Or wrapper scripts in ~/bin/ you can invoke? Literally what I do for mosh, mosh+screen etc. -- "Genius might be described as a supreme capacity for getting its possessors into trouble of all kinds." -- Samuel Butler On Fri, May 3, 2024 at 20:27 <openssh at tr.id.au>

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 With this change built ok. But patch must be quite different on my platform (see attached) for portable version. And, of course, after autoreconf run. 02.08.2016 10:55, Darren Tucker ?????: > --- a/configure.ac > +++ b/configure.ac > @@ -754,6 +754,9 @@ main() { if (NSVersionOfRunTimeLibrary("System") >= (60 << 16))

Currently, ~/.ssh/environment can set static environment variables, and ~/.ssh/rc can run initialization routines. But there is no way for sshrc to propagate changes to the environment to the user's shell or command. There is, however, a possible way to do this. If the PermitUserEnvironment option is set, sshd could treat the stdout of sshrc as additional assignment lines of the form

Hey Damien, > Would something like this help? > > Match sessiontype shell > User foo > Match remotecommand "none" > User foo2 > Match sessiontype exec remotecommand "/rsync" > User bar > Match sessiontype subsystem remotecommand "sftp" > User baz > > > diff --git a/readconf.c b/readconf.c > <snip> Thanks for looking

Hi! It feels like there is an obvious answer to this that I'm not seeing, but I've been testing, reading manuals and googling for a while now and can't seem to get it to work. I have an SSH server that mounts a windows share on login, to act as a SFTP proxy for windows home directories. The mounting of the users' homedirs is done via a call from /etc/ssh/sshrc. This mount

On Sun, 2018-01-07 at 18:41 +0000, halfdog wrote: > Hello list, > > I created a page to demonstrate, what would happen when chroot > root directory is writeable. In fact, code execution is possible > already, when only /etc and /bin are writable. I also tried to > escape the chroot jail, but that did not work for non-root users. > > As the 2009 CVE activities mention,

When doing a make with the portable developer version, I came across this error: ssh/ssh_host_ecdsa_key|/opt/etc/ssh_host_ecdsa_key|g' -e 's|/etc/ssh/ssh_host_dsa_key|/opt/etc/ssh_host_dsa_key|g' -e 's|/etc/ssh/ssh_host_rsa_key|/opt/etc/ssh_host_rsa_key|g' -e 's|/var/run/sshd.pid|/var/run/sshd.pid|g' -e 's|/etc/moduli|/opt/etc/moduli|g' -e

While logging in via ssh (versions 1.2.17 and 1.2.12) under Linux 2.0, I found that limits weren''t being set (as shown by the output of "limit" (tcsh) or "ulimit -a" (bash). Since /etc/profile, /etc/csh.cshrc, and /etc/limits were ignored, I made /etc/sshrc and put "ulimit" statements in it. However, I was unable to limit the number of processes this way,

On Sat, 4 May 2024, openssh at tr.id.au wrote: > Hey there, > > I often want different behavior in my ssh client depending on > whether I'm logging into an interactive session or running > a remote non-interactive command. We can see at, say, > https://unix.stackexchange.com/a/499562/305714 that this isn't a > unique wish, and existing solutions are kind of baroque.

https://bugzilla.mindrot.org/show_bug.cgi?id=3185 Bug ID: 3185 Summary: some bashrc broke sshrc Product: Portable OpenSSH Version: 8.3p1 Hardware: amd64 OS: Linux Status: NEW Severity: minor Priority: P5 Component: sshd Assignee: unassigned-bugs at mindrot.org

Dear OpenSSH developers, I hope you don't mind that I resubmit my patch for OpenSSH. This patch adds a new ssh_config option "ExecRemoteCommand", which is the missing equivalent to the "-N" command line option. For implementation notes, please have a look at the top of the patch. Regards, Volker -- Volker Diels-Grabsch ----<<<((()))>>>----

I have just finished battling with this and noticed it has been reported on HP systems too. Problem ist, if you have an sshrc file with: XKEY=`cat -` -n "$DISPLAY" && $XAUTH add $DISPLAY $XKEY then with SSH 3.1 this mysteriously fails, as the DISPLAY is now localhost:10.0 instead of $HOST:10.0 I imagine the reasoning behind the change is to accomodate hosts that have no

http://bugzilla.mindrot.org/show_bug.cgi?id=771 Summary: Add option to override XAUTHORITY env variable Product: Portable OpenSSH Version: 3.7.1p1 Platform: UltraSparc OS/Version: SunOS Status: NEW Severity: enhancement Priority: P5 Component: sshd AssignedTo: openssh-bugs at mindrot.org