Я следую учебному руководству для установки статического 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 изменяется:
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
РЕДАКТИРОВАНИЕ 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 моего ПК.
В 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
если нет веская причина сделать иначе. Это делает кодирование запроса более чистым и простым. Я поместил открытый ключ в именованный файл только, когда я хочу сохранить ключ возле своего локального дома или если я хотел, по некоторым причинам я не могу предположить иметь, сохранять различные ключи для различных хостов.