summaryrefslogtreecommitdiff
path: root/site
diff options
context:
space:
mode:
Diffstat (limited to 'site')
-rwxr-xr-xsite/entries/librex.html2
-rwxr-xr-xsite/entries/ssh_forwarding.html52
2 files changed, 26 insertions, 28 deletions
diff --git a/site/entries/librex.html b/site/entries/librex.html
index c78c2cd..b4078b5 100755
--- a/site/entries/librex.html
+++ b/site/entries/librex.html
@@ -4,6 +4,6 @@
My instance: [search.davidovski.xyz](https://search.davidovski.xyz/)
-For a while now I have been using [SearX](https://github.com/searx/searx) as my search engine, a meta search engine that cumulates search results from multiple different sites. While this is a great idea in theory, making the best of all search engines through one *privacy respecting* interface, in reality it ends up meaning that search results are quite slow. Couple this with the fact that most SearX instances are hosted by volunteers, and often have downtime, I was in the situation where I was hopping between various instances to try and find ones that worked. I always wanted to self host one myself, but the whole system seemed very bloated and complicated, and honestly I just couldn't be bothered to mess around with it.
+For a while now I have been using [SearX](https://github.com/searx/searx) as my search engine, a meta search engine that cumulates search results from multiple different sites. While this is a great idea in theory, making the best of all search engines through one *privacy respecting* interface, in reality it ends up meaning that search results are quite slow. Couple this with the fact that most SearX instances are hosted by volunteers, and often have downtime, I was in the situation where I was hopping between various instances to try and find ones that worked. I always wanted to self host one myself, but the whole system seemed very bloated and complicated, and honestly I just couldn't be bothered to mess around with it.
That's where [LibreX](https://github.com/hnhx/librex) comes in, a very small and simple meta search engine. Its still in development, but currently it has just enough functionality to actually be somewhat useful. Currently it only really supports google searches, but it still is a good layer for privacy, since all of your queries are anonymised, with google only seeing that they came from LibreX. I am curious to see how well it will handle larger amounts of search queries and if Google will limit them or something. If you want to support development, feel free to use it, find bugs and request features: [View the github repo](https://github.com/hnhx/librex)
diff --git a/site/entries/ssh_forwarding.html b/site/entries/ssh_forwarding.html
index d068f54..6319445 100755
--- a/site/entries/ssh_forwarding.html
+++ b/site/entries/ssh_forwarding.html
@@ -2,32 +2,30 @@
# Permanent SSH Forwarding (Tutorial)
-Take this situation: you have a cheap (or even free), low-powered remote server and a considerably better homeserver with more storage and power. For certain services that require more power, you'd obviously want to run them on that homeserver.
+Take this situation: you have a cheap (or even free), low-powered remote server and a considerably better homeserver with more storage and power. For certain services that require more power, you'd obviously want to run them on that homeserver.
-However, what if you don't want to, *or can't*, directly open ports onto your home network, or you if you simply want to keep all of your site to one IP? This is where SSH port forwarding comes in handy: using ssh to forward the open port from a service from your local server to the remote one, where it can be exposed to the rest of the internet.
+However, what if you don't want to, *or can't*, directly open ports onto your home network, or you if you simply want to keep all of your site to one IP? This is where SSH port forwarding comes in handy: using ssh to forward the open port from a service from your local server to the remote one, where it can be exposed to the rest of the internet.
## SSH Remote Port Forwarding
SSH remote port forwarding is built right into ssh itself, and is quite simple:
-```
-ssh -R 5505:localhost:4404 user@remote.host
-```
+ ssh -R 5505:localhost:4404 user@remote.host
When this command is run on the local server, it will:
+ create an ssh connection to the remote server, as per usual
-+ open the port 5505 on the remote server,
-+ all traffic on this port will be forwarded to port 4404 on the local server.
++ open the port 5505 on the remote server,
++ all traffic on this port will be forwarded to port 4404 on the local server.
This command by itself is already everything you'd need to forward most ports easily to your remote server, of course, remember to open the port on your remote server's firewall, if applicable.
-However to ensure that that port is exposed properly on the remote server, you'd want to make sure that it is listening to all external traffic.
+However to ensure that that port is exposed properly on the remote server, you'd want to make sure that it is listening to all external traffic.
You can fix this by setting `GatewayPorts yes` in `/etc/ssh/sshd_config` on the remote server. (don't forget to restart sshd after editing the config)
## Persistent ssh forwarding
-The above is all well and good, but you'd need to keep an interactive ssh connection up at all times, so the above isn't the most ideal solution.
+The above is all well and good, but you'd need to keep an interactive ssh connection up at all times, so the above isn't the most ideal solution.
To get around this, you can create a service to run on the local server to forward requested ports from the remote server.
@@ -39,14 +37,14 @@ Then, create a script for your ssh port forwarding. I placed mine directly in th
Here is my example of a script that you could use:
- #!/bin/sh
+ #!/bin/sh
+
+ PORTS="8080 25565"
+ DEST="bridge@remote.host"
+ SSH_PORT="22"
+ IDENTITY_FILE="~/.ssh"
- PORTS="8080 25565"
- DEST="bridge@remote.host"
- SSH_PORT="22"
- IDENTITY_FILE="~/.ssh"
-
- /usr/bin/ssh -nNT $(echo $PORTS | awk -v host=$LOCALHOST '{for (i = 1; i <= NF; i++){ printf "-R %d:%s:%d ",$i,host,$i}}') -p $SSH_PORT -i $IDENTITY_FILE $DEST
+ /usr/bin/ssh -nNT $(echo $PORTS | awk -v host=$LOCALHOST '{for (i = 1; i <= NF; i++){ printf "-R %d:%s:%d ",$i,host,$i}}') -p $SSH_PORT -i $IDENTITY_FILE $DEST
Next you'd want to run this script as a service. Check your distro's service system how to do this if you have any trouble.
@@ -56,17 +54,17 @@ Say that the script you made was `/home/bridge/tunnel.sh`, you should create a u
To do this create the following file in `/home/bridge/.config/systemd/user/tunnel.service`:
- [Unit]
- Description=SSH tunnel
-
- [Service]
- ExecStart=/home/bridge/tunnel.sh
- RestartSec=5
- Restart=always
- KillMode=mixed
+ [Unit]
+ Description=SSH tunnel
+
+ [Service]
+ ExecStart=/home/bridge/tunnel.sh
+ RestartSec=5
+ Restart=always
+ KillMode=mixed
- [Install]
- WantedBy=default.target
+ [Install]
+ WantedBy=default.target
Then enable and start the service with: `systemd --user enable tunnel.service` and `system --user start tunnel.service`. Ensure that it is running with `systemd --user status tunnel`
@@ -82,7 +80,7 @@ Say you forwarded traffic from port 8080 on remote to port 80 on local, you coul
Here is an example of this in practice, forwarding port 80 and 443, by forwarding ports 8080 and 8443:
- /usr/bin/ssh -nT -R 8443:localhost:443 -R 8080:localhost:80 -i $IDENTITY_FILE -p $SSH_PORT $DEST "(sudo socat TCP-LISTEN:80,fork TCP:localhost:8080) & sudo socat TCP-LISTEN:443,fork TCP:localhost:8443"
+ /usr/bin/ssh -nT -R 8443:localhost:443 -R 8080:localhost:80 -i $IDENTITY_FILE -p $SSH_PORT $DEST "(sudo socat TCP-LISTEN:80,fork TCP:localhost:8080) & sudo socat TCP-LISTEN:443,fork TCP:localhost:8443"
However this command assumes that the remote user has access to sudo with **NO PASSWORD**. Alternatively you could create a similar service (this time as a system service) on the remote server running the socat commands.