id: Гость   вход   регистрация
текущее время 20:34 29/04/2024
создать
просмотр
ссылки

есть ли windows решения VPN over SSh не на уровне прокси а на уровне ethernet интерфейса?


т.е. чтобы создавался сетевой интерфейс как при использовании OpenVpn трафик шел через него, заворачивался на ssh(весь включая udp и dns запросы).


желательно фри/опенсорс.


 
На страницу: 1, 2, 3 След.
Комментарии
— Гость (19/03/2012 01:28)   <#>

Лучше по ключам сделайте. Оно же просто делается, куча манулов по интернету, погладьте их.


В правилах iptables/pf разрешите пакеты нужному user'у только с IP-адреса/интерфейса, ассоциированного с данным туннелем. Полностью запретите IPv6 и ICMP-трафик с вашей машины.
— Гость (19/03/2012 01:35)   <#>

Заодно в authorized_files можете прописать разрешение авторизовываться только с определённого IP, обсуждалось в /comment36073 (конфиг pf там не вполне безопасен, т.к. разрешает ICMP-пакеты).
— Гость (19/03/2012 13:10)   <#>
Есть непонимание, каким образом генерируется и передается открытый ключ с локальной машины на сервер. Серверный я получаю...
— Гость (19/03/2012 17:24)   <#>

Теоретически надо бы дать его админу, чтобы он положил его в ~/.ssh/authorized_keys. За неимением доступа к админу обычно приходится довольствоваться тем, что 1ый раз входите по паролю, затем загружаете сами туда свой открытый ключ (sftp или scp), а следующие разы авторизуетесь только по ключу.
— Гость (19/03/2012 17:34)   <#>

$ ssh-keygen -C "комментарий, чтобы знать, что за ключ" -f ~/.ssh/NAME.ssh -b 2048 -v -t dsa
В качестве NAME удобно взять IP-адрес или DNS-имя сервера. В каталоге ~/.ssh появятся два файла: ~/.ssh/NAME.ssh — ваш приватный ключ и /.ssh/NAME.ssh.pub — ваш публичный. На сервере и в домашней директории на клиенте надо проследить за тем, чтобы у других пользователей не было прав доступа к ~/.ssh: сделать
$ find ~/.ssh -exec chmod go-rwx {} \;
иначе авторизация по ключам не заработает.
— Гость (24/03/2012 19:34, исправлен 24/03/2012 20:08)   <#>

/comment51316


а матерые линуксятнике давая ссылки даже не утруждают себя проверкой их работоспособности
по иронии судьбы http://unix-like.info/ сейчас варезняк с софтом под винду :D

— Гость (29/03/2012 23:49)   <#>
Наверное я действительно непонимаю нечто основопологающее. Каким образом осуществляется шифрование если авторизация проходит только по логин:пароль? Ведь сервер в данном случае не имеет ключа клиента?
— SATtva (31/03/2012 09:28)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
Ключи и пароли — это средство аутентификации. Шифрование канала в любом случае производится сеансовым ключом.
— Гость (01/04/2012 01:52)   <#>
Да, я так и понял. То есть при аутентификациии по логин:пароль на локальную машину приходит ключ с сервера. Кстати при реконнектах он не меняется(это сеансовый?). Запросы шифруются этим ключем, передаются серверу. Каким образом шифруется ответ?
— SATtva (01/04/2012 09:11)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
Стороны совместно вырабатывают ключ по Диффи-Хэллману при установлении соединения, на этом же этапе приосходит аутентификация сервера, см. RFC 4253. Ключ не только уникален для каждого сеанса, но и периодически пересогласовывается в рамках одного сеанса.
— Гость (01/04/2012 17:57)   <#>
кстати знатоки ssh – ведутся ли логи соединений через него?
— SATtva (01/04/2012 22:06)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
Это уж как админу сервера заблагорассудится. :) Обычно факт логина фиксируется.
— Гость (02/04/2012 02:04)   <#>
Запросы шифруются этим ключем, передаются серверу. Каким образом шифруется ответ?
На тему SSH недавно уже был топик :) На уровне PoC (а не в SSH) подобные протоколы могли бы работать подобно PGP:
  1. Сервер высылает клиенту ключ
  2. Клиент проверяет его отпечаток
  3. Клиент шифрует свой публичный ключ публичным ключом сервера и передаёт ему
  4. Сервер и клиент имеют ключи друг друга. Каждый может шифровать сообщения и посылать один другому.
Для отсылки сообщения Алиса генерирует случайный пароль, шифрует им передаваемое сообщение, а сам пароль шифрует ключом Боба. Оба шифртекста (как шифрованный ключом пароль, так и сами данные, шифрованные этим паролем) пакуются в один PGP-пакет и посылаются в сеть. Ответ от Боба Алисе посылается аналогично. Так работает [вроде бы], PGP-шифрование в XMPP.

знатоки ssh – ведутся ли логи соединений через него?
По умолчанию? Наверное, зависит от ОС. В /var/log/authlog бывает информация типа следующей:
Nov 20 22:32:14  sshd[991]: SSH: Server;Ltype: Version;Remote: IP-52671;Protocol: 2.0;Client: OpenSSH-VERSION OS-VERSION
Nov 20 22:32:15  sshd[991]: Accepted publickey for USER from IP port 52671 ssh2
Nov 20 22:32:15  sshd[2488]: subsystem request for sftp
Nov 20 22:32:33  sshd[2488]: Received disconnect from IP: 11: disconnected by user
...
Jan 22 02:25:13  sshd[2427]: error: connect_to IPv6-ADDRESS port 80: No route to host
Ну и на last смотрите. Детализации всех сетевых соединений, как видите, нет, но, например, ошибка соединения с каким-то адресом по тунелю (ssh -D порт) осела в логах. На публичных системах, если админ не враг сам себе, он настраивает систему логов, и тут уже кто во что горазд... Следует отметить, что
  1. При логине по ssh клиент светит версию своего клиента и ОС.
  2. При пользовании опцией -N при открытии тунелей записи в last не создаётся (зато создаётся в /var/log/authlog, хотя за все системы не поручусь).
— unknown (02/04/2012 09:47)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
На уровне PoC (а не в SSH) подобные протоколы могли бы работать подобно PGP:

Такой протокол когда-то существовал, не помню для OpenSSH или OpenVPN. Он устаревший, по причине того, что нет смысла переносить изначально оффлайновые протоколы в онлайн-сессию. Реальный протокол основан на согласовании эфемерного ключа Диффи-Хеллмана со сверкой подписи отпечатков и выведении из него симметричного ключа сессии. Это даёт преимущество в том, что так в онлайн-протоколах естественным образом появляется свойство "наперёд заданной секретности" (Perfect Forward Security) — PFS. Будущие потенциальные компрометации ключей (MITM, взлом серверов, похищение ключей, но естественно не полный криптоаналитический взлом) не позволяют расшифровать предыдущие нескомпрометированые сеансы.
— Гость (02/04/2012 17:56)   <#>
Есть два способа построения vpn через ssh:

1. ppp через ssh. Если есть сервер pppd под windows, то наверное можно сделать по аналогии с linux. Рецептов в Интрернете множество, например http://citforum.ru/operating_systems/linux/linux_vpn/

2. Построение туннеля средствами одного ssh с помощью опции -w. Для этого нужно установить драйвер виртуального интерфейса tun, под windows он вроде есть.

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

Ещё вариант – установить cygwin, тогда vpn наверное строится в точности как в linux.
На страницу: 1, 2, 3 След.
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3