Как установить SSH между портативным компьютером и сервером за маршрутизатором
Я пытаюсь настроить персональный SSH-сервер за маршрутизатором и иметь возможность подключаться к нему с помощью моего ноутбука. Я пробовал несколько руководств, но пока ничего не помогло. У меня
- включена переадресация портов на моем маршрутизаторе, направляя весь трафик с порта XXXX на порт моего сервера 22.
- запустил демон
sshdна моем сервере (по умолчанию прослушивает порт 22), и проверенный порт 22 на моем сервере был открыт. - использовал
ssh-keygenна моем ноутбуке для создания пары ключей, а затем передал ее через USB на сервер какmy_key.pub. Я оставил поле пароля пустым во время создания кейгена. - На сервере я
mkdir ~ / .sshиcat my_key.pub >> ~ / .ssh / authorized_keys. На портативном компьютере яmkdir ~ / .sshи перемещаю туда свой закрытый ключmy_key.
Мой публичный IP-адрес - ГГГ.ГГГ.ГГГ.ГГГ. Мой локальный IP-адрес сервера - 192.168.1.73.
Когда я пытаюсь
ssh (скрытый) -p XXXX -v
Я понимаю, что в соединении отказано, других сообщений отладки нет. То же самое происходит без спецификации порта.
Когда я пытаюсь
ssh (скрытый) -v
Я понимаю, что меня приветствует поле пароля, для которого пароль не работает:
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Connecting to 192.168.1.73 [192.168.1.73] port 22.
debug1: Connection established.
debug1: key_load_public: No such file or directory
debug1: identity file /home/xps/.ssh/id_rsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/xps/.ssh/id_rsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/xps/.ssh/id_dsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/xps/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/xps/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/xps/.ssh/id_ecdsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/xps/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/xps/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.2
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.3p1 Debian-1
debug1: match: OpenSSH_7.3p1 Debian-1 pat OpenSSH* compat 0x04000000
debug1: Authenticating to 192.168.1.73:22 as 'root'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256@libssh.org
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:0wIYI/LCJOSgjJMN9uiinKC5GVwNyH7cVf1CeqnAQEs
debug1: Host '192.168.1.73' is known and matches the ECDSA host key.
debug1: Found key in /home/xps/.ssh/known_hosts:1
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<rsa-sha2-256,rsa-sha2-512>
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Trying private key: /home/xps/.ssh/id_rsa
debug1: Trying private key: /home/xps/.ssh/id_dsa
debug1: Trying private key: /home/xps/.ssh/id_ecdsa
debug1: Trying private key: /home/xps/.ssh/id_ed25519
debug1: Next authentication method: password
root@192.168.1.73's password:
debug1: Authentications that can continue: publickey,password
Permission denied, please try again.
root@192.168.1.73's password:
debug1: Authentications that can continue: publickey,password
Permission denied, please try again.
root@192.168.1.73's password:
debug1: Authentications that can continue: publickey,password
debug1: No more authentication methods to try.
Permission denied (publickey,password).
Указание порта в этой опции дает мне отказ в другом соединении. Меня смущает, что здесь происходит не так!
Спасибо.
ИЗМЕНИТЬ Вот отладочная информация для остальных сценариев:
OpenSSH_7.3p1, OpenSSL 1.0.2h 3 May 2016
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Connecting to YYY.YYY.YYY.YYY [YYY.YYY.YYY.YYY] port XXXX.
debug1: connect to address YYY.YYY.YYY.YYY port XXXX: Connection refused
ssh: connect to host YYY.YYY.YYY.YYY port XXXX: Connection refused
Я хочу попробовать несколько вещей:
1) На вашем клиенте закрытый ключ по умолчанию, который он будет использовать при согласовании соединения, - ~ / .ssh / id_rsa Для того, чтобы укажите другой ключ, вы можете указать его следующим образом: ssh -i ~ / .ssh / my_key (hidden) -p xxxx
-i указывает используемый ключ
2) На сервере вы необходимо убедиться, что разрешения для authorized_keys и папки .ssh соответствуют .
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
3) В / etc / ssh / sshd_config есть опция, запрещающая вход в систему root - убедитесь, что она выключена:
#PermitRootLogin yes
Вы хотите видеть этот хэш-символ #, означающий команду to Prohibit закомментировано OUT (так что root может войти в систему)
4) Если клиент и сервер находятся в одной локальной сети (упрощенно, если они оба подключены к одному коммутатору); тогда вы должны использовать ЧАСТНЫЙ IP-адрес (192.168.xx) и порт 22. Если ваш клиент находится где-то в другом месте (McDonald's WiFi и т. д.), вы укажете своему клиенту ПУБЛИЧНЫЙ IP-адрес и порт xxxx. {{1 }} Другими словами - если они оба находятся в одной локальной сети, то маршрутизатор вообще не вступает в игру!
5) Если вы все еще застряли, проверьте журнал SSH на сервере. Эта статья - отличное руководство. Вкратце:
- Если ваш сервер - Ubuntu или его вариант, проверьте
/var/log/auth.log - Если ваш сервер - CentOS или его вариант, проверьте
/ var / log / secure
Удачи, держите нас в курсе!
По моему опыту, это проще, чем вы думаете, по крайней мере, для меня, использующего Ubuntu в качестве клиента. Но делать все нужно в правильной последовательности. Прежде чем пытаться передать ключ, вы должны попытаться убедиться, что вы можете подключиться, используя имя пользователя и пароль, которые являются вашими кредитными данными для входа, не обязательно root.
Затем, как только вы сможете подключиться, вы можете передать ключ:
сгенерировать ключ (RSA или DSA)
ssh-keygen -t rsa -- or dsa
передать ключ на удаленный хост:
ssh-copy-id username@host (your username and the host name or IP)
если не стандартный порт 22: обратите внимание на кавычки вокруг аргумента
ssh-copy-id "username@host -p PortNumber" (substitute number forPortNumber)
Я считаю, что проще всего настроить учетную запись ddns для обработки внешнего IP-адреса. Делает вещи намного проще.
Если вы используете Ubuntu или что-то подобное, вы можете найти полезную информацию здесь . Если нет, и если это не сработает, извините, но я пробовал.