Changes: Ssh

Latest revision as of 22:33, 4 February 2024

visually

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."

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 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

#executing these commands from 192.168.1.98 to 188.168.0.100
ssh -R  8653:localhost:8554 pc@188.168.0.100 #open 8653 on all eth interfaces.

#RTSP server and sshd daemon are on the same physical computer.
#For security reasons designate as usersshd@192.168.1.98 as the only pc on the LAN as the ssh server.
#(remote computer from your perspective) and RTSP as 192.168.1.200
#Open up port 8554 RTSP(192.168.1.200) service(https://sasecurity.fandom.com/wiki/Streaming) 
#and bind it to Ethernet third port on 192.168.0.100
ssh -4 -R  8653:192.168.1.200:8554 remote@192.168.0.100
#this implies 192.168.0.100 is reachable TCP from 192.168.1.98
# 192.168.1.200:8554 RTSP session can be opened and closed as you wish, the ssh link remains. 
ssh -4 -R  8653:192.168.1.200:8554 remote@192.168.0.100
#implies 
ssh -4 -R  8653:192.168.1.200:8554 remote@192.168.0.100 -p 22
#From machine 192.168.0.100 Connect mplayer to 8653(port reverse opened from 192.168.1.98)
#Use interface 127.0.0.3 , the others won't work
mplayer  -rtsp-stream-over-tcp -prefer-ipv4  rtsp://127.0.0.1:8653/mystream
#bind remote port 8653 to all Ethernet interfaces. 
ssh -4 -R  8653:192.168.1.200:8554 remote@192.168.0.100 -p 22
#From machine 192.168.0.100 Connect mplayer to 8653(port reverse opened from 192.168.1.98)
mplayer  -rtsp-stream-over-tcp -prefer-ipv4  rtsp://127.0.0.1:8653/mystream
#or connect from eth2 
mplayer  -rtsp-stream-over-tcp -prefer-ipv4  rtsp://127.0.0.2:8653/mystream

# open up a remote port on 192.168.1.76, from 192.168.1.5, allowing 
#192.168.1.76 to cut trough the NAT(192.168.1.5 behind NAT) and get shell access.
#192.168.1.76 must be TCP reachable(no NAT) from 192.168.1.5
ssh -4 -R 7654:localhost:22 jim@192.168.1.76
# pc 192.168.1.5 opens up a reverse port on 192.168.1.76
# Whatever connects to 7654(192.168.1.76) is 
# reversed back to the sshd daemon at 192.168.1.5
ssh -4 jim@localhost -p 7654

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.

# This statement binds to all Ethernet interfaces on the pc that will execute mplayer command:
ssh -4 -L  8653:192.168.1.200:8554 remote@192.168.1.98 
mplayer  -rtsp-stream-over-tcp -prefer-ipv4  rtsp://localhost:8653/mystream
# Binding to a target ip(192.168.1.200) on remote side, stream 
# between sshd server and this ip is decrypted :
ssh -4 -L  8653:192.168.1.200:8554 remote@192.168.1.98
mplayer  -rtsp-stream-over-tcp -prefer-ipv4  rtsp://127.0.0.1:8653/mystream

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}

#Reverse ssh is executed from raspberry(target,server) side to jumpserver. From the target side the port on the 
#jumpserver is reverse forwarded to application(ssh server) on localhost:22 port. from the jumpsrv perspective the #local port 8123(socat connector) is forwarded to ssh server application on port 22(raspberry ) via the TCP listener #port 12500. This allows a ssh client connection to the target pc from the jump server with command
#ssh pi@localhost -p 12500. port 8123 is binded to all interfaces on the #jumpserver(8123) as per man page.
ssh -4 -R  8123:localhost:22  jump@192.168.1.100  "socat -d -d TCP-LISTEN:12500 TCP:8123"
# reuseaddr,fork options allow multiple connections to listener port 12500 and bypasses the GateWayPorts option in sshd_config file
ssh -4 -R  8123:localhost:22  jump@188.88.88.88 "socat -d -d TCP-LISTEN:12500,reuseaddr,fork TCP:8123"
#If a specific interface[bind:port:localhost:22] is required(any number of ethernet ports could be on a pc) then the command is :
ssh -R  8123:localhost:22  jump@192.168.1.100  "socat -d -d TCP-LISTEN:12500 TCP:8123"

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

#ssh attempts to use ip6 before timing out(2min) and then 
#using ip4. Force it to use ip4 with -4 flag
ssh  -4 pi@localhost  -p 12500

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)

#from client pc, forward port 9874(the port from which application ssh client is executed) to the socat TCP listener port 12500.
ssh -4 -f -n -L  9874:localhost:12500  jump@192.168.1.100

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

#from client pc
ssh -4 pi@localhost  -p 9874

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.

ssh rtsp

#If the application is a RTSP server(8554) , then this should work(not tested yet) executing from say pi target(ssh server) (192.168.1.160)
#with 192.168.1.137(RTSP) on same LAN to jump server.
#https://sasecurity.fandom.com/wiki/Streaming#RTSP .
#mplayer connects to the  socat TCP listener port 12500, which bridges to the 8123 connector port, which in turn is
#locally forwarded to the ssh server from which the ssh -R command was called(192.168.1.160). Between 192.168.1.137  #and  192.168.1.160 on the target pc(pi) the data isn't encrypted. The pi ssh server encrypts the data to the jump #server 188.123.1.100, where its ssh server decrypts the data for usage by an application(mplayer) on port 8123(fourth ethernet interface)
ssh -4 -R  8123:192.168.1.137:8554  jump@188.123.1.100  "socat -d -d TCP-LISTEN:12500,reuseaddr,fork  TCP:8123"
#execute mplayer from the jumpserver:
mplayer  -rtsp-stream-over-tcp -prefer-ipv4  rtsp://localhost:12500/mystream
#if RTSP server and ssh server is on same target side pc(pi):
ssh -4 -R  8123:localhost:8554  jump@188.123.1.100  "socat -d -d TCP-LISTEN:12500,reuseaddr,fork  TCP:8123"
#Bind port 8123 on all ethernet interface of jumpserver(the usual command), issued from 192.168.1.160 target rasp pc:
ssh -4 -R  8123:localhost:8554  jump@188.123.1.100  "socat -d -d TCP-LISTEN:12500,reuseaddr,fork  TCP:8123"
#from jumpserver ip 188.123.1.100 issue command:
mplayer  -rtsp-stream-over-tcp -prefer-ipv4  rtsp://localhost:12500/mystream
#reuseaddr and fork flags allows any number of other applications to receive the same RTSP stream on port 12500.

#Executing mplayer from the client side(behind a NAT) to reach the RTSP server on the target side(pi) hosting
#both the SSH server and RTSP server on the pi. Port 8653 is any arbitrary port chosen for ssh -L forwarding.
ssh -4 -f -n -L 8653:localhost:12500 jump@188.123.1.100 &
mplayer  -rtsp-stream-over-tcp -prefer-ipv4  rtsp://localhost:8653/mystream

#Executing mplayer from the client side(behind a NAT) to reach the RTSP server on the target side(pi) hosting
#both the SSH server and RTSP server on the pi. Port 8653 is any arbitrary port chosen for ssh -L forwarding.
#Connecting additional applications other than mplayer needs a socat tcp listen /connector.
#the connector is port forwarded with ssh -L
socat TCP-LISTEN:8777,reuseaddr,fork TCP:8653 &
ssh -4 -f -n -L 8653:localhost:12500 jump@188.123.1.100 &
mplayer  -rtsp-stream-over-tcp -prefer-ipv4  rtsp://localhost:8777/mystream

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.

#from client pc ip address: 192.168.1.100 issue command
ssh -L  2221:localhost:3122   jim@188.88.88.88
# which implies the localhost of 192.168.1.100:2221 if there is only one ip address on the pc
# from which the ssh command is issued.
ssh -L  localhost:2221:localhost:3122   jim@188.88.88.88
ssh -L  127.0.0.1:2221:localhost:3122   jim@188.88.88.88

http://zarb.org/~gc/html/udp-in-ssh-tunneling.html udp over ssh. See Gprs and wifi streaming#rtsp
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:<my.ip>: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<mitm.ip.address>:9090:localhost:9999 localhost

udp over ssh

ffmpeg stream videofile via UDP over ssh

superuser 53103

https://superuser.com/questions/53103/udp-traffic-through-ssh-tunnel?rq=1 links to https://securesocketfunneling.github.io/ssf/#home
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:

Server side: socat tcp4-listen:5353,reuseaddr,fork UDP:nameserver:53
Client side: socat -T15 udp4-recvfrom:53,reuseaddr,fork tcp:localhost:5353

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.

And not at all with parallel requests. – Peter V. Mørch Apr 20 '20 ..

sshuttel ,proxychains

dergachev

https://pastebin.com/u4VPGsqE Append only new text from clipboard to file in shell, vlang, goland and c in linux and windows.
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.

ngrok

https://news.ycombinator.com/item?id=35119261 for https://github.com/pgrok/pgrok , alternative to ngrok

https://github.com/antoniomika/sish
https://github.com/pgrok/pgrok
https://github.com/localtunnel/localtunnel
https://github.com/anderspitman/awesome-tunneling list of ngrok alternatives
https://www.reddit.com/r/webdev/comments/ca634r/alternatives_to_serveo_for_localhost_tunneling/
https://news.ycombinator.com/item?id=35119261 Has anyone tried this for a free ngrok alternative that works with HTTPS, doesn't require setting up a server and has no rate limit within reason? https://developers.cloudflare.com/pages/how-to/preview-with-... Based on the page it looks like you can install Cloudflare's CLI and then run `cloudflared tunnel --url http://localhost:3000`, and you'll get back a URL to visit such as https://seasonal-deck-organisms-sf.trycloudflare.com. Looks like it supports being able to associate it with a custom domain too so you can have repeatable URLs.
https://alternativeto.net/software/serveo/
http://localhost.run/
https://tailscale.com/blog/introducing-tailscale-funnel/
https://zrok.io/
https://burrow.io/
https://portmap.io/
https://vercel.com/

tor

https://news.ycombinator.com/item?id=29929399 , https://golb.hplar.ch/2019/01/expose-server-tor.html Expose server behind NAT with Tor and https://golb.hplar.ch/2019/01/expose-server-vpn.html links to https://www.hackerfactor.com/blog/index.php?/categories/19-Tor
Is there still an onion service config option to use 3 hops instead of 6? I can't find the documentation on the current tor project website. found it in the manpage: HiddenServiceSingleHopMode
Disable the SocksPort, then set two options to really convince tor that you know what you're doing, then configure your onion service as usual. Basically use a CIA Tor server for free, cutting down the hops takes away the anonymity but brings the latency down. See https://justpaste.it/c505u code block explanation:

SocksPort 0
HiddenServiceSingleHopMode 1
HiddenServiceNonAnonymousMode 1
HiddenServiceDir /var/lib/tor/ssh_service
HiddenServicePort 22
HiddenServiceDir /var/lib/tor/http_service
HiddenServicePort 80

why disable SocksPort?
By default it is six hops for complete circuit between client and hidden service. Three hops from client to rendezvous point, then three hops from rendezvous point to the hidden service. If you go below that you might as well host on the public internet. If the main goal is not anonymity this should not be a problem?

https://tailscale.com/blog/how-nat-traversal-works/ https://www.zerotier.com/ is one example, Cloudflare Argo is another, tinc is another, Yggdrasil is another, Tailscale is another. Some VPN providers (like Mullvad) will happily forward ports to you from their VPN servers. As the author linked to at the very beginning of their post, you could even set up something similar by hand with a VPS (free-tier would suffice) and off-the-shelf VPN software like Wireguard. See i2p
https://news.ycombinator.com/item?id=30156551, https://yggdrasil-network.github.io/, https://www.youtube.com/watch?v=GtbsfI8ZG0U I started using yggdrasil yesterday. The ability to get a static IPv6 address on a meshnet, with encrypted traffic by default, and the option to only accept inbound connections from public keys I trust is incredibly cool. Just like that I can access any of my devices that run ygg from anywhere using standard tools like git or ssh (or git-annex). It makes it really easy to network my devices together without having to screw around with split tunneling a wireguard server and create a DIY set of services to, for example, remotely manage my devices or sync things from one to the other, and that's just for starters. Feels like the Unix philosophy actually being useful for once.