Как правильно настроить туннель ssh

Предположим, у меня есть компьютер в моей домашней сети, на котором запущены серверы приложений Ubuntu и Glassfish. Я отлаживаю мое веб-приложение на нем с помощью WiFi. Следующим шагом будет загрузка некоторых конфиденциальных данных. Я беспокоюсь о безопасности WiFi. Я не хочу чрезмерно усложнять эту настройку и не потерять удобство своего WiFi. Итак, я решил подключить слушателя Glassfish к :: 1 и перенаправить серверный порт 8080 на мой ноутбук с помощью ssh-туннеля.

wget localhost:8080/ работает как ожидалось, загружая root index.html

Удаленный доступ к порту 8080 моего сервера не работает - как и ожидалось.

ssh -L 8080:homeserver:8080 minorthreat@homeserver - channel 2: open failed: connect failed: Connection refused

не работает. Я не знаю почему.

UPD:

Я получаю ssh-соединение с удаленным сервером, поэтому учетные данные в порядке, я полагаю. Я не вижу причин для размещения -vvv-листинга, но я все равно вхожу в это дело только для случая. Я заметил, что ssh не может зарегистрировать known_hosts по какой-то причине, но это другая проблема с более низким приоритетом. Я сделаю это, используя cert-based auth в ближайшем будущем. Этот туннель работал, когда слушатель Glassfish был связан с 0.0.0.0. Увы, это не нормально, я хочу запретить любое подключение к серверу, кроме тех, что поступают из туннеля ssh (мои подключения с ноутбука). Проблема заключается в том, что он не перенаправляет соединение laptop [localhost interface]: 8080-> homeserver [:: 1 interface]: 8080 OpenSSH_5.4p1, OpenSSL 1.0.0 29 Mar 2010 debug1: Reading configuration data /etc/ssh/ssh_config debug2: ssh_connect: needpriv 0 debug1: Connecting to homeserver [192.168.1.101] port 22. debug1: Connection established. Could not create directory '/home/mt/.ssh'. debug1: identity file /home/mt/.ssh/id_rsa type -1 debug1: identity file /home/mt/.ssh/id_rsa-cert type -1 debug1: identity file /home/mt/.ssh/id_dsa type -1 debug1: identity file /home/mt/.ssh/id_dsa-cert type -1 debug1: Remote protocol version 2.0, remote software version OpenSSH_7.2p2 Ubuntu-4ubuntu2.2 debug1: match: OpenSSH_7.2p2 Ubuntu-4ubuntu2.2 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_5.4 debug2: fd 3 setting O_NONBLOCK debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received /..... skip encryption details to fit char limits ........./ debug2: kex_parse_kexinit: none,zlib@openssh.com debug2: kex_parse_kexinit: none,zlib@openssh.com debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: mac_setup: found hmac-sha1 debug1: kex: server->client aes128-ctr hmac-sha1 none debug2: mac_setup: found hmac-sha1 debug1: kex: client->server aes128-ctr hmac-sha1 none debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<2048<8192) sent debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP debug2: dh_gen_key: priv key bits set: 181/320 debug2: bits set: 1066/2048 debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY debug3: check_host_in_hostfile: host homeserver filename /home/mt/.ssh/known_hosts debug3: check_host_in_hostfile: host homeserver filename /home/mt/.ssh/known_hosts debug3: check_host_in_hostfile: host homeserver filename /etc/ssh/ssh_known_hosts debug3: check_host_in_hostfile: host homeserver filename /etc/ssh/ssh_known_hosts debug3: check_host_in_hostfile: host 192.168.1.101 filename /home/mt/.ssh/known_hosts debug3: check_host_in_hostfile: host 192.168.1.101 filename /home/mt/.ssh/known_hosts debug3: check_host_in_hostfile: host 192.168.1.101 filename /etc/ssh/ssh_known_hosts debug3: check_host_in_hostfile: host 192.168.1.101 filename /etc/ssh/ssh_known_hosts debug3: check_host_in_hostfile: host homeserver filename /home/mt/.ssh/known_hosts debug3: check_host_in_hostfile: host homeserver filename /etc/ssh/ssh_known_hosts debug2: no key of type 0 for host homeserver debug3: check_host_in_hostfile: host homeserver filename /home/mt/.ssh/known_hosts2 debug3: check_host_in_hostfile: host homeserver filename /etc/ssh/ssh_known_hosts2 debug3: check_host_in_hostfile: host homeserver filename /home/mt/.ssh/known_hosts debug3: check_host_in_hostfile: host homeserver filename /etc/ssh/ssh_known_hosts debug2: no key of type 2 for host homeserver The authenticity of host 'homeserver (192.168.1.101)' can't be established. RSA key fingerprint is 45:84:58:01:80:95:bb:71:0e:a3:66:2f:e6:cd:e9:34. Are you sure you want to continue connecting (yes/no)? yes Failed to add the host to the list of known hosts (/home/mt/.ssh/known_hosts). debug2: bits set: 1010/2048 debug1: ssh_rsa_verify: signature correct debug2: kex_derive_keys debug2: set_newkeys: mode 1 debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug2: set_newkeys: mode 0 debug1: SSH2_MSG_NEWKEYS received debug1: Roaming not allowed by server debug1: SSH2_MSG_SERVICE_REQUEST sent debug2: service_accept: ssh-userauth debug1: SSH2_MSG_SERVICE_ACCEPT received debug2: key: /home/mt/.ssh/id_rsa (0x0) debug2: key: /home/mt/.ssh/id_dsa (0x0) debug1: Authentications that can continue: publickey,password debug3: start over, passed a different list publickey,password debug3: preferred publickey,keyboard-interactive,password debug3: authmethod_lookup publickey debug3: remaining preferred: keyboard-interactive,password debug3: authmethod_is_enabled publickey debug1: Next authentication method: publickey debug1: Trying private key: /home/mt/.ssh/id_rsa debug3: no such identity: /home/mt/.ssh/id_rsa debug1: Trying private key: /home/mt/.ssh/id_dsa debug3: no such identity: /home/mt/.ssh/id_dsa debug2: we did not send a packet, disable method debug3: authmethod_lookup password debug3: remaining preferred: ,password debug3: authmethod_is_enabled password debug1: Next authentication method: password minorthreat@homeserver's password: debug3: packet_send2: adding 48 (len 63 padlen 17 extra_pad 64) debug2: we sent a password packet, wait for reply debug1: Authentication succeeded (password). debug1: Local connections to localhost:8080 forwarded to remote address homeserver:8080 debug3: channel_setup_fwd_listener: type 2 wildcard 0 addr NULL debug1: Local forwarding listening on 127.0.0.1 port 8080. debug2: fd 4 setting O_NONBLOCK debug3: fd 4 is O_NONBLOCK debug1: channel 0: new [port listener] debug1: channel 1: new [client-session] debug3: ssh_session2_open: channel_new: 1 debug2: channel 1: send open debug1: Requesting no-more-sessions@openssh.com debug1: Entering interactive session. debug1: client_input_global_request: rtype hostkeys-00@openssh.com want_reply 0 debug2: callback start debug2: client_session2_setup: id 1 debug2: channel 1: request pty-req confirm 1 debug2: channel 1: request shell confirm 1 debug2: fd 3 setting TCP_NODELAY debug2: callback done debug2: channel 1: open confirm rwindow 0 rmax 32768 debug2: channel_input_status_confirm: type 99 id 1 debug2: PTY allocation request accepted on channel 1 debug2: channel 1: rcvd adjust 2097152 debug2: channel_input_status_confirm: type 99 id 1 debug2: shell request accepted on channel 1 Welcome to Ubuntu 16.04.3 LTS (GNU/Linux 4.4.0-91-generic x86_64)
0
задан 6 March 2018 в 22:17

3 ответа

Ваша проблема заключается в том, что вы сообщаете SSH о подключении к (home forwarding to) homeserver: 8080 на удаленном конце, но ваша стеклянная рыба не привязана к этому IP; он связан с localhost.

Попробуйте ssh -L 8080:localhost:8080 minorthreat@homeserver.

1
ответ дан 22 May 2018 в 19:25
  • 1
    Тем не менее, я решил потратить некоторое время на настройку сервера openvpn и привязать все конечные точки java и postgres к интерфейсу tap0. Гораздо удобнее. Спасибо, в любом случае. – Minor Threat 17 August 2017 в 05:34
  • 2
    Однако имейте в виду, что это делает их адресованными в локальной сети, на которой установлен ваш сервер. Например. если ваш tap0 имеет 192.168.42.42/24, а ваш интерфейс eth0 имеет 10.1.1.1/24, то кто-то из сети 10.1.1.0/24, который знает о вашем 192.168.42.42 адресе, может отправлять пакеты от, например. 10.1.1.2, адресованному 192.168.42.42 на уровне IP и вашему MAC-адресу eth0, и ваш Linux-блок получит их и ответит им. Это не требует сложного кодирования на клиенте; им просто нужно добавить маршрут через 10.1.1.1 в направлении 192.168.42.42. – András Korn 18 August 2017 в 09:52
  • 3
    Таким образом, услуги привязки к интерфейсу tap0 не «скрываются», их так же тщательно, как привязывать их к обратному адресу. – András Korn 18 August 2017 в 09:54
  • 4
    Как это могло произойти? Я не настроил свой Linux как маршрутизатор. Зачем ему пересылать пакеты из одного интерфейса в другой? – Minor Threat 18 August 2017 в 14:55
  • 5
    $ cat / proc / sys / net / ipv4 / ip_forward 0 – Minor Threat 18 August 2017 в 15:35

Ваша проблема заключается в том, что вы сообщаете SSH о подключении к (home forwarding to) homeserver: 8080 на удаленном конце, но ваша стеклянная рыба не привязана к этому IP; он связан с localhost.

Попробуйте ssh -L 8080:localhost:8080 minorthreat@homeserver.

1
ответ дан 18 July 2018 в 08:28

Ваша проблема заключается в том, что вы сообщаете SSH о подключении к (home forwarding to) homeserver: 8080 на удаленном конце, но ваша стеклянная рыба не привязана к этому IP; он связан с localhost.

Попробуйте ssh -L 8080:localhost:8080 minorthreat@homeserver.

1
ответ дан 24 July 2018 в 19:05

Другие вопросы по тегам:

Похожие вопросы: