Помогите настроить ssh-соединение.

[savigm]

Есть рабочая станция, подключенная к интернету через NAT и рабочая станция, подключенная к интернету, с внешним динамическим ip-адресом. На обоих компах стоит Linux. Как можно настроить ssh-соединение между рабочими станциями, чтобы подключаться с компа с динамическим ip?

[sash-kan]

клиент dyndns на машине с динамическим ip.
ssh с опцией -R на машине за nat-ом. чтоб далеко за примером не ходить — FAQ aka Оглавление. в блоге, конечно, более коротко и именно про -R (ссылка в подписи). но так руки и не доходят дополнить блог соображениями про keepalive. они изложены как раз в faq-е.

[drBatty]

тут не зайти мне было на комп жены по ssh, почему-то ключи у неё сбросились, сделал по новой. Это в настройках ssh-server'а? или мне в раздел своего дистрибутива? или просто непонятный баг?

[Ленивая Бестолочь]

тут не зайти мне было на комп жены по ssh, почему-то ключи у неё сбросились, сделал по новой

некоторое время назад (точно не помню) - вроде около полугода нашли баг в генераторе ключей у openssh.
соответственно все ключи, сгенерированные тем генератором скомпроментированы и не принимаются больше при подключении.

[drBatty]

некоторое время назад (точно не помню) - вроде около полугода

не. я с месяц или 2(не раньше) создавал и настраивал ключи. тогда и ssh-server установил из репов. систему обновляю, раз в 2-3 дня.

[savigm]

Проблема с динамическим IP сервера решена, с помощью dyndns.org.
Запустил сервер sshd, обнаружил следы попыток соединения компа за NAT'ом:

Код: Выделить всё

May 12 15:32:43 linux-7ycy sshd[8599]: Accepted publickey for user from xxx.xxx.xxx.xxx port 21072 ssh2
May 12 15:33:38 linux-7ycy sshd[8645]: Accepted publickey for user from xxx.xxx.xxx.xxx port 21073 ssh2
May 12 15:34:38 linux-7ycy sshd[8691]: Accepted publickey for user from xxx.xxx.xxx.xxx port 21074 ssh2

Вот что выполняется на компе за NAT'ом:

Код: Выделить всё

command='ssh -f -N -R 4040:localhost:22 user@user.dyndns.org -o
ConnectTimeout=60 -o ServerAliveInterval=20 -o ServerAliveCountMax=5 -o
StrictHostKeyChecking=no'
*/1 * * * * pgrep -f "$command" &>/dev/null || $command

На этом попытки коннекта кончились, порт 4040 открыт, ключи Я генерил на компе за NAT'ом, public key скопировал на комп сервера в authorized_keys.

Подскажите, в чем загоздка, почему комп за NAT'ом болше не стучится на сервер?

[sash-kan]

почему комп за NAT'ом болше не стучится на сервер?

а почему он так часто стучался? у него хоть раз получилось соединиться? что выдаёт
$ command='ssh -f -N -R 4040:localhost:22 user@user.dyndns.org -o \
ConnectTimeout=60 -o ServerAliveInterval=20 -o ServerAliveCountMax=5 -o \
StrictHostKeyChecking=no' pgrep -f "$command"
?

[savigm]

Выдачу компа за NAT'ом я узнаю только завтра, у меня же(на сервере sshd) в логах было следующее:

Код: Выделить всё

May 12 15:32:43 linux-7ycy sshd[8599]: Accepted publickey for savigm from xxx.xxx.xxx.xxx port 21072 ssh2
May 12 15:33:38 linux-7ycy sshd[8645]: Accepted publickey for savigm from xxx.xxx.xxx.xxx port 21073 ssh2
May 12 15:34:38 linux-7ycy sshd[8691]: Accepted publickey for savigm from xxx.xxx.xxx.xxx port 21074 ssh2

Где xxx.xxx.xxx.xxx - IP NAT'а.

Непонятно почему ключ три раза принялся, и на этом все закончилось. Возможно на компе за NAT'ом процесс после соединения продолжает висеть, хотя соединения давно уже нет.
Может для надежности в кронтабе убрать проверку работы процесса, и стучаться каждые пять минут на сервер:

Код: Выделить всё

command='ssh -f -N -R 4040:localhost:22 user@user.dyndns.org -o
ConnectTimeout=60 -o ServerAliveInterval=20 -o ServerAliveCountMax=5 -o
StrictHostKeyChecking=no'
*/5 * * * * $command

Правда при этом видимо будет висеть много процессов ssh-клиентов.

[savigm]

Клиент почему-то достукивается до сервера несколько раз в сутки, в остальное время тишина.
Сам сегодня пробовал: ping с клиента на ip сервера не проходит, ping с сервера на ip сервера проходит.
Либо клиента NAT или фаервол не пускает(что вряд-ли), либо виноват маршрутизатор сервера - D-Link DSL 2640U, но там все основные сервисы - icmp, ssh,ftp и т.п. включены.
Что самое странное в логах среди неудачных коннектов есть удачные - штук 10 подряд, затем тишина, т.е. до сервера то есть коннект, то нету. Может я в эти моменты действительно что-то в настройках маршрутизатора менял, точно не помню.

Вот лог удачного коннекта.

Код: Выделить всё

debug1: Connecting to someserver.org [xxx.xxx.xxx.xxx] port 22.
debug1: fd 3 clearing O_NONBLOCK
debug1: Connection established.
debug1: identity file /home/user/.ssh/id_rsa type 1
debug1: identity file /home/user/.ssh/id_dsa type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.0
debug1: match: OpenSSH_5.0 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.0
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'someserver.org' is known and matches the RSA host key.
debug1: Found key in /home/user/.ssh/known_hosts:17
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Offering public key: /home/user/.ssh/id_rsa
debug1: Server accepts key: pkalg ssh-rsa blen 277
debug1: read PEM private key done: type RSA
debug1: Authentication succeeded (publickey).
debug1: Remote connections from LOCALHOST:4040 forwarded to local address localhost:22
debug1: Entering interactive session.
debug1: remote forward failure for: listen 4040, connect localhost:22
Warning: remote port forwarding failed for listen port 4040

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

Подскажите дальнейшие действия по прокладыванию ssh-туннеля...

[savigm]

Виноват оказался фаервол маршрутизатора - если его отрубить ping работает, ssh соединение устанавливается.
Остается одна проблема:

Код: Выделить всё

debug1: Remote connections from LOCALHOST:4040 forwarded to local address localhost:22
debug1: Entering interactive session.
debug1: remote forward failure for: listen 4040, connect localhost:22
Warning: remote port forwarding failed for listen port 4040

Возможно это опять что-то в маршрутизаторе, но я его сделал прозрачным - ничего он фильтровать не должен.
Большее подозрение вызывает фаервол ОС и сам сервер sshd. ОС - openSuse 11.0, в ферволе открыл порт 4040, если на него повесить ssh-сервер, то canyouseeme.org говорит что порт открыт. В настройках sshd есть строка:

Код: Выделить всё

#       AllowTcpForwarding no

Я ее разкоментировал, поставил yes, перезапустил ssh daemon - не помогло - порт 4040 не прослушивается.
В man ssh_config обнаружил еще кое-что:

Privileged ports can be forwarded only when logging in as root on the remote machine.

Я же соединяюсь с сервером как обычный пользователь, возможно поэтому ssh-сервер не позволяет ssh-клиенту перенаправить стандартный 22 порт на 4040?
Если есть мысли по данному вопросу - прошу высказать.

[sash-kan]

так. давайте снова на пальцах. а то я полностью потерял нить ваших рассуждений.

есть машина user.dyndns.org, у вас на ней есть учётка user. sshd на этой машине слушает 122-й порт.
и есть машина loc.host с учёткой luser. sshd на этой машине слушает 222-й порт.
выполнив на loc.host от имени luser команду
luser@loc.host~$ ssh -p 122 -f -N -R 10001:localhost:222 user@user.dyndns.org
и введя на запрос пароль пользователя user@user.dyndns.org, вы устанавливаете туннель между этими двумя машинами.

технически это выливается в запуск процесса ssh от имени user на машине user.dyndns.org, слушающего порт 10001 на интерфейсе lo (loopback, обычно имеет адрес 127.0.0.1/8).
ну и, естественно, на loc.host остаётся висеть процесс ssh.
вот эти два процесса, взаимодействуя друг с другом, и образуют туннель.

данный туннель позволяет, залогинившись под именем user на машину user.dyndns.org, выполнить команду:
user@user.dyndns.org~$ ssh -p 10001 luser@localhost
и, введя пароль пользователя luser@loc.host, получить сеанс этого самого luser на машине loc.host

цифра 10001 не зря такая большая. номер этого порта должен быть больше 1000. разве что под именем user@user.dyndns.org вы подразумеваете root@user.dyndns.org.
root-у — да, можно создавать процессы, слушающие порты ниже тысячного. рядовому пользователю — увы…

p.s. исходя из вышеизложенного, и разбирайтесь, чего и где вам нужно подрихтовать.

[savigm]

Добился установки соединения, прослушки порта 4040, однако теперь при соединении с портом 4040 такая проблема:

Код: Выделить всё

debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to localhost [127.0.0.1] port 4040.
debug1: Connection established.
debug3: Not a RSA1 key file /home/savigm/.ssh/id_rsa.
debug2: key_type_from_name: unknown key type '-----BEGIN'
debug3: key_read: missing keytype
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug2: key_type_from_name: unknown key type '-----END'
debug3: key_read: missing keytype
debug1: identity file /home/savigm/.ssh/id_rsa type 1
debug1: identity file /home/savigm/.ssh/id_dsa type -1
ssh_exchange_identification: Connection closed by remote host

Хоть-бы пароль спросил, а то сразу послал...

[drBatty]

debug3: Not a RSA1 key file /home/savigm/.ssh/id_rsa.

http://www.opennet.ru/base/sec/ssh_pubkey_auth.txt.html

[sash-kan]

savigm
вырубите к чёрту все ваши файерволы, конфигурационные файлы ssh и sshd верните к первоначальному состоянию.
иначе очень долго будете тыкаться, как слепой котёнок, в разложенные своими же (и не только своими) руками грабли.

[savigm]

Конф. файлы восстановил, фаервол отрубил - не помогло, в логах сервера при попытке коннекта на прослушиваемый 4040 порт следующее:

Код: Выделить всё

sshd[1156]: channel 2: open failed: connect failed: Connection refused

[sash-kan]

это вы на user.dyndns.org выполняете?
облом происходит либо непосредственно со стороны процесса ssh, выполняющегося на этой машине, либо со стороны sshd, выполняющегося на машине loc.host.
проверьте для начала второе предположение:
luser@loc.host~$ ssh -p 222 luser@localhost

[savigm]

это вы на user.dyndns.org выполняете?
облом происходит либо непосредственно со стороны процесса ssh, выполняющегося на этой машине, либо со стороны sshd, выполняющегося на машине loc.host.
проверьте для начала второе предположение:
luser@loc.host~$ ssh -p 222 luser@localhost

Да на сервере user.dyndns.org, если я соединяюсь с сервером по 22 порту - ssh localhost - все нормально, если по прослушиваемому порту туннеля 4040 - ssh -p 4040 user@localhost -

Код: Выделить всё

OpenSSH_5.0p1, OpenSSL 0.9.8g 19 Oct 2007
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to localhost [127.0.0.1] port 4040.
debug1: Connection established.
debug3: Not a RSA1 key file /home/savigm/.ssh/id_rsa.
debug2: key_type_from_name: unknown key type '-----BEGIN'
debug3: key_read: missing keytype
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug2: key_type_from_name: unknown key type '-----END'
debug3: key_read: missing keytype
debug1: identity file /home/savigm/.ssh/id_rsa type 1
debug1: identity file /home/savigm/.ssh/id_dsa type -1
ssh_exchange_identification: Connection closed by remote host

Сервер ищет RSA1 ключ, ругается что мой RSA не такой, не спрашивает пароль и закрывает соединение по непонятным причинам.

А вот детальная информация из логов сервера при попытке соединения с портом 4040:

Код: Выделить всё

May 17 18:36:31 linux-7ycy sshd[6476]: debug1: server_input_global_request: rtype keepalive@openssh.com want_reply 1
May 17 18:36:32 linux-7ycy sshd[6476]: debug1: Connection to port 4040 forwarding to localhost port 0 requested.
May 17 18:36:32 linux-7ycy sshd[6476]: debug2: fd 9 setting TCP_NODELAY
May 17 18:36:32 linux-7ycy sshd[6476]: debug2: fd 9 setting O_NONBLOCK
May 17 18:36:32 linux-7ycy sshd[6476]: debug3: fd 9 is O_NONBLOCK
May 17 18:36:32 linux-7ycy sshd[6476]: debug1: channel 2: new [forwarded-tcpip]
May 17 18:36:32 linux-7ycy sshd[6476]: channel 2: open failed: connect failed: Connection refused
May 17 18:36:32 linux-7ycy sshd[6476]: debug1: channel 2: free: forwarded-tcpip: listening port 4040 for localhost port 0, connect from 127.0.0.1 port 21599, nchannels 3
May 17 18:36:32 linux-7ycy sshd[6476]: debug3: channel 2: status: The following connections are open:\r\n  #2 forwarded-tcpip: listening port 4040 for localhost port 0, connect from 1
27.0.0.1 port 21599 (t3 r-1 i0/0 o0/0 fd 9/9 cfd -1)\r\n
May 17 18:36:32 linux-7ycy sshd[6476]: debug3: channel 2: close_fds r 9 w 9 e -1 c -1

[sash-kan]

Да на сервере user.dyndns.org, если я соединяюсь с сервером по 22 порту - ssh localhost - все нормально

я про ту машину писал. которая у вас за nat-ом:

luser@loc.host~$ ssh -p 222 luser@localhost

А вот детальная информация из логов сервера при попытке соединения с портом 4040:

на какой машине? на loc.host, которая за nat-ом, или на user.dyndns.org, которая имеет внешний ip?
какую машину вы подразумеваете, называя её «сервер»?

[savigm]

Да на сервере user.dyndns.org, если я соединяюсь с сервером по 22 порту - ssh localhost - все нормально

я про ту машину писал. которая у вас за nat-ом:

luser@loc.host~$ ssh -p 222 luser@localhost

Завтра попробую, но для этого придется запустить sshd на localhost

А вот детальная информация из логов сервера при попытке соединения с портом 4040:

на какой машине? на loc.host, которая за nat-ом, или на user.dyndns.org, которая имеет внешний ip?
какую машину вы подразумеваете, называя её «сервер»?

Сервер - это машина с внешним ip, на которой работает sshd - сервер.

[savigm]

Давайте еще раз все уточним:

nathost - машина за NAT, не имеющая внешнего ip;
remotehost - машина с внещним ip, с которой нужно получить доступ к nathost;
localhost - 127.0.0.1
nuser - пользователь на nathost;
ruser - пользователь на remotehost;

На nathost я запускаю cron задание:

Код: Выделить всё

sshcmd='ssh -f -N -v -R 4040:localhost:22 ruser@remotehost -o ConnectTimeout=60 -o ServerAliveInterval=20 -o ServerAliveCountMax=5 -o StrictHostKeyChecking=no'
*/5 * * * * pgrep -f "$sshcmd" &>/dev/null || (date >> ~/tmp/sshtun.log; $sshcmd >> ~/tmp/sshtun.log 2>&1; echo >> ~/tmp/sshtun.log)

На remotehost работает ssh daemon, соединение ssh-клиента nathost с ssh-сервером remotehost нормально устанавливается, на remotehost по

Код: Выделить всё

netstat -lp --inet --numeric-ports

вижу что порт 4040 прослушивает ssh daemon, т.е. порт перенапрвлен. На remotehost пытаемся соединится с nathost по 4040 порту:

Код: Выделить всё

ssh -vvv -p 4040 nuser@localhost

, получаем:

Код: Выделить всё

OpenSSH_5.0p1, OpenSSL 0.9.8g 19 Oct 2007
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to localhost [127.0.0.1] port 4040.
debug1: Connection established.
debug3: Not a RSA1 key file /home/savigm/.ssh/id_rsa.
debug2: key_type_from_name: unknown key type '-----BEGIN'
debug3: key_read: missing keytype
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug2: key_type_from_name: unknown key type '-----END'
debug3: key_read: missing keytype
debug1: identity file /home/savigm/.ssh/id_rsa type 1
debug1: identity file /home/savigm/.ssh/id_dsa type -1
ssh_exchange_identification: Connection closed by remote host

В логах ssh-клиента nathost - sshtun.log:

Код: Выделить всё

Mon May 18 02:30:01 MSD 2009
OpenSSH_5.0p1, OpenSSL 0.9.8g 19 Oct 2007
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to savigm.dyndns.org [85.140.64.157] port 22.
debug1: fd 3 clearing O_NONBLOCK
debug1: Connection established.
debug1: identity file /home/savinov/.ssh/id_rsa type 1
debug1: identity file /home/savinov/.ssh/id_dsa type -1
debug1: Remote protocol version 1.99, remote software version OpenSSH_5.0
debug1: match: OpenSSH_5.0 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.0
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'savigm.dyndns.org' is known and matches the RSA host key.
debug1: Found key in /home/savinov/.ssh/known_hosts:17
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Offering public key: /home/savinov/.ssh/id_rsa
debug1: Server accepts key: pkalg ssh-rsa blen 277
debug1: read PEM private key done: type RSA
debug1: Authentication succeeded (publickey).
debug1: Remote connections from LOCALHOST:4040 forwarded to local address localhost:22
debug1: Entering interactive session.

debug1: remote forward success for: listen 4040, connect localhost:22
debug1: client_input_channel_open: ctype forwarded-tcpip rchan 2 win 2097152 max 32768
debug1: client_request_forwarded_tcpip: listen localhost port 4040, originator 127.0.0.1 port 20418
debug1: channel 0: new [127.0.0.1]
debug1: confirm forwarded-tcpip
debug1: channel 0: not connected: Connection refused
debug1: channel 0: free: 127.0.0.1, nchannels 1
debug1: client_input_channel_open: ctype forwarded-tcpip rchan 2 win 2097152 max 32768
debug1: client_request_forwarded_tcpip: listen localhost port 4040, originator 127.0.0.1 port 20420
debug1: channel 0: new [127.0.0.1]
debug1: confirm forwarded-tcpip
debug1: channel 0: not connected: Connection refused
debug1: channel 0: free: 127.0.0.1, nchannels 1
debug1: client_input_channel_open: ctype forwarded-tcpip rchan 2 win 2097152 max 32768
debug1: client_request_forwarded_tcpip: listen localhost port 4040, originator 127.0.0.1 port 22006
debug1: channel 0: new [127.0.0.1]
debug1: confirm forwarded-tcpip
debug1: channel 0: not connected: Connection refused
debug1: channel 0: free: 127.0.0.1, nchannels 1
debug1: client_input_channel_open: ctype forwarded-tcpip rchan 2 win 2097152 max 32768
debug1: client_request_forwarded_tcpip: listen localhost port 4040, originator 127.0.0.1 port 22008
debug1: channel 0: new [127.0.0.1]
debug1: confirm forwarded-tcpip
debug1: channel 0: not connected: Connection refused
debug1: channel 0: free: 127.0.0.1, nchannels 1
debug1: client_input_channel_open: ctype forwarded-tcpip rchan 2 win 2097152 max 32768
debug1: client_request_forwarded_tcpip: listen localhost port 4040, originator 127.0.0.1 port 22012
debug1: channel 0: new [127.0.0.1]
debug1: confirm forwarded-tcpip
debug1: channel 0: not connected: Connection refused
debug1: channel 0: free: 127.0.0.1, nchannels 1
debug1: client_input_channel_open: ctype forwarded-tcpip rchan 2 win 2097152 max 32768
debug1: client_request_forwarded_tcpip: listen localhost port 4040, originator 127.0.0.1 port 22014
debug1: channel 0: new [127.0.0.1]
debug1: confirm forwarded-tcpip
debug1: channel 0: not connected: Connection refused
debug1: channel 0: free: 127.0.0.1, nchannels 1
debug1: client_input_channel_open: ctype forwarded-tcpip rchan 2 win 2097152 max 32768
debug1: client_request_forwarded_tcpip: listen localhost port 4040, originator 127.0.0.1 port 4857
debug1: channel 0: new [127.0.0.1]
debug1: confirm forwarded-tcpip
debug1: channel 0: not connected: Connection refused
debug1: channel 0: free: 127.0.0.1, nchannels 1
debug1: client_input_channel_open: ctype forwarded-tcpip rchan 2 win 2097152 max 32768
debug1: client_request_forwarded_tcpip: listen localhost port 4040, originator 127.0.0.1 port 4861
debug1: channel 0: new [127.0.0.1]
debug1: confirm forwarded-tcpip
debug1: channel 0: not connected: Connection refused
debug1: channel 0: free: 127.0.0.1, nchannels 1
debug1: client_input_channel_open: ctype forwarded-tcpip rchan 2 win 2097152 max 32768
debug1: client_request_forwarded_tcpip: listen localhost port 4040, originator 127.0.0.1 port 4862
debug1: channel 0: new [127.0.0.1]
debug1: confirm forwarded-tcpip
debug1: channel 0: not connected: Connection refused
debug1: channel 0: free: 127.0.0.1, nchannels 1
debug1: client_input_channel_open: ctype forwarded-tcpip rchan 2 win 2097152 max 32768
debug1: client_request_forwarded_tcpip: listen localhost port 4040, originator 127.0.0.1 port 4863
debug1: channel 0: new [127.0.0.1]
debug1: confirm forwarded-tcpip
debug1: channel 0: not connected: Connection refused
debug1: channel 0: free: 127.0.0.1, nchannels 1
debug1: client_input_channel_open: ctype forwarded-tcpip rchan 2 win 2097152 max 32768
debug1: client_request_forwarded_tcpip: listen localhost port 4040, originator 127.0.0.1 port 4864
debug1: channel 0: new [127.0.0.1]
debug1: confirm forwarded-tcpip
debug1: channel 0: not connected: Connection refused
debug1: channel 0: free: 127.0.0.1, nchannels 1
Read from remote host savigm.dyndns.org: No route to host
debug1: Transferred: stdin 0, stdout 0, stderr 59 bytes in 4448.5 seconds
debug1: Bytes per second: stdin 0.0, stdout 0.0, stderr 0.0
debug1: Exit status -1

Я одного не пойму: для соединения remotehost:4040 с nathost:22 нужен-ли ssh daemon на nathost, прослушивающий 22 порт? Ведь nathost находится за NAT, зачем там ssh daemon, порт 22 все равно не виден из интернета?

[pelmen]

Попробую объяснить. Когда ты выполняешь
ssh -f -N -v -R 4040:localhost:22 ruser@remotehost
у тебя образуется тунель между компьютером, с которого выполняется эта команда и компьютером remotehost.
"-R" говорит, что "вход" в этот тунель будет на remotehost, "выход", соответственно, на другом.
"4040:" говорит о том, что "вход" будет слушать на этом порте
"localhost:22" говорит о том, что трафик, вышедший из тунеля нужно будет направить на localhost:22
нужен-ли ssh daemon на nathost, прослушивающий 22 порт?
Если его там не будет, то трафику будет "refuse connection"

[sash-kan]

для этого придется запустить sshd на localhost

на каком localhost???
на машине за натом?
sshd там не был запущен?!
и как вы себе представляли организацию туннеля?
перечитайте ещё раз Помогите настроить ssh-соединение. и обратите внимание на _две_ строки «sshd на этой машине слушает такой-то порт».

[savigm]

Да, все заработало, спасибо. Может конечно Я пропустил, но про то что при прокладывании ssh-туннеля за NAT, на машине за NAT'ом должен быть запущен sshd насколько я помню ни в FAQ ни в блоге не говорилось. Везде очень кратенько про туннели написанно - сделай так-то, а как все это работает не говорится. Я не нашел подробной информации по ssh-туннелированию, если подскажите - буду благодарен.

[sash-kan]

в блоге не говорилось

цитата из блога:

p.s. кусочек «inner.host:22» — это способ достучаться до собственного sshd непосредственно с inner.host-а. если sshd слушает на порту 1000 — «inner.host:1000».
кусочек «inner.host:22» вполне можно заменить и на «localhost:22», и на «127.0.0.1:22».

почему об этом не пишут большими красными буквами?
сужу по себе — весьма трудно представить себе машину, подключенную к сети, на которой не запущен sshd.
как ею рулить-то? идти к ней и на кнопки нажимать, что ли?

[sash-kan]

не нашел подробной информации по ssh-туннелированию

man sshd. google://ssh+tunneling