Проблемы с IP-адресом Ubuntu SSH

Я планирую использовать недавно приобретенную настольную башню в качестве сервера, и я хотел бы начать с создания службы SSH. До сих пор я не имел успеха, и я считаю, что проблема в том, что IP для моего компьютера контролируется жилым комплексом, в котором я живу, и поэтому я, кажется, имею ограниченный контроль (т. Е. Без контроля) по привязке к порту.

Есть ли какое-нибудь обходное решение для этого?

(Ps Я все еще учась, когда я ухожу, поэтому любые рекомендации в вашем ответе также будут высоко оценены!)

Редактировать 1 :

sshd_config:

# Package generated configuration file # See the sshd_config(5) manpage for details # What ports, IPs and protocols we listen for, just picked a port at random # because none were working Port 380 # Use these options to restrict which interfaces/protocols sshd will bind to #ListenAddress :: ListenAddress [IP Address of Apartment Complex] Protocol 2 # HostKeys for protocol version 2 HostKey /etc/ssh/ssh_host_rsa_key HostKey /etc/ssh/ssh_host_dsa_key HostKey /etc/ssh/ssh_host_ecdsa_key HostKey /etc/ssh/ssh_host_ed25519_key #Privilege Separation is turned on for security UsePrivilegeSeparation yes # Lifetime and size of ephemeral version 1 server key KeyRegenerationInterval 3600 ServerKeyBits 1024 # Logging SyslogFacility AUTH LogLevel INFO # Authentication: LoginGraceTime 120 PermitRootLogin no StrictModes yes RSAAuthentication yes PubkeyAuthentication yes #AuthorizedKeysFile %h/.ssh/authorized_keys # Don't read the user's ~/.rhosts and ~/.shosts files IgnoreRhosts yes # For this to work you will also need host keys in /etc/ssh_known_hosts RhostsRSAAuthentication no # similar for protocol version 2 HostbasedAuthentication no # Uncomment if you don't trust ~/.ssh/known_hosts for RhostsRSAAuthentication #IgnoreUserKnownHosts yes # To enable empty passwords, change to yes (NOT RECOMMENDED) PermitEmptyPasswords yes # Change to yes to enable challenge-response passwords (beware issues with # some PAM modules and threads) ChallengeResponseAuthentication no # Change to no to disable tunnelled clear text passwords PasswordAuthentication no # Kerberos options #KerberosAuthentication no #KerberosGetAFSToken no #KerberosOrLocalPasswd yes #KerberosTicketCleanup yes # GSSAPI options #GSSAPIAuthentication no #GSSAPICleanupCredentials yes X11Forwarding yes X11DisplayOffset 10 PrintMotd no PrintLastLog yes TCPKeepAlive yes #UseLogin no #MaxStartups 10:30:60 #Banner /etc/issue.net # Allow client to pass locale environment variables AcceptEnv LANG LC_* Subsystem sftp /usr/lib/openssh/sftp-server # Set this to 'yes' to enable PAM authentication, account processing, # and session processing. If this is enabled, PAM authentication will # be allowed through the ChallengeResponseAuthentication and # PasswordAuthentication. Depending on your PAM configuration, # PAM authentication via ChallengeResponseAuthentication may bypass # the setting of "PermitRootLogin without-password". # If you just want the PAM account and session checks to run without # PAM authentication, then enable this but set PasswordAuthentication # and ChallengeResponseAuthentication to 'no'. UsePAM yes

Выход sudo systemctl start ssh:

Job for ssh.service failed because the control process exited with error code. See "systemctl status ssh.service" and "journalctl -xe" for details.

Выход systemctl status ssh.service:

ssh.service - OpenBSD Secure Shell server Loaded: loaded (/lib/systemd/system/ssh.service; enabled; vendor preset: enabled) Active: failed (Result: exit-code) since Mon 2017-06-05 22:15:30 PDT; 14s ago Process: 2288 ExecReload=/bin/kill -HUP $MAINPID (code=exited, status=0/SUCCESS) Process: 6579 ExecStart=/usr/sbin/sshd -D $SSHD_OPTS (code=exited, status=255) Main PID: 6579 (code=exited, status=255) Jun 05 22:15:30 Case systemd[1]: Starting OpenBSD Secure Shell server... Jun 05 22:15:30 Case systemd[1]: ssh.service: Main process exited, code=exited, status=255/n/a Jun 05 22:15:30 Case systemd[1]: Failed to start OpenBSD Secure Shell server. Jun 05 22:15:30 Case systemd[1]: ssh.service: Unit entered failed state. Jun 05 22:15:30 Case systemd[1]: ssh.service: Failed with result 'exit-code'.

Усеченный вывод 'journalctl -xe`:

Unit ssh.service has begun starting up. Jun 05 22:15:30 Case sshd[6579]: error: Bind to port 380 on [IP Address of My Apartment Complex] failed: Cannot assign requested address. Jun 05 22:15:30 Case sshd[6579]: fatal: Cannot bind any address. Jun 05 22:15:30 Case systemd[1]: ssh.service: Main process exited, code=exited, status=255/n/a Jun 05 22:15:30 Case systemd[1]: Failed to start OpenBSD Secure Shell server. -- Subject: Unit ssh.service has failed -- Defined-By: systemd -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel -- -- Unit ssh.service has failed.

Другие сведения:

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

Надеюсь, что этого достаточно!

0
задан 6 June 2017 в 09:32

4 ответа

Вы можете использовать Reverse SSH Tunneling для доступа к вашему ящику за NAT.

0
ответ дан 18 July 2018 в 12:05

Если вы находитесь в многоквартирном доме, который предоставляет Wi-Fi, вам действительно повезло. Если это так, есть вероятность, что у вас есть IP-адрес, предоставленный DHCP. Это означает, что каждый раз, когда вы перезагружаете или завершаете работу своего сервера, вы получите новый договор аренды и, возможно, другой IP-адрес. Однако, если это неудобство для вас не является большой проблемой, вы можете просто настроить SSH для документации, которая находится повсюду на этом сайте.

SSHD будет работать с любым IP-адресом, который назначен для сервер, включая неработающие адреса и локальный loopback. Естественно, если вы хотите получить ssh из Интернета, вам понадобится IP-адрес, доступный из-за пределов локальной сети.

В качестве отправной точки проверьте, что ваш текущий IP-адрес (если есть), набрав

ifconfig -a

, выполните следующие действия: ] Настройка sshd очень проста. Немного менее легко в зависимости от того, насколько безопасным вы хотите получить доступ к своему серверу. Базовый ssh ​​работает в значительной степени из коробки на Ubuntu 16.04

Чтобы проверить, работает ли sshd, независимо от сетевого подключения, введите

ssh localhost

Это позволит вам войдите в систему на своем сервере и убедитесь, что sshd действительно работает правильно.

1
ответ дан 18 July 2018 в 12:05

Вы можете использовать Reverse SSH Tunneling для доступа к вашему ящику за NAT.

0
ответ дан 24 July 2018 в 19:54

Если вы находитесь в многоквартирном доме, который предоставляет Wi-Fi, вам действительно повезло. Если это так, есть вероятность, что у вас есть IP-адрес, предоставленный DHCP. Это означает, что каждый раз, когда вы перезагружаете или завершаете работу своего сервера, вы получите новый договор аренды и, возможно, другой IP-адрес. Однако, если это неудобство для вас не является большой проблемой, вы можете просто настроить SSH для документации, которая находится повсюду на этом сайте.

SSHD будет работать с любым IP-адресом, который назначен для сервер, включая неработающие адреса и локальный loopback. Естественно, если вы хотите получить ssh из Интернета, вам понадобится IP-адрес, доступный из-за пределов локальной сети.

В качестве отправной точки проверьте, что ваш текущий IP-адрес (если есть), набрав

ifconfig -a

, выполните следующие действия: ] Настройка sshd очень проста. Немного менее легко в зависимости от того, насколько безопасным вы хотите получить доступ к своему серверу. Базовый ssh ​​работает в значительной степени из коробки на Ubuntu 16.04

Чтобы проверить, работает ли sshd, независимо от сетевого подключения, введите

ssh localhost

Это позволит вам войдите в систему на своем сервере и убедитесь, что sshd действительно работает правильно.

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

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

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