Могу ли я создать SSH для туннелирования HTTP через сервер, как если бы он был прокси?

Да, это возможно.

Бежать ssh -D port user@host и настройте своего клиента на использование вашего ящика в качестве SOCKS-прокси.

Если вам нужен именно HTTP-прокси, вы можете использовать Proxychains и направить его через предыдущие SOCKS.

sshuttle работает как VPN, но через SSH.

Прозрачный прокси-сервер, который работает как VPN для бедного человека. Нападающие над ssh. Не требует администратора. Работает с Linux и MacOS. Поддерживает DNS-туннелирование.

https://github.com/sshuttle/sshuttle

Замазка делает это очень хорошо тоже.

Под SSH, goto Tunnels. Внизу поместите 8080 в порт, а для пункта назначения оставьте его черным и выберите переключатель "Динамический". Вот и все, что вам нужно сделать, теперь подключиться к серверу с помощью Putty.

После подключения на локальном хосте у вас работает прокси-сервер с портом 8080, который будет передавать все запросы через ваш сервер.

Теперь используйте веб-браузер и настройте прокси, установив host=localhost и port=8080, и убедитесь, что вы выбрали SOCKS прокси. Я делаю это все время, поэтому, если вы используете Firefox, обязательно установите плагин FoxyProxy, поскольку он делает включение / отключение прокси одним щелчком мыши.

Внимание: имейте в виду, что по умолчанию ваши DNS-запросы не передаются через прокси. Таким образом, веб-сайт, который вы посещаете через прокси-сервер, все равно будет зарегистрирован (если они регистрируют этот материал). Вы также можете настроить Firefox на DNS-запросы прокси, он просто не делает этого по умолчанию.

Чтобы разрешить прокси-серверу запускать компьютер и разрешить другим клиентам подключаться к вам, потребуется опция -g. Например, вы должны запустить это на сервере с именем foo:

ssh -g -ND 9191 root@remotehost

Затем вы можете установить прокси в браузере клиента, чтобы использовать сервер foo и порт 9191 для SOCKS прокси. Клиенты будут отправлять свои запросы слишком foo, которые, в свою очередь, перенаправят запрос через ssh на удаленный хост. Так что в интернете будет похоже, что они используют remotehost.

Если вы также хотите пересылать DNS-запросы с помощью firefox, отредактируйте about:config в firefox и установите для network.proxy.socks_remote_dns значение true.

Простое руководство по туннелированию HTTP с помощью SSH

На первый взгляд я не понял основные ответы, поэтому поискал учебник. Вот что я узнал и чего достиг.

Настраивать

Вы находитесь на своей машине, то есть на любом компьютере, на котором вы можете вводить команды. Вы хотите подключиться к машине с именем , туннелируя при этом трафик через машину с именем . Вы можете подключиться по ssh к . недоступен с вашего , но доступен с .

Шаги

1. На вашем компьютере выполните следующую команду:
2. ssh <local-port>:<remotehost>:<remote-port> <username-on-proxy>@<proxyhost>
   Где
   • <local-port>это свободный порт на вашем , например 8000;
   • <remotehost>это доменное имя или IP-адрес машины. Обратите внимание, что это доменное имя или IP-адрес могут быть бессмысленными или недоступными для вашегоclient. Важная часть заключается в том, что это имеет смысл и доступно для вашего файла .*.<remote-port>— это порт, к которому вы хотите подключиться, например 80 для http или 443 для https.*.<username-on-proxy>@<proxyhost>это способ доступа кproxyhostс ssh и вашей учетной записью на этом компьютере.
3. На этом этапе вы можете перейти кlocalhost:<local-port>и просматривать/использоватьremotehostресурсы.

Вы можете использовать SSHUTTLE, вот учебник о том, как его использовать,

https://etherarp.net/sshuttle-a-vpn-for-the-lazy/

вот учебник, как настроить его для работы в качестве службы,

https://medium.com/@mike.reider/using-sshuttle-as-a-service-bec2684a65fe

У меня возникли некоторые трудности при попытке переадресации сокетов. Особенно в ситуации, когда nginx использует сокет для обслуживания веб-сайта на базе Flask: вот мой опыт:

Переадресацию сокетов можно записать так:

      ssh -R /run/temp1.sock:/run/temp2.sock somehost -N

temp1.sock относится к сокету на удаленном сайте.ssh не принимает использование существующего удаленного сокета, но должен его создать. Он создается с разрешением 600, поэтому после создания необходимо сделать его доступным для nginx, добавив привилегии w/r пользователю www-data.