Je suis en train de suivre un tutoriel pour définir une adresse IP statique pour mon serveur de sauvegarde distant. ( https://www.techrepublic.com/article/how-to-configure-a-static-ip-address-in-ubuntu-server-18-04/ )
J'ai suivi cet ensemble d'instructions:
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
Mais maintenant, je ne peux pas me connecter à mon serveur et je devrai restaurer son netplan à partir de l'ancienne copie que j'ai faite avant de faire des modifications.
Configuration SSH personnalisée:
Host Scilab
HostName 192.168.43.245
Port 45834
IdentityFile ~/.ssh/LesserArkKey
Lorsque j'essaie d'utiliser ssh Scilab
Je reçois: ssh: connect to Host 192.168.43.245 port 45834: Connection refused
. C'est inhabituel car cela fonctionnait auparavant (j'ai une configuration ssh personnalisée). J'ai changé la configuration ssh actuelle pour la nouvelle adresse IP (c'était 192.168.1.144 auparavant)
Que fais-je de mal et comment puis-je définir l'adresse IP sur une adresse statique au lieu de DCHP?
EDIT 0: Pour plus de précision, la connexion basée sur les clés du serveur fonctionne très bien lorsque le serveur a le Netplan par défaut en place. ssh Scilab
demande la clé de cryptage et je donne le mot de passe, et tout se connecte. Cela ne donne une erreur que lorsque j'essaie d'utiliser le nouveau Netplan. Alors rien ne fonctionne.
Ces commandes échouent également:
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
Le serveur après le changement de netplan: ifconfig
:
Configuration 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
EDIT 1: Voici les sorties des commandes: 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
EDIT 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
Sortie de hostname
: scilab_comp_0
EDIT 3: J'ai fait une courte vidéo depuis mon ordinateur (pas le serveur) montrant plus de détails sur ce qui se passe: https://www.youtube.com/watch?v=rqQGas4fs_A&feature=youtu.be
J'ai fait une vidéo rapide du conflit d'adresse IP ici: https://youtu.be/P2rXWvdOM7k
EDIT 4: Sortie de 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.
J'ai creusé un peu plus et j'ai remarqué que j'avais 2 adresses IP pour le serveur. Voici 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
Comme vous pouvez le voir, l'un est dynamique et l'autre est statique. Je ne sais pas si le statique fonctionne ou pas ou comment se débarrasser du dynamique (puisque j'ai rétabli le yaml dans la configuration d'origine afin que je puisse y accéder à distance pour le moment depuis mon ordinateur). Étant donné que notre fichier de configuration indique que nous ne voulons que le DCHP, d'où provient l'adresse IP statique?
De plus, j'ai vérifié que seul le 50-cloud-init.yaml
a un effet sur la configuration. J'ai ajouté le préfixe .DISABLED à l'autre fichier yaml que nous avons créé car il ne semble pas avoir d'effet.
EDIT 4: Meilleurs tests
J'ai fait un meilleur moyen de tester si le serveur est capable de se connecter ou non. J'ai deux fenêtres de terminal connectées au serveur et une exécute simplement une boucle avec while true; do ip a; ping -c3 google.com; date; sleep 10; done
. L'autre ne Sudo netplan try
avec le netplan pour définir l'adresse IP sur statique.
Voici les résultats: -Chaque fois que l'adresse IP devient statique (après avoir appuyé sur Entrée sur l'autre terminal pour `` Sudo netplan try``, le ping échoue:
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
Et chaque fois qu'il revient à utiliser l'adresse IP DCHP (Posé plus tôt quand il avait 2 adresses IP), il revient et rapporte les informations au SSH Shell de mon PC.
Dans la configuration netplan du serveur pour l'IP statique, vous demandez une adresse IP dans un sous-réseau différent de celui de la passerelle. Bien que netplan puisse attribuer cette IP à votre appareil, la passerelle ne pourra pas communiquer avec elle.
Pour résoudre ce problème, demandez une adresse IP dans le même sous-réseau attribué via DHCP. Donc, si l'adresse affectée par DHCP est 192.168.1.15
, définissez votre fichier yaml netplan comme ceci:
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]
Si vous n'êtes pas sûr de l'adresse IP de la passerelle, émettez ce qui suit pendant que vous disposez d'une bonne connexion via DHCP:
ip route
Le système répondra par quelque chose comme
default via 192.168.1.1 dev netdev01 ....
Dans cette sortie, la passerelle est identifiée par le default via
champ.
Pour plus de simplicité et pour éviter les problèmes liés au DNS et à la configuration SSH locale, vous pouvez émettre votre demande SSH client avec l'adresse IP littérale du serveur:
ssh [email protected]
Il s'agit d'un serveur de sauvegarde, il est donc probable que la plupart de vos communications avec le serveur seront scriptées, la seule raison fonctionnelle d'utiliser un nom d'hôte est si l'IP du serveur est très susceptible de changer.
Aussi, pour plus de simplicité, je générerais mes clés ssh sur la valeur par défaut ~/.ssh/id_rsa.pub
sauf s'il existe une raison valable de faire autrement. Cela rend le codage de la demande plus propre et plus simple. Je mets la clé publique dans un fichier nommé uniquement lorsque je veux stocker la clé en dehors de mon domicile local ou si je voulais, pour une raison quelconque, je ne peux pas imaginer avoir, garder des clés différentes pour différents hôtes.