Ssh

visually
With the -L and -R flags, think in terms of what application (mplayer) you are tempting to use over an encrypted link to a remote pc's sshd daemon program. The -R flag is interpreted as remote or reverse from either of the two computers. From the computer(not behind a NAT,192.168.1.55:8653) running mplayer, the port 8653 is seen being remotely opened by the sshd daemon(behind a NAT,192.168.1.60:22), binded to a specific Ethernet port and its associated localhost number (127.0.0.4). From 192.168.1.60:22 the remote ip 192.168.1.55:8653 is seen as remote on which a reverse ssh connection is made on 8653(opened by the sshd daemon from 192.168.1.60:22), allowing the mplayer application to reverse back to it. With the -L flag this same mplayer(192.168.1.55:8653), either behind a NAT or not, initiates contact with the remote pc (192.168.1.60:22)(no NAT), port 22 as per /etc/ssh/sshd_config file.

https://iximiuz.com/en/posts/ssh-tunnels/ from https://news.ycombinator.com/item?id=34349929
 * "The mnemonics are "ssh -L local:remote" and "ssh -R remote:local" and it's always the left-hand side that opens a new port."

This implies that such port had to be closed before being opened, but that the ports on the right hand side could be either open or closed.? So the two line below could executed in any order?: socat TCP-LISTEN:8777,reuseaddr,fork TCP:8653 & ssh -4 -f -n -L 8653:localhost:12500 jump@188.123.1.100 &

If the remote pc is TCP reachable(not behind a NAT) and you wish to connect to the RTSP server on 192.168.1.200:8554 (same LAN sshd runs on 192.168.1.98)

If the remote pc isn't TCP reachable(behind a NAT) and you wish to connect to the RTSP server on on 192.168.1.200:8554, then the sshd server daemon does a reverse ssh connection to your pc(assuming your pc isn't behind a NAT and has port 22 open) from 192.168.1.98

With the -L flag the computer running mplayer, the port 8653(binded to 127.0.0.3 for example) is forwarded to the remote port 8554 on the remote pc via its sshd daemon on the same LAN.

ssh
https://www.howtoforge.com/reverse-ssh-tunneling and http://cb.vu/unixtoolbox.xhtml Ssh into another pc via a VPS from a client pc behind a NAT or router where the ports are blocked. The idea is for the target pc to create a SSH tunnel to either a server or directly to the client pc. Because we don't wish to expose the client pc's ports to the world a server is used as an intermediary. From the client pc we are finally able to create a ssh session back to the target through this tunnel.

Reverse SSH from the Target PC to the middleman(jump server): ssh -R {PortOnMiddlePC}:localhost:{PortOnTargetPC} {UserOnMiddlePC}@{IPofMiddlePC}

ssh -R remoteport:localhost:port jump@192.168.1.100 forward whatever connects to the remote port on the jump server back to the localhost:port from which the ssh -R command is executed(target pc in the context of this example).

From the jumpserver itself issue command But because you're not on the jumpserver you have to forward your local port to the jumpserver: ssh -4 -f -n -L localport:remotehost:remoteport jump@192.168.1.100 (local:remote order is reversed with -R flag)

Finally, ssh the Target PC from the Client PC in another terminal:

Using ssh localhost -p 9874 instead will attempt to login as client pc user, instead of as the user on the target pc. /var/log/auth.log flagged that I attempted to login as the wrong user. In other words what we attempted to do on the jumpserver with ssh pi@localhost -p 12500 is now executed on the client pc via local port forwarding from the client pc with command ssh targetusername@localhost  -p 9874

Enable GateWayPorts in the sshd_config file under /etc/ssh on the jumpserver.(socat overrides this option,defeating the whole purpose of preventing portforwarding via sshd_config file. If you use socat set the setting to no. Use the -x flag (ssh -x target@localhost -p 9874) if you don't wish to run a X11 session, preventing the target pc from attacking the client pc. For X11 use (ssh -X target@localhost -p 9874). GatewayPorts clientspecified is preferred over GatewayPorts yes  which enables all IPs binded to the pc. Creat a listener connector with socat if gatewayports can't be changed from no. This defeats the whole point of preventing port forwarding with the sshd_config file.

ports
https://www.howtogeek.com/168145/how-to-use-ssh-tunneling/ from ssh format binding to multiple local IP addresses -L [bind_address:]port:host:hostport or forward port 2221 from a single ip on a physical pc on local side to localhost port 3122 of server 188.88.88.88 on remote side.

http://zarb.org/~gc/html/udp-in-ssh-tunneling.html udp over ssh. See Gprs and wifi streaming https://help.ubuntu.com/community/SSH/OpenSSH/PortForwarding https://dev.to/samuyi/the-how-to-of-ssh-port-forwarding-1f4e x11 forwarding https://unix.stackexchange.com/questions/46235/how-does-reverse-ssh-tunneling-work from https://www.howtogeek.com/428413/what-is-reverse-ssh-tunneling-and-how-to-use-it/ and and control background process with ssh
 * }

gatewayports
https://github.com/sumup-oss/gocat socat alternative http://blog.joncairns.com/2013/12/understanding-ssh-agent-and-ssh-add/ ssh-agent from shh_auth_sock(stackoverflow) sharing ssh agent links to https://github.com/intuited/sshag and https://github.com/ccontavalli/ssh-ident make ssh tunnel publicly accessible cites(how to tunnel local port to remote server and selecting interface for ssh port forward) Warning: if you set GatewayPorts to yes this will make sshd bind your forwardings to any interface - regardless of the client configuration (-R, etc.). This can become quite a security issue if the client assumes he has limited his forwardings to f.e. localhost. Therefore, setting GatewayPorts to clientspecified is usually what you want. With the -R option enable gatewayports in the /etc/sshd_config file on the remote computer.

Here's my answer for completion: I ended up using ssh -R ... for tunneling, and using socat on top of that for redirecting network traffic to 127.0.0.1: tunnel binded to 127.0.0.1: ssh -R mitm:9999::8084 me@mitm socat TCP-LISTEN:9090,fork TCP:127.0.0.1:9999 Other option is to do a local-only tunnel on top of that, but i find this much slower ssh -L:9090:localhost:9999 localhost

udp over ssh

 * ffmpeg stream videofile via UDP over ssh
 * 1) https://copyconstruct.medium.com/socat-29453e9fc8a6
 * 2) https://superuser.com/questions/1532374/ssh-tunnel-socat-udp-unicast-multicast and refs
 * 3) https://stackpointer.io/network/ssh-port-forwarding-tcp-udp/365/
 * 4) https://superuser.com/questions/62303/how-can-i-tunnel-all-of-my-network-traffic-through-ssh
 * 5) https://superuser.com/questions/331582/netcat-socat-behavior-with-piping-and-udp?rq=1
 * 6) https://superuser.com/questions/771155/impersonate-a-serial-device-with-socat?rq=1 SERIAL OVER SOCAT

superuser 53103
Server side: socat tcp4-listen:5353,reuseaddr,fork UDP:nameserver:53 Client side: socat -T15 udp4-recvfrom:53,reuseaddr,fork tcp:localhost:5353 And not at all with parallel requests. – Peter V. Mørch Apr 20 '20 ..
 * 1) https://superuser.com/questions/53103/udp-traffic-through-ssh-tunnel?rq=1 links to https://securesocketfunneling.github.io/ssf/#home
 * 2) http://zarb.org/~gc/html/udp-in-ssh-tunneling.html with netcat but Brian Marshall and Zakaria have an alternative solution using socat. It eliminates the fifo file requirement. Here's how to do:
 * 1) https://www.morch.com/2011/07/05/forwarding-snmp-ports-over-ssh-using-socat/ ...And this is the main improvement of socat over nc. nc will do it for one single UDP port combination, which means it will work for SNMP for "some time" until the SNMP manager chooses another source port (which it is free to do for every request). Socat handles that. nc doesn't. So with nc, SNMP forwarding will work "for a little while" only.

sshuttel ,proxychains

 * 1) https://github.com/rofl0r/proxychains-ng
 * 2) https://superuser.com/questions/62303/how-can-i-tunnel-all-of-my-network-traffic-through-ssh #sshuttle
 * 3) https://www.tunnelsup.com/how-to-create-ssh-tunnels/
 * 4) https://github.com/sshuttle/sshuttle

dergachev
https://pastebin.com/9A9rvKPu ,(https://archive.ph/vKK7x),(https://archive.ph/hiFRa) Append only new text from clipboard to file in shell, vlang, goland and c. https://gist.github.com/dergachev/8259104 ssh forward clipboard sites https://gist.github.com/burke/5960455  and https://seancoates.com/blogs/remote-pbcopy https://web.archive.org/web/20140228075602/http://www.ping.eti.br/docs/01/13.txt from https://gist.github.com/dergachev/7913990 Reverse Shell Cheat Sheet, links to links with socat integration. | pentestmonkey https://superuser.com/questions/123790/socat-and-rich-terminals-with-ctrlc-ctrlz-ctrld-propagation setsid command https://github.com/vi/dive Start programs inside unshare/lxc namespaces easily using UNIX sockets + easy access to capabilities, namespaces, chroot and others. https://gist.github.com/dergachev/f0d15f45f32b753959517f8a6a708171 links to links https://gist.github.com/dergachev/7916152  set guid root backdoor  Why You Can't Un-Root a Compromised Machine Let's say somebody temporarily got root access to your system, whether because you "temporarily" gave them sudo rights, they guessed your password, or any other way. Even if you can disable their original method of accessing root, there's an infinite number of dirty tricks they can use to easily get it back in the future. While the obvious tricks are easy to spot, like adding an entry to /root/.ssh/authorized_keys, or creating a new user, potentially via running malware, or via a cron job. I recently came across a rather subtle one that doesn't require changing any code, but instead exploits a standard feature of Linux user permissions system called setuid to subtly allow them to execute a root shell from any user account from the system (including www-data, which you might not even know if compromised).

ssh keys
create private public keys https://medium.com/risan/upgrade-your-ssh-key-to-ed25519-c6e8d60d3c54

ssh-keygen -o -a 100 -t ed25519 -f ~/.ssh/id_ed25519 -C "john@example.com" Only a quantum mechanics type source of indeterminacy(not randomness, which doesn't exist) enables a enough entropy(nobody knows what this word means) seed. With a concentrate of energy we have high "entropy", as the energy fills the medium we have low entropy. Usually such a situation is designed(binary opposite of random) like heating the end of a metal bar, loading it with high entropy and then allowing the heat to disperse into a low state of entropy.

Your computer's random number generator isn't connected to a Geiger counter measuring radioactive decay(source of quantum indeterminacy), hence no entropy. All those garbled numbers in your private and public keys only seem garbled, they are actually an easily cracked pattern. If you do use a Geiger counter, the minix operating system on which all OS install will flag you as a high value target back to CIA headquarters. In this numberphile video, the mathematician was unable to define what randomness is because it doesn't exist. He flails around, using analogous reasoning but of course you can't solve problem you can't even define which is why for example https://en.wikipedia.org/wiki/Theory_of_Evolution redirects to https://en.wikipedia.org/wiki/Evolution: there is no such thing as a theory of evolution because nobody knows what is the Lagrangian that maps polypeptide space into frog space. If pigs had wheels mounted on ball bearings instead of trotters, on what scale of porcine fitness would they be?

"https://en.wikipedia.org/wiki/Evolution...Evolution is change in the heritable characteristics of biological populations over successive generations..."

If Wikipedia had written: Evolution is change in the heritable characteristics of biological populations over successive generations as the Lagrangian maps the quantum entangled DNA super computed calculations from polypeptide dinosaur space into chicken space... then at least the statement would enter the domain of Popper falsifiability but not though escape Agrippian circularity.

android
https://github.com/termux/termux-app#github from https://github.com/dtr2300/nvim

links
Perl encrypted link Software bearssh tigervnc gist.github install uses https://wiki.gentoo.org/wiki/FVWM, which is also used by Anydesk. Anydesk GPL and BSD pays the copyright holders of fvwm lots of money so they don't have to credit them for using their GPL proprietory software and exempts Anydesk from having to share their code modifications of fvwm, while you without lots of money have to share your modifications back. Paying lots of money to be exempted from GPL to the copyright holder is something most GPL proponents don't seem to grasp. MeshNetworking main page documenting the locustworld.com mesh networking technology. http://16s.us/OpenBSD/acls.txt  ssh secure shell from home to work computer http://www.openbsd.org/cgi-bin/man.cgi?query=ssh&sektion=1 command descripts http://16s.us/OpenBSD/ http://www.thegeekstuff.com/2010/12/50-unix-linux-sysadmin-tutorials/ http://www.revsys.com/writings/quicktips/ssh-tunnel.html Ftp socat