similar to: Alpha, configure and (brain dead) bash?

Either this never made it to the list or no one cares about Tru64. This is the last time I'll send this patch to the list. If no one steps up and finishes it or provides me with enough information to fix any remaining bugs (one being complaint that 'ssh site cmd' does not work right). If there is no activity on this for a week. I'll post it to bugzilla and will ignore any

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

Dear openssh-unix-dev; I recently downloaded the tarball openssh-3.4p1 and built it for my Tru64 Unix ( OSF/1 ) 5.1a system. My configure statement is: ./configure --prefix=/usr/local/security/tools/openssh-3.4p1 \ --exec-prefix=/usr/local/security/tools/openssh-3.4p1 \ -with-ssl-dir=/usr/local/security/tools/openssl-0.9.6g \ -with-zlib-dir=/usr/local/compress/tools/zlib-1.1.3 \

http://bugzilla.mindrot.org/show_bug.cgi?id=338 ------- Additional Comments From stevesk at pobox.com 2002-07-07 04:00 ------- will look into this ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.

No "ssh -X hostname" doesn't work. But when you "export DISPLAY=..." it works!? I set the the Display Hack so that I can see my IP with "env" or "echo SSH_CLIENT" when I'm connect via VPN-Tunnel and I don't know my IP in the Net I'm connected through. Andreas Kerl ----------------------------------------- DTS Medien GmbH Heidestrasse 38

On 13/10/2017 15:29, Michael Felt wrote: > This verifies it is xauth related: > > debug3: sending debug message: No xauth program; cannot forward with > spoofing. > > so, added an extra debug - and this is what I see: > > debug1: session_input_channel_req: session 0 req x11-req > debug3: setup_x11fwd: xauth_location == /usr/X11R6/bin/xauth > debug3: sending debug

Hello, I have a strange (for me) problem with these two machines : - Client, a CentOS-5.7 workstation ; - Server, a CentOS-6.2 headless, up-to-date server. From Client, I want to use xauth on Server with the help of rsh (yes, I know, ssh and all this sort of things... another time.) When SELinux is in permissive mode on Server, all these commands perform as expected : rsh Server

Ever since I upgraded my laptop from FC15 to FC17, I've been getting this message when I ssh to some RHEL6 hosts inside Red Hat. In particular, I'm trying to do this: virt-viewer --connect \ qemu+ssh://kvm11.devlab.phx1.redhat.com/system \ bork-s01.candlepin.dev.devlab.phx1.redhat.com This is the message I get: X11 forwarding request failed on channel 0 A viewer window pops

Hi folks, I've got a problem with X11 forwarding on an AIX 5.2 system thats stumped me. I've installed the same patched + compiled installp package on all our aix boxes but one of them won't play ball with X11 ssh -X -v -v user at host gives (grepped out X11 looking lines) debug2: we sent a password packet, wait for reply debug1: Authentication succeeded (password). debug1:

Hello All, I set up ltsp regulary, on Centos6 machines. This morning I have a Selinux problem that usualy does not occur: after setting everything up, the thinclients boot, but nobody can login. It only works after the command : # echo 0 > /selinux/enforce I tried this semanage command: # semanage fcontext -a -t bin_t /usr/bin/xauth but it makes no difference. The message I'm now

http://bugzilla.mindrot.org/show_bug.cgi?id=803 Summary: Security Bug: X11 Forwarding is more powerful than it needs to be. Product: Portable OpenSSH Version: -current Platform: All OS/Version: All Status: NEW Severity: major Priority: P2 Component: ssh AssignedTo: openssh-bugs

Hi- I applied the privsep patch to Tru64 5.1A openssh 3.4p1 and it *almost* works. I get in from the client side and xauth is run, but in the meantime the server side disconnects. Running sshd in debug mode level 3 gives the following output: . . . debug1: session_input_channel_req: session 0 req shell debug1: fd 5 setting TCP_NODELAY debug1: channel 0: rfd 13

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

hi, eventually newbie: i want to show remote X-apps on my desktop. now, i know from google that xhost and xauth is not the way to so that very secure. now, i have a ssh_config with X forwarding enabled and a server with forwarding enabled, too. now when i connect to server i read that ssh creates automaticaly a Xauthory file. So i know that this is the xauth way with supercookies etc. but i

I've currently got a couple of boxes which obtain their IP address via DHCP, and as a consequence do not have a mapping in /etc/hosts for their own IP/name... but helpfully (!) they have their name mapping to 127.0.0.1 This breaks X authentication... - openssh (and also ssh) makes an apparently valid xauth entry, but all attempts to start clients gives "X11 connection rejected

Hello all, $XAUTHORITY location has moved from under /tmp to ~/.Xauthority in 2.9p2. The commit message was: --- remove xauth-cookie-in-tmp handling. use default $XAUTHORITY, since we do already trust $HOME/.ssh you can use .ssh/sshrc and .ssh/environment if you want to customize the location of the xauth cookies --- The latter is true, but can only be enabled in per-user basis as far as I see.

On 13/10/2017 08:03, Damien Miller wrote: > On Thu, 12 Oct 2017, Michael Felt wrote: > >> On 08/10/2017 23:32, Michael Felt wrote: >>> On 04/10/2017 11:07, Michael Felt wrote: >>>> I do not often use X11 - but when I do I prefer to enable >>>> X11forwarding, and when finished - turn it off. This is preferable, >>>> imho, to having

After making quite a few circles around one particular issue (and eventually resolving it) I have a suggestion to make: Append the following to http://www.openssh.org/faq.html#2.7 "NOTE: In order to agent forwarding to work you need to have xauth installed in the remote host. In Debian xauth is in 'xbase-clients' package." And about that "F" in

Hello! In configure.in from openssh-2.2.0p1 you are using $xno and $xyes several times. However, those variables are not defined. I guess you mean literals "xno" and "xyes" in all those cases. If that's correct please apply the patch at the end of this message. Regards, Pavel Roskin _____________________ --- configure.in Wed Aug 30 18:20:05 2000 +++ configure.in Wed Oct

On Saturday 26 November 2016 19:25:41 Peter Stuge wrote: > Gene Heskett wrote: > > the inside of the door .. two SBC's: > > .. > > > I have tried running X on the raspi, but it hasn't enough memory or > > iron to do it well. > > A GHz system with GB of RAM is certainly capable of running a > well-written GUI effortlessly. > > > Running htop