Проксификация программ на Linux

Решение подходит в т.ч. и для windows приложений запускаемых через wine
Ставим пакет dante-client (он даст нам утилиту socksify)

sudo apt-get install dante-client

Настраиваем (в Ubuntu настройки тут – /etc/dante.conf)
В конце файла:

route {
   from: 0.0.0.0/0 to: 0.0.0.0/0 via: 192.168.1.25 port = 3128
   proxyprotocol: http_v1.0
}

Где 192.168.1.25 – адрес http прокси, 3128 – порт прокси.
Запуск нужного приложения делается следующей командой:

socksify <имя_приложения>

Для Wine вобщем-то то же самое, но дописываем еще и имя запускаемой в wine программы, например для World of Warcraft:

socksify wine icq.exe

SSH авторизация по ключу

mik@m1k:~$ ssh-keygen -t dsa -b 1024 -f /home/user/.ssh/id_dsa

-t dsa - тип ключа. Есть rsa и dsa. Dsa это для второй версии ssh, которая сейчас везде по умолчанию. Rsa - первая версия ssh.
-b 1024 (optional) длина ключа
-f /home/user/.ssh/id_dsa - (optional) каталог и имя файла где будет сохранен ключ id_dsa и его публичный ключ id_dsa.pub

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

В итоге получаем два файла id_dsa и id_dsa.pub. PUB ключ - это публичный, а id_dsa секретный.
 Переносим файл id_dsa.pub на сервер, к которому мы будем подключаться. Помещаем в директорию /home/user/.ssh/ того пользователя под которым мы будем соединяться по ssh.

Делаем это либо в ручную копированием и вставкой ключа, либо следующей командой:

ssh-copy-id -i .ssh/id_rsa.pub root@212.90.160.1

Теперь надо изменить конфигурацию ssh сервера (файл /etc/ssh/sshd_config) той машины куда мы перенесли публичный ключ.
Раскомментируем строки по которым мы разрешим использовать ключи.

PubkeyAuthentication yes
AuthorizedKeysFile      .ssh/authorized_keys

Переименовываем ключ id_dsa.pub в файл authorized_keys, назначаем файлу правами 600 и оставляем файл в папке /home/user/.ssh.

Пробуем соединиться с сервером:

В случае если имя ключа имеет название по умолчанию (id_dsa), ключ можно не указывать.

 ssh user@212.90.160.1

Если же при генерации ключа было указано имя отличное от id_dsa, например id_dsa2, то нужно явно указать имя ключа.

ssh -i /home/user/.ssh/id_dsa2 user@212.90.160.1

Выставив в конфигурации sshd PermitRootLogin no мы запретим авторизацию по паролю для рута, а указав UsePAM no мы сможем подключиться к серверу только по ключу.

Туннелирование порта через SSH

Например, работаем на виртуальном хостинге, там Apache, MySQL. Хотим подключить визуальный клиент администрирования MySQL. Много есть случаев, когда было бы удобно коннектится на удаленном компьютере к его локальным портам.
Организация туннеля

Давайте попробуем подключить клиент администрирования MySQL на удаленном компьютере.

Естественно считаем, что вход по SSH по ключу уже настроен.

Тогда поднять туннель не просто, а очень просто. На своем локальном компьютере выполняем команду:

ssh -f username@remote_host -L 127.0.0.1:4306:127.0.0.1:3306 -N

Где:

-f    Говорит ssh уйти в бэкграунд
username    Имя пользователя на удаленном компьютере
remote_host    Имя или IP адрес удаленного хоста
-L 127.0.0.1:4306:127.0.0.1:3306    Пробросить тоннель с локального порта 4306 на удаленный порт 3306
-N    Не выполнять команду на удаленном хосте.
Подключение клиента

Теперь можно подключать клиента. Запускаем mysql-admin и конфигурируем его следующим образом:
Server Hostname:    127.0.0.1
Port:    4306

Пользователь и пароль - ну ясно, так как у нас сконфигурировано.

Примечание: Мы перенаправили с нашего хоста порт 4306, для того, чтобы в случае, если у нас на локальном хосте тоже работает MySQL, не мешать ему.

http://blog.swlogic.eu/2011/07/16/tunnelirovanie-porta-cherez-ssh/

One authentication with multiple ssh terminals

The concept is very simple — rather than each new SSH connection to a particular server opening up a new TCP connection, you instead multiplex all of your SSH connections down one TCP connection. The authentication only happens once, when the TCP connection is opened, and thereafter all your extra SSH sessions are sent down that connection.

Host *

ControlMaster auto

ControlPath ~/.ssh/cm_socket/%r@%h:%p

Then mkdir ~/.ssh/cm_socket, and you’re away. Any time a connection to a remote server exists, it’ll be used as the master for any other connections.

All of your SSH sessions are multiplexed down a single TCP connection initiated by the first SSH session, that first session must stay alive until all of the other sessions are complete. This problem will manifest itself as an apparent “hang” when you log out of the remote session that is acting as the master — instead of getting your local prompt back, SSH will just sit there. If you Ctrl-C or otherwise kill this session, all of the other sessions you’ve got setup to that server will drop, so don’t do that. Instead, when you logout of all the other sessions, the master will then return to the local prompt.

SSH socks proxy

ssh -CND 1080  login@server

• 1080 - порт на локальном компе, через который мы и будем выходить в инет
• C - нужна здесь для сжатия данных
• N - для того чтобы не было записи в wtmp
• D - благодаря этому ключу всё и работает.

В браузере, где вбивается socks proxy написать locаlhost port 1080, ну и поставить галочку напротив socks5

Еще говорится, что в конфиге sshd.conf должна быть такая строчка:

AllowTcpForwarding yes

http://ruunix.ru/496-xitrosti-ssh.html