search for: remoteforward

Specifying a RemoteForward of 0:example.com:1234 dynamically allocates the listen port on the server, and then reports it to ... the client! Where it is practically useless. Was this someone's idea of a joke? Presumably not--there are some technical obstacles to reporting it to the remote process. I'd like to help...

...hancement Priority: P5 Component: ssh Assignee: unassigned-bugs at mindrot.org Reporter: erjoalgo at gmail.com Created attachment 3727 --> https://bugzilla.mindrot.org/attachment.cgi?id=3727&action=edit Patch to implement ${RANDOM} support I use the RemoteForward keyword in my sshd_config file to create a unix socket on the remote host, I personally use this socket to map to a local program that can receive GUI-related commands, e.g. set clipboard, open a URL in a browser, etc, from any commands executed on the remote server. It looks something like this:...

Hi, I've just upgraded to openssh-4.7p1 on my gentoo box, and I've noticed a incompatibility with openssh-3.6.1p2 running on a redhat AS3 server. If I ssh from my openssh-4.7_p1 client to the openssh-3.6.1p2 server, and RemoteForward a port, the ssh connection closes if I try to send more than roughly 300K through the tunneled port. The problem isn't present when I use openssh-4.6p1 as a client. A typical error is: Disconnecting: Bad packet length 327708. The number varies with retries. The problem is easily reproducible....

Hi, I've just upgraded to openssh-4.7p1 on my gentoo box, and I've noticed a incompatibility with openssh-3.6.1p2 running on a redhat AS3 server. If I ssh from my openssh-4.7_p1 client to the openssh-3.6.1p2 server, and RemoteForward a port, the ssh connection closes if I try to send more than roughly 300K through the tunneled port. The problem isn't present when I use openssh-4.6p1 as a client. A typical error is: Disconnecting: Bad packet length 327708. The number varies with retries. The problem is easily reproducible....

http://bugzilla.mindrot.org/show_bug.cgi?id=1000 dtucker at zip.com.au changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED ------- Comment #5 from dtucker at zip.com.au 2006-10-07 11:39 ------- Change all RESOLVED bug to CLOSED with the exception

...Reporter: dkg at fifthhorseman.net In some situations, users will want to forward a unix domain socket that lives in XDG_RUNTIME_DIR. for example, the default GnuPG gpg-agent's `agent-socket` lives in $XDG_RUNTIME_DIR/S.gpg-agent. But this isn't known by the client when setting up a RemoteForward. If we could use tokens in RemoteForward (see #3014), then one token that would be really nice to have would be this location. -- You are receiving this mail because: You are watching the assignee of the bug.

...on a personal smartcard that is connected to my local system. Problem ===== Now with GnuPG 2.1.13 the socket directory changed from ~/.gnupg to /run/user/<uid>/gnupg on systems where /run/user/<uid> exists, to better accommodate systemd. I now have the problem that my config line: RemoteForward /var/run/user/10118/gnupg/S.gpg-agent /home/aheinecke/.gnupg/S.gpg-agent.extra Does not work if /var/run/user/10118/gnupg/ does not exist. OpenSSH does not create the directory and fails to forward the socket. That it does not exist is the usual case because systemd cleans up this directory on lo...

...server and then curl -D /dev/stdout --unix-socket /tmp/TEST http://xyz/ or nc -U /tmp/TEST on the client side to see, that it is working fine. :-) But then, it is working only for one session. Not for subsequent sessions, because ssh opens /tmp/TEST on the client side (I guess the same for RemoteForward on the server, but haven't tested yet), and leaves the socket /tmp/TEST existing, but can't reuse it. For the ext run, ssh issues unix_listener: cannot bind to path /tmp/TEST: Address already in use and can't use it, thus the connection does not work anymore. It requires a rm /tmp/...

...ostkeys available -- exiting. make: [check-config] Error 1 (ignored) (the current version is rooted in /usr, not /usr/local, and these files live in /etc/ssh.) ============== Anyway, the problem that starts it all: http://www.linuxquestions.org/questions/linux-networking-3/connection-refused-on-remoteforward-ed-port-652472/#post3198878 basically, the "RemoteForward" is not working as expected. It works with my client side daemon running 0.9.8c and 0.9.8e (as reported by "ssh", not "sshd"), but not with 0.9.8g. On the server side, I invoke: /usr/bin/ssh -v -q -g -R ${POR...

...SH which address to bind to for every single port forwarding option! This patch allows you to pass the following as ssh command line options: ssh -L 192.168.1.55:1234:localhost:80 -R ::11:22:aa:bb/80/localhost/80 etc. Or as normal config file options: LocalForward ::11:22:33/1234 localhost/80 RemoteForward 1.2.3.4:80 localhost:80 It will also accept the old-style forwarding options just fine. It would be cool if this could be put into the main branch some day so that everyone can enjoy this functionality. If I'm mistaken, and OpenSSH already had this sort of functionality, please let me know...

...ons like in the Match directive would be nice, but even a fixed string would go a long way. E.g.: === Begin .ssh/config === Host *.localdomain SetEnv EMACS_SOCKET=/home/sascha/.emacs.d/server/server.%l SetEnv GPG_AGENT_INFO=/home/sascha/.gnupg/S.gpg-agent.%l:1:1 Host myserver.localdomain RemoteForward /home/sascha/.emacs.d/server/server.mydesktop:/tmp/emacs8193/server RemoteForward /home/sascha/.gnupg/S.gpg-agent.mydesktop:/home/sascha/.gnupg/S.gpg-agent === End .ssh/config === (As you can see, environment variables and Match-like expansions would be useful in RemoteForward as well, but that...

http://bugzilla.mindrot.org/show_bug.cgi?id=413 markus at openbsd.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED ------- Additional Comments From markus at openbsd.org 2003-02-03 19:50 ------- i'll look into this. ------- You are

...CKS5 proxy. Then > all traffic in firefox will be routed over the ssh connection. It > won't break SNI and for the most part, everything will work in firefox > as if you were connecting from the remote side of the connection. > > It works with yum and dnf too, where you can use RemoteForward to set > up a proxy port on the remote side, set the 'proxy' settings in the > configuration, and all yum/dnf traffic will go over the established > SSH connection. Why would you do this? Well, if you've got a system > that's sitting inside a private, not NAT'd net...

...; all traffic in firefox will be routed over the ssh connection. It > > won't break SNI and for the most part, everything will work in firefox > > as if you were connecting from the remote side of the connection. > > > > It works with yum and dnf too, where you can use RemoteForward to set > > up a proxy port on the remote side, set the 'proxy' settings in the > > configuration, and all yum/dnf traffic will go over the established > > SSH connection. Why would you do this? Well, if you've got a system > > that's sitting inside a privat...

...mp;m=156080681530337&w=2 I am running OpenBSD 6.5-stable (also tested on -current). When I ssh somewhere I get a sig abort from pledge(). I use a Yubikey with GPG and use gpg-agent as my ssh-agent. I also remote forawrd this agent. For example my .ssh/config has the following (please note the RemoteForward is actually all on one line, I have split it here to keep it below 80 chars): Host www Hostname 192.168.1.100 RemoteForward /home/tbrown/.gnupg/S.gpg-agent \ /home/tbrown/.gnupg/S.gpg-agent.extra ExitOnForwardFailure yes Host * ForwardX11 no Compression yes ServerAlive...

https://bugzilla.mindrot.org/show_bug.cgi?id=3017 Bug ID: 3017 Summary: ExitOnForwardFailure=yes doesn't work for local forwards (-L) Product: Portable OpenSSH Version: 7.6p1 Hardware: Other OS: Linux Status: NEW Severity: normal Priority: P5 Component: ssh

If the point is to access a specific web site only the remote machine can get to, you can also do it with port forwarding: ssh -L 8000:ip_of_web_site_to_access_from_remote:443 remote_machine and then locally run any browser, and access https://localhost:443 (assuming it's https. If it's plain http, use "http" and 80). Note that you'll be breaking some aspects of https

...ep closer to a solution. I just added debug output to the forwarding.sh script and it turns out that the test prior to the "transfer over chained unix domain socket forwards ..." test, namely echo "LocalForward ${base}01 127.0.0.1:$PORT" >> $OBJ/ssh_config echo "RemoteForward ${base}02 127.0.0.1:${base}01" >> $OBJ/ssh_config for p in 1 2; do trace "config file: start forwarding, fork to background" ${SSH} -$p -F $OBJ/ssh_config -f somehost sleep 10 trace "config file: transfer over forwarded channels and check result" ${SSH}...

...only accepts absolute paths, which requires knowledge about the remote file-system layout. It would be useful if one could forward a Unix-domain socket without specifying the full path name of the socket on the remote end. There are couple of use-cases: - gpg-agent forwarding uses this syntax: RemoteForward /home/<user>/.gnupg/S.gpg-agent /home/<user>/.gnupg/S.gpg-agent.extra https://wiki.gnupg.org/AgentForwarding - smart card forwarding with p11-kit uses /run/user/$UID/p11-kit https://fosdem.org/2017/schedule/event/smartcard_forwarding/ On the mailing list, it was suggested to call...

...e localhost:port as a SOCKS5 proxy. Then all traffic in firefox will be routed over the ssh connection. It won't break SNI and for the most part, everything will work in firefox as if you were connecting from the remote side of the connection. It works with yum and dnf too, where you can use RemoteForward to set up a proxy port on the remote side, set the 'proxy' settings in the configuration, and all yum/dnf traffic will go over the established SSH connection. Why would you do this? Well, if you've got a system that's sitting inside a private, not NAT'd network and your workst...