Установка статического 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
Но теперь я не могу подключиться к своему серверу, и мне придется восстановить его сетевой план из старой копии, которую я сделал до внесения изменений.
Пользовательский SSH Config:
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
Сервер после смены нетплана: 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-адрес становится статическим (После того, как я нажал Enter на другом терминале для `sudo netplan try``, 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 ответ
В конфигурации сетевого плана сервера для статического 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 [email protected]
Это резервный сервер, поэтому, скорее всего, большая часть вашего взаимодействия с сервером будет записана в сценарии, поэтому единственная функциональная причина для использования имени хоста состоит в том, что IP-адрес сервера может измениться.
Также, для простоты, я бы сгенерировал мои ключи ssh по умолчанию ~/.ssh/id_rsa.pub
если нет веской причины поступить иначе. Это делает кодирование запроса более понятным и простым. Я помещаю открытый ключ в именованный файл только тогда, когда хочу сохранить ключ за пределами моего локального дома или, если я по какой-то причине не могу себе представить, хранить разные ключи для разных хостов.