Установка статического IP-адреса, не соединяющегося?

Я следую учебному руководству для установки статического IP-адреса для моего удаленного сервера резервного копирования. (https://www.techrepublic.com/article/how-to-configure-a-static-ip-address-in-ubuntu-server-18-04/)

Я следовал за этим набором инструкций:

network:
        renderer: networkd
        ethernets:
            enp0s25:
                dhcp4: no
                addresses: [192.168.111.27/24]
                gateway4: 192.168.1.1
                nameservers:
                         addresses: [192.168.1.1,8.8.8.8]
        version: 2

Но теперь я не могу соединиться со своим сервером и должен буду восстановить его netplan из старой копии, которую я сделал прежде, чем сделать модификации.

Пользовательская конфигурация SSH:

Host Scilab
  HostName 192.168.43.245
  Port 45834
  IdentityFile ~/.ssh/LesserArkKey

Когда я пытаюсь использовать ssh Scilab Я добираюсь: ssh: connect to host 192.168.43.245 port 45834: Connection refused. Это необычно, потому что это работало прежде (у меня есть пользовательская конфигурация ssh). Я изменил текущую конфигурацию ssh на новый IP-адрес (Это было 192.168.1.144 ранее),

Что я делаю неправильно и как я могу установить IP-адрес на статический вместо DCHP?

РЕДАКТИРОВАНИЕ 0: Для разъяснения сервер работает просто великолепно основанный на ключе вход в систему, когда сервер имеет в распоряжении Netplan по умолчанию. ssh Scilab просит ключ шифрования, и я даю пароль, и все соединяется. Это только дает ошибку, когда я пытаюсь использовать новый Netplan. Затем ничто не работает.

Эти команды весь сбой также:

sarah@LesserArk:~$ ssh -p 45834 -i .ssh/LesserArkKey 192.168.111.27
ssh: connect to host 192.168.111.27 port 45834: Connection refused
sarah@LesserArk:~$ ssh -p 24 -i .ssh/LesserArkKey 192.168.111.27
ssh: connect to host 192.168.111.27 port 24: Connection refused
sarah@LesserArk:~$ ssh -i .ssh/LesserArkKey 192.168.111.27
ssh: connect to host 192.168.111.27 port 22: Connection refused

Сервер после netplan изменяется: Server ifconfig: Server ifconfig

Конфигурация SSHD:

#   $OpenBSD: sshd_config,v 1.101 2017/03/14 07:19:07 djm Exp $

# This is the sshd server system-wide configuration file.  See
# sshd_config(5) for more information.

# This sshd was compiled with PATH=/usr/bin:/bin:/usr/sbin:/sbin

# The strategy used for options in the default sshd_config shipped with
# OpenSSH is to specify options with their default value where
# possible, but leave them commented.  Uncommented options override the
# default value.

Port 45834
#AddressFamily any
#ListenAddress 0.0.0.0
#ListenAddress ::

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

# Ciphers and keying
#RekeyLimit default none

# Logging
SyslogFacility AUTH
LogLevel INFO

# Authentication:
LoginGraceTime 120
PermitRootLogin no
StrictModes yes
#MaxAuthTries 6
#MaxSessions 10

PubkeyAuthentication yes

# Expect .ssh/authorized_keys2 to be disregarded by default in future.
#AuthorizedKeysFile .ssh/authorized_keys .ssh/authorized_keys2

#AuthorizedPrincipalsFile none

#AuthorizedKeysCommand none
#AuthorizedKeysCommandUser nobody

# For this to work you will also need host keys in /etc/ssh/ssh_known_hosts
#HostbasedAuthentication no
# Change to yes if you don't trust ~/.ssh/known_hosts for
# HostbasedAuthentication
#IgnoreUserKnownHosts no
# Don't read the user's ~/.rhosts and ~/.shosts files
#IgnoreRhosts yes

# To disable tunneled clear text passwords, change to no here!
PasswordAuthentication no
#PermitEmptyPasswords no

# Change to yes to enable challenge-response passwords (beware issues with
# some PAM modules and threads)
ChallengeResponseAuthentication no

# Kerberos options
#KerberosAuthentication no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes
#KerberosGetAFSToken no

# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes
#GSSAPIStrictAcceptorCheck yes
#GSSAPIKeyExchange no

# 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

#AllowAgentForwarding yes
#AllowTcpForwarding yes
#GatewayPorts no
X11Forwarding yes
X11DisplayOffset 10
#X11UseLocalhost yes
#PermitTTY yes
PrintMotd no
#PrintLastLog yes
#TCPKeepAlive yes
#UseLogin no
#PermitUserEnvironment no
#Compression delayed
#ClientAliveInterval 0
#ClientAliveCountMax 3
#UseDNS no
#PidFile /var/run/sshd.pid
MaxStartups 2
#PermitTunnel no
#ChrootDirectory none
#VersionAddendum none

# no default banner path
#Banner none

# Allow client to pass locale environment variables
AcceptEnv LANG LC_*

# override default of no subsystems
Subsystem   sftp    /usr/lib/openssh/sftp-server

# Example of overriding settings on a per-user basis
#Match User anoncvs
#   X11Forwarding no
#   AllowTcpForwarding no
#   PermitTTY no
#   ForceCommand cvs server

Protocol 2

РЕДАКТИРОВАНИЕ 1: Вот выводы команд: cat /etc/hosts:

127.0.0.1       localhost.localdomain   localhost
::1             localhost6.localdomain6 localhost6

# The following lines are desirable for IPv6 capable hosts
::1     localhost ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
ff02::3 ip6-allhosts

cat /etc/nsswitch.conf | grep "hosts:": hosts: files dns

`networkctl status`:

●        State: routable
       Address: 192.168.111.27 on enp0s25
                fe80::225:64ff:feaf:9fc8 on enp0s25
           DNS: 192.168.1.1
                8.8.8.8

ls -l /etc/resolv.conf: lrwxrwxrwx 1 root root 39 Feb 14 09:49 /etc/resolv.conf -> ../run/systemd/resolve/stub-resolv.conf

РЕДАКТИРОВАНИЕ 2:/etc/hosts:

127.0.0.1       localhost.localdomain   localhost
::1             localhost6.localdomain6 localhost6
192.168.111.27  scilab_comp_0

# The following lines are desirable for IPv6 capable hosts
::1     localhost ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
ff02::3 ip6-allhosts

Вывод hostname: scilab_comp_0

РЕДАКТИРОВАНИЕ 3: Я сделал короткое видео из своего компьютера (Не сервер) показывающий больше детали относительно того, что происходит: https://www.youtube.com/watch? v=rqQGas4fs_A&feature=youtu.be

Сделанный быстрым видео IP-адреса конфликтовать здесь: https://youtu.be/P2rXWvdOM7k exit

РЕДАКТИРОВАНИЕ 4: вывод telnet 192.168.111.27 45834

sarah@scilab_comp_0:~$ telnet 192.168.111.27 45834
Trying 192.168.111.27...
Connected to 192.168.111.27.
Escape character is '^]'.
SSH-2.0-OpenSSH_7.6p1 Ubuntu-4ubuntu0.3
Connection closed by foreign host.

Сделал еще некоторое рытье и заметил, что у меня есть 2 IP-адреса для сервера. Вот ip a:

2: enp0s25: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 00:25:64:af:9f:c8 brd ff:ff:ff:ff:ff:ff
    inet 192.168.111.27/24 brd 192.168.111.255 scope global enp0s25
       valid_lft forever preferred_lft forever
    inet 192.168.1.142/24 brd 192.168.1.255 scope global dynamic enp0s25
       valid_lft 78971sec preferred_lft 78971sec
    inet6 fe80::225:64ff:feaf:9fc8/64 scope link 
       valid_lft forever preferred_lft forever

Поскольку Вы видите, что каждый является динамичным, и каждый статичен. Я не уверен, работает ли статический или не, хотя или как избавиться от динамического (Так как я вернулся yaml к исходной конфигурации, таким образом, я могу получить доступ к нему удаленно в настоящее время от моего компьютера). Учитывая, что наш файл конфигурации указывает, что мы только хотим DCHP один, куда статический IP-адрес прибывает из?

Кроме того, я проверил это только 50-cloud-init.yaml имеет любой эффект на конфигурацию. Я добавил.DISABLED префикс к другому yaml файлу, который мы создали, так как это, кажется, не имеет эффекта.

РЕДАКТИРОВАНИЕ 4: лучше тестирование

Я сделал лучший способ протестировать, может ли сервер соединиться. У меня есть два окна терминала, вошел в сервер, и каждый просто выполняет цикл с while true; do ip a; ping -c3 google.com; date; sleep 10; done. Другой делает sudo netplan try с netplan для установки IP-адреса на помехи.

Это результаты: - каждый раз IP-адрес идет статичный (После того, как я совершил нападки, вводят в другой терминал для 'sudo netplan попытка'', проверяют с помощью ping-запросов сбои:

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: enp0s25: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 00:25:64:af:9f:c8 brd ff:ff:ff:ff:ff:ff
    inet 192.168.111.27/24 brd 192.168.111.255 scope global enp0s25
       valid_lft forever preferred_lft forever
    inet6 fe80::225:64ff:feaf:9fc8/64 scope link 
       valid_lft forever preferred_lft forever
ping: google.com: Temporary failure in name resolution

И каждый раз это возвращается к использованию IP-адреса DCHP (Изложенный ранее, когда это имело 2 IP-адреса), это возвращается и сообщает информацию оболочке SSH моего ПК.

1
задан 15 May 2019 в 08:39

1 ответ

В netplan конфигурации сервера для статического IP Вы запрашиваете IP-адрес в другой подсети, чем подсеть шлюза. Хотя netplan может присвоить тот IP Вашему устройству, шлюз не сможет общаться с ним.

Для фиксации запросите IP-адрес в той же подсети, которая присвоена через DHCP. Таким образом, если присвоенный DHCP адрес 192.168.1.15, установите свой netplan yaml файл как это:

network:
    renderer: networkd
    ethernets:
        enp0s25:
            dhcp4: no
            addresses: [192.168.1.111/24]
            gateway4: 192.168.1.1
            nameservers:
                     addresses: [192.168.1.1,8.8.8.8]

Если Вы не уверены в IP шлюза, выпускаете следующее, в то время как у Вас есть исправное соединение через DHCP:

ip route 

Система ответит чем-то как

 default via 192.168.1.1 dev netdev01 ....

В этом выводе шлюз определяется через default via поле.

Для простоты, и избегать проблем, возникающих через DNS и локальную конфигурацию SSH, можно выпустить клиент запрос SSH с литеральным IP-адресом сервера:

ssh sarah@192.168.1.111

Это - сервер резервного копирования, таким образом, вероятно, что большая часть Вашей связи с сервером будет задана сценарием так, единственная функциональная причина использовать имя хоста состоит в том, если IP сервера, очень вероятно, изменится.

Кроме того, для простоты я генерировал бы свои ssh ключи к значению по умолчанию ~/.ssh/id_rsa.pub если нет веская причина сделать иначе. Это делает кодирование запроса более чистым и простым. Я поместил открытый ключ в именованный файл только, когда я хочу сохранить ключ возле своего локального дома или если я хотел, по некоторым причинам я не могу предположить иметь, сохранять различные ключи для различных хостов.

3
ответ дан 15 May 2019 в 08:39

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

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