similar to: Proposed enhancement: forward controlling terminal

I noticed that this command returns NO through ssh: > $ ssh user at host "if [ -t 1 ]; then echo YES; else echo NO; fi" > NO and YES when run locally (of course): > $ if [ -t 1 ]; then echo YES; else echo NO; fi > YES I can't find any command line option related to running command remotely in terminal. I think users intuitively expect commands to be run in

Hello List-Members, the forwarded message below is an excerpt from an actual discussion from the Midnigt Commander mailing list (mc at gnome.org, see www.gnome.org/mc/ for details). It`s about a bug and a yet half-implemented feature in the mc fish (File transfer over shell) virtual file system support. The FiSh filesystem allows the user to treat files on a remote server over a shell

https://bugzilla.redhat.com/show_bug.cgi?id=1842440 Patches 1 and 2 address fairly obvious bugs in how we handle reading passwords from stdin. There are other ways we may consider fixing these bugs: - Should password=- always open /dev/tty and ignore stdin entirely? - Should we make password=-0/-1/-2 work by skipping the close? Or perhaps reopen the file descriptors on /dev/null after

Ok, using openssh-SNAP-20010126.tar.gz, two versions of the server both compiled with the configure commands as below, one with USE_PIPES defined and one without. This is on SCO OpenServer 5.0.5 (using SCO dev environment, SCO make, etc.) The client is always linux, openssh 2.3.0p1. export CCFLAGS='-L/usr/local/lib -I/usr/local/include' ./configure --sysconfdir=/etc/ssh

>From what I understand, the problem is due to people's disagreement about what the "correct" behavior should be. I'm pretty sure that the following is the correct behavior from running rsh and ssh often (both fsecure and openssh). Lets say you have a stupid script that does while 1 do sleep 1 done Called foreverSleep on your remote host: rsh remotehost

Dear R users, A colleague of mine asked me how to write a script (an executable text file containing R code) in R. After I showed him, he said that after extensive searching of the R archives, he had not found anything like these techniques. He suggested that I share these methods to enable others to leverage R as a better alternative to bash/perl scripts. So in the interest of giving back to

So I've got this situation where I have two systems connected via a protocol that looks nothing at all like IP, and I'd like to be able to rsync between them. I can, though, open a perfectly normal looking socket through various magic and trickery. I've managed to get rsync to work by using the "rsync --rsh=mymagictransportprogram" style invocation, but for a number of

On 30 Oct 2003, aslan@io.com wrote: > > I was hoping that since you guys are the authors to rsync that > you could answer a simple question for me. > > I'm trying to transfer files via the rsh/rexec protocol by > remotely executing a cat command, i.e. "cat > foo.txt" > and then sending data through the socket to the stdin of the remote > process. This all

http://bugzilla.mindrot.org/show_bug.cgi?id=245 ------- Additional Comments From wknox at mitre.org 2002-05-18 00:58 ------- Same issue with Solaris 8 built with gcc 2.95.2 with the following configure options: --without-rsh --with-tcp-wrappers --with-pam --disable-suid-ssh --with-prngd-socket --with-default-path=/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin Running a ssh -v

Hi all. OpenSSH_4.1p1, OpenSSL 0.9.7g 11 Apr 2005 on Solaris 8 using host-based authentication. With "PrivilegeSeparation yes" and "UsePAM no" everything works as desired. If I enable PAM, I am able to connect, but just before it gives me a shell, it disconnects. If I leave PAM enabled and disable PrivilegeSeparation, it works. Is this a current limitation, or is there

This fixes the main issues in virt-rescue and is usable. There are some enhancements which could be made (in follow up work): - An escape sequence and escape commands that could be handled by virt-rescue, eg. to shut down the appliance, mount or unmount filesystems. - `virt-rescue -i' could be implemented cleanly by performing the right API calls before handing control to the

This set of patches fixes virt-rescue rather cleanly. In particular the problems with handling ^C are completely fixed. Work still to be done before this can go upstream: - Shutdown doesn't work properly if you exit the shell. At the moment to exit you must do 'reboot -f'. Future improvements: - An escape sequence and escape commands that could be handled by virt-rescue,

In the changelog, there is an entry: 20001129 - (djm) Back out all the serverloop.c hacks. sshd will now hang again if there are background children with open fds. Does this mean that this is regarded as expected (and correct) behavior, that should not change in the future, or does it mean that this behavior is a known problem that someone will eventually fix? --Adam -- Adam McKenna

https://bugzilla.mindrot.org/show_bug.cgi?id=3676 Bug ID: 3676 Summary: Redirect conch stdin from /dev/zero rather than requiring a controlling terminal Product: Portable OpenSSH Version: -current Hardware: Other OS: Linux Status: NEW Severity: enhancement Priority: P5

Version 3: - Tidies up the code further. - Implements correct handling of SIGTSTP and SIGCONT. - Adds: ^] s - sync filesystems - Adds: ^] z - suspend virt-rescue Rich.

https://bugzilla.samba.org/show_bug.cgi?id=2784 ------- Additional Comments From carnesresearchcenter@gmail.com 2005-06-09 11:20 ------- *** Bug 2785 has been marked as a duplicate of this bug. *** -- Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact.

SSH, like RSH before it, invokes a command using the user's shell as specified in the passwd file. In a mixed shell environment with some logins csh-like and some sh-like that is sometimes very difficult to handle. (No, I am not fond of csh.) If I could force a single shell everywhere of course that would be preferable but sometimes I have no control over it. I have often wanted an option

Hello, I wrote this patch that allows you to run rsync over an existing I/O connection, instead of creating a new rsh or socket connection. For example, I have a client and server that talk over ssh via a simple custom protocol. I want to use the existing ssh connection to transfer files, but I want the flexibility of rsync to do it. With this patch, I can do the following in my client

Hello All. Attached is an update to my previous patch to make do_pam_chauthtok and privsep play nicely together. First, a question: does anybody care about these or the password expiration patches? Anyway, the "PRIVSEP(do_pam_hauthtok())" has been moved to just after the pty has been allocated but before it's made the controlling tty. This allows the child running chauthtok to

hello short description: ssh client sends a wrong all-zero terminal info when requesting forced pseudo-terminal allocation while stdin is not a terminal. sshd then sets the terminals ospeed to 0 because it receives this information from the client. on solaris this means that the pseudo-terminal is closed and output of any remote command is dropped. longer description: what we're doing is