Utilisation des clés WireGuard pour SSH

La meilleure pratique pour gérer les clés SSH est d’utiliser les certificats de l’hôte et de l’utilisateur SSH CA. Cependant, si vous utilisez déjà WireGuard pour connecter deux machines dans un réseau point-to-point, vous pouvez entièrement éviter la gestion des clés SSH et simplement faire confiance à WireGuard pour l’authentification. Cet article vous montrera comment.

Ce concept fonctionne grâce à WireGuard qui fournit une connexion cryptée avec une authentification mutuelle, tout comme SSH. Dans une configuration point-to-point entre deux points de terminaison, comme celle-ci entre le Point A et le Point B, chaque point de terminaison WireGuard a été configuré avec la clé publique de l’autre partie, et utilise cette clé pour cryptographiquement authentifier l’autre côté de la connexion :

Figure 1. Authentification mutuelle avec WireGuard

De plus, le routage basé sur les clés cryptographiques de WireGuard (cryptokey routing) bloque automatiquement le trafic qui ne passe pas à travers le tunnel WireGuard, sauf si vous autorisez la connexion par pair et adresse IP. Ainsi, si nous configurons notre interface WireGuard sur l’Endpoint B pour accepter les connexions de l’Endpoint A avec un trafic provenant de 10.0.0.1, WireGuard garantit que tout paquet sortant de cette interface avec une adresse source de 10.0.0.1 a légalement été envoyé à nous par l’Endpoint A (ou par un hôte qui contrôle la clé privée de l’Endpoint A) :

Figure 2. Routage basé sur les clés cryptographiques appliqué par WireGuard

Ainsi, si nous configurons notre interface WireGuard sur l’Endpoint B pour accepter les connexions de l’Endpoint A ayant une adresse source de 10.0.0.1 et que nous configurons le pare-feu sur l’Endpoint B pour bloquer les connexions ayant une adresse source de 10.0.0.1 provenant d’importe part mais pas de cette interface, chaque service réseau que nous exécutons sur l’Endpoint B peut faire confiance à tout connexion avec une adresse source de 10.0.0.1 qui a légalement été envoyée par l’Endpoint A.

Et si nous avons la certitude que un utilisateur individuel (comme Alice) a le contrôle unique de la clé privée WireGuard de l’Endpoint A, alors nous pouvons automatiquement connecter cette utilisateur à tout service réseau (comme SSH) sur l’Endpoint B chaque fois que la connexion a une adresse source de 10.0.0.1 :

Figure 3. Connexion SSH d’Alice à travers un tunnel WireGuard point-to-point

Pour cela, ces composants doivent être configurés sur le Point de terminaison B :

1. Configuration de WireGuard
2. Configuration de SSHD
3. Configuration du groupe réseau
4. Configuration PAM
5. Configuration du pare-feu

Avec cette configuration en place sur le Point de terminaison B, nous pouvons ensuite Tester depuis le Point de terminaison A (et effectuer tout Dépannage nécessaire). En bonus, à la fin de cet article, nous montrerons également comment nous pourrions éliminer complètement SSH, en remplaçant par Telnet et FTP (ou RSH) — cryptés et authentifiés par WireGuard.

Configuration de WireGuard

D’abord, nous allons configurer WireGuard sur le Point de terminaison A et B comme dans l’article Configuration point-to-point de WireGuard (consultez-le pour une explication détaillée de chaque paramètre de configuration).

Sur le Point de terminaison A, nous utiliserons la configuration WireGuard suivante :

# /etc/wireguard/wg0.conf

# paramètres locaux pour le Point de terminaison A
[Interface]
PrivateKey = AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEE=
Address = 10.0.0.1/32
ListenPort = 51821

# paramètres distants pour le Point de terminaison B
[Peer]
PublicKey = fE/wdxzl0klVp/IR8UcaoGUMjqaWi3jAd7KzHKFS6Ds=
Endpoint = 203.0.113.2:51822
AllowedIPs = 10.0.0.2/32

Cette configuration signifie que le Point de terminaison A utilisera une adresse IP source de 10.0.0.1 pour ses connexions au Point de terminaison B, et le Point de terminaison A acceptera uniquement les connexions avec une adresse IP source de 10.0.0.2 provenant du Point de terminaison B.

Au Point de terminaison B, nous utiliserons la configuration suivante pour WireGuard :

# /etc/wireguard/wg0.conf

# paramètres locaux pour le Point de terminaison B
[Interface]
PrivateKey = ABBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBFA=
Address = 10.0.0.2/32
ListenPort = 51822

# paramètres distants pour le Point de terminaison A
[Peer]
PublicKey = /TOE4TKtAqVsePRVR+5AA43HkAK5DSntkOCO7nYq5xU=
AllowedIPs = 10.0.0.1/32

Cette configuration signifie que le Point de terminaison B utilisera une adresse IP source de 10.0.0.2 pour ses connexions au Point de terminaison A, et le Point de terminaison B acceptera uniquement les connexions avec une adresse IP source de 10.0.0.1 provenant du Point de terminaison A.

Configuration de SSHD

Comme nous utiliserons PAM pour accomplir l’authentification (couvert dans quelques sections ci-dessous), nous devons activer PAM dans notre fichier sshd_config sur le Point de terminaison B. Pour activer PAM pour l’authentification, nous devons nous assurer que le paramètre spécifique à Linux (UsePAM) est défini sur yes — plus KbdInteractiveAuthentication ou PasswordAuthentication est également défini sur yes :

# /etc/ssh/sshd_config
...
UsePAM yes
KbdInteractiveAuthentication yes
# ou PasswordAuthentication yes

$ sudo groupadd ssh-pk-users
$ sudo usermod --append --groups ssh-pk-users cate
$ sudo usermod --append --groups ssh-pk-users dan

# /etc/ssh/sshd\_config
...
AllowGroups ssh-pk-users
KbdInteractiveAuthentication no
PasswordAuthentication no
UsePAM yes
Match Address 10.0.0.0/24
AllowGroups \*
KbdInteractiveAuthentication yes

Nous pouvons vérifier que notre fichier sshd_config est valide en exécutant la commande sshd -t (aucune sortie signifie OK), puis en le rechargeant avec nos modifications :

$ sudo sshd -t
$ sudo systemctl reload sshd

Configuration du Netgroup

Netgroups sont une méthode traditionnelle d’associer un compte utilisateur local à un hôte distant. Ils sont complètement distincts des groupes de comptes réguliers. Nous utiliserons les netgroups pour connecter les comptes utilisateurs locaux avec les adresses IP WireGuard distantes — par exemple, pour connecter le compte utilisateur alice sur l’Endpoint B avec l’adresse IP WireGuard de l’Endpoint A 10.0.0.1.

D’abord, nous créerons un fichier /etc/netgroup sur l’Endpoint B et ajoutons une entrée pour chaque compte utilisateur local sur l’Endpoint B que nous voulons associer à une adresse IP WireGuard distante ; en plus, nous ajouterons une entrée maître wg-users qui combine chaque groupe netgroup par utilisateur dans un groupe plus large pour tous les utilisateurs WireGuard :

# /etc/netgroup
wg-alice (10.0.0.1,alice,)
wg-bob (10.0.0.3,bob,)
wg-users wg-alice wg-bob

Chaque entrée dans le fichier /etc/netgroup spécifie un groupe netgroup distinct ; chaque entrée consiste au nom du groupe netgroup listé en premier (par exemple wg-alice), suivie des membres du groupe netgroup (comme la combinaison (10.0.0.1,alice,)) séparés par des espaces. Les membres d’un groupe netgroup peuvent être une combinaison (host,user,domain) ou ils peuvent être d’autres groupes netgroup nommés.

Nous laisserons le champ domain vide lors de la spécification de nos groupes de réseaux. Notre groupe de réseau wg-alice combine l’adresse IP WireGuard 10.0.0.1 (Point de terminaison A) avec le compte d’utilisateur alice; notre groupe de réseau wg-bob combine l’adresse IP WireGuard 10.0.0.3 (un autre hôte) avec le compte d’utilisateur bob; et notre groupe de réseau wg-users inclut les deux combinaisons ((10.0.0.1,alice,) et (10.0.0.3,bob,)).

Après avoir créé le fichier /etc/netgroup en tant que root, assurez-vous qu’il est lisible (mais pas modifiable) pour d’autres utilisateurs :

$ sudo chmod 644 /etc/netgroup

Une fois que nous avons défini nos groupes de réseau dans le fichier /etc/netgroup, nous les configurons pour être utilisés en éditant le fichier /etc/nsswitch.conf. Éditez-le et changez son entrée netgroup pour inclure files (si elle ne l’utilise pas déjà comme une source de données netgroup) :

# /etc/nsswitch.conf
...
netgroup:       files

Une fois que nous avons apporté les modifications de configuration mentionnées ci-dessus, nous pouvons interroger les membres d’un groupe réseau via la commande getent. Par exemple, nous pouvons interroger le contenu du groupe réseau wg-users pour voir qu’il contient les combinaisons suivantes d’adresses IP WireGuard et de comptes utilisateurs :

$ getent netgroup wg-users
wg-users              (10.0.0.3,bob,) (10.0.0.1,alice,)

Configuration PAM

Nous pouvons maintenant mettre à jour notre configuration PAM pour que les membres de notre groupe réseau wg-users soient authentifiés automatiquement lorsqu’ils tentent de se connecter via SSH. Nous ajouterons la règle PAM suivante au début du fichier /etc/pam.d/sshd sur le Point de terminaison B :

# /etc/pam.d/sshd
auth    sufficient    pam_succeed_if.so user innetgr wg-users
...

Cela authentifiera toute tentative de connexion à Endpoint B via SSH si l’adresse IP de l’hôte distant depuis lequel la tentative est effectuée, ainsi que le compte utilisateur qui se connecte, correspondent à une combinaison hôte+utilisateur dans notre groupe réseau wg-users. Comme nous avons utilisé le mot-clé PAM sufficient dans cette règle, si un utilisateur ne correspond pas à une combinaison hôte+utilisateur, les autres méthodes d’authentification définies dans le fichier de configuration /etc/pam.d/sshd (telles que l’authentification par clé publique SSH ou mot de passe) pourraient permettre à l’utilisateur de se connecter ; mais si la combinaison hôte+utilisateur correspond, aucune autre méthode d’authentification ne sera tentée ou requise.

Avec les groupes de réseaux définis ci-dessus, toute connexion SSH entrante à partir de l’adresse IP 10.0.0.1 qui tente de se connecter au compte utilisateur alice réussira automatiquement ; et toute connexion SSH entrante à partir de l’adresse IP 10.0.0.3 qui tente de se connecter au compte utilisateur bob réussira également automatiquement. (Mais notez que dans notre configuration WireGuard pour le Point de terminaison B ci-dessus, nous n’avons pas défini une section [Peer] avec un paramètre AllowedIPs = 10.0.0.3 — donc personne ne sera en réalité capable de se connecter au Point de terminaison B comme bob via WireGuard.)

Configuration du Pare-feu

Avec la configuration Netgroup et PAM définie ci-dessus, nous avons autorisé tout hôte utilisant une adresse IP source de 10.0.0.1 à SSH sur le Point de terminaison B en tant que l’utilisateur alice ; et avec la configuration WireGuard au début de cet article, nous avons assuré que l’initiateur de toute connexion entrante sur l’interface WireGuard du Point de terminaison B avec une adresse IP source de 10.0.0.1 légalement détient la clé privée WireGuard du Point A.

Le seul trou restant dans ce système est les autres interfaces réseau du Point de terminaison B : Si un adversaire contrôle un hôte sur le même sous-réseau LAN que le Point de terminaison B, elle pourrait établir une connexion SSH au Point de terminaison B via son interface réseau LAN en utilisant une adresse IP source spoofée choisie par elle-même — comme 10.0.0.1. De plus, si le Point de terminaison B utilisait également d’autres interfaces réseau virtuelles non-WireGuard, ces interfaces virtuelles pourraient également permettre des adresses IP sources spoofées ou dynamiques.

Nous pouvons bloquer les adresses IP source falsifiées vers d’autres interfaces sur le Point de terminaison B de deux manières :

1. Via Paramètres du noyau pour l’anti-spoofing.
2. Via Règles de pare-feu pour l’anti-spoofing.

Paramètres du noyau pour l’anti-spoofing

Si nous utilisons uniquement IPv4 et que nous ne faisons aucune route sophistiquée ou d’autres réseaux virtuels sur le Point de terminaison B, nous pouvons définir le paramètre du noyau net.ipv4.conf.all.rp_filter à 1 pour configurer le noyau Linux pour appliquer automatiquement la strict RPF (Reverse Path Forwarding) SAV (Source Address Validation) sur les paquets IPv4 qu’il reçoit. La meilleure façon de le faire est d’ajouter les lignes suivantes au fichier /etc/sysctl.conf du Point de terminaison B :

# /etc/sysctl.conf
...
net.ipv4.conf.default.rp_filter=1
net.ipv4.conf.all.rp_filter=1

Ensuite, exécutez la commande suivante sur le Point de terminaison B pour appliquer à nouveau tous les paramètres du noyau définis dans vos fichiers de configuration sysctl :

$ sudo sysctl --system

Règles de pare-feu pour l’anti-spoofing

Sinon, nous devons configurer manuellement une ou plusieurs règles de pare-feu pour bloquer tout le trafic ayant une adresse IP source dans la plage de notre réseau WireGuard (10.0.0.0/24) que l’Endpoint B n’a pas reçu via son interface WireGuard. Il existe diverses façons de faire cela ; mais avec nftables, la méthode la plus directe est d’ajouter une règle tôt dans le processus de filtrage des paquets qui vérifie l’interface et l’adresse source des paquets entrants, et de bloquer les paquets s’ils ne sont pas venus via WireGuard mais utilisent néanmoins une adresse source WireGuard :

table inet raw {
    chain prerouting {
        type filter hook prerouting priority raw; policy accept;
        # bloquer les paquets trompeurs prétendant venir via le tunnel WireGuard
        iifname != "wg0" ip saddr 10.0.0.0/24 drop
    }
}

L’équivalent iptables serait une règle comme celle-ci :

iptables -t raw -I PREROUTING ! -i wg0 -s 10.0.0.0/24 -j DROP

Alternativement, nous pourrions ajouter une règle nftables qui vérifie génériquement l’interface et l’adresse source des paquets entrants par rapport à la table de routage de Endpoint B, et si l’interface sur laquelle un paquet a été reçu n’est pas celle où les réponses seront renvoyées, bloquer le paquet :

table inet raw {
    chain prerouting {
        type filter hook prerouting priority raw; policy accept;
        # enforce strict RPF
        fib saddr . mark . iif oif missing drop
    }
}

La règle équivalente dans iptables serait quelque chose comme ceci :

iptables -t raw -I PREROUTING -m rpfilter --validmark --invert -j DROP

Cela fonctionnera bien pour bloquer la plupart des tentatives d’authentification source en spoofing (malgré ce qui peut causer des problèmes si vous faites du routage sophistiqué sur le Point de terminaison B où vous devez accepter légitimement le trafic entrant sur une interface réseau qui ne correspond pas à la meilleure route sortante).

Pour ce scénario d’article, la configuration nftables suivante est idéale pour le Point de terminaison B. Elle combine le hook de pré-routage générique ci-dessus, pour protéger contre les spoofing des adresses source ; avec la configuration nftables de base recommandée du guide Comment utiliser WireGuard avec Nftables , limitant l’accès externe au hôte aux ICMP, SSH et les connexions WireGuard ; en plus elle ajoute une règle supplémentaire pour permettre un accès complet à tous les services réseau du Point de terminaison B via le tunnel WireGuard :

#!/usr/sbin/nft -f
flush ruleset

define pub_iface = "eth0"
define wg_iface = "wg0"
define wg_port = 51822

table inet raw {
    chain prerouting {
        type filter hook prerouting priority raw; policy accept;
        # enforce strict RPF
        fib saddr . mark . iif oif missing drop
    }
}
table inet filter {
    chain input {
        type filter hook input priority 0; policy drop;

        # accept all loopback packets
        iif "lo" accept
        # accept all icmp/icmpv6 packets
        meta l4proto { icmp, ipv6-icmp } accept
        # accept all packets that are part of an already-established connection
        ct state vmap { invalid : drop, established : accept, related : accept }
        # drop new connections over rate limit
        ct state new limit rate over 1/second burst 10 packets drop

        # accept all DHCPv6 packets received at a link-local address
        ip6 daddr fe80::/64 udp dport dhcpv6-client accept
        # accept all SSH packets received on a public interface
        # (remove to block SSH except through WireGuard)
        iifname $pub_iface tcp dport ssh accept
        # accept all WireGuard packets received on a public interface
        iifname $pub_iface udp dport $wg_port accept
        # accept all packets received through the WireGuard tunnel
        iifname $wg_iface accept

        # reject with polite "port unreachable" icmp response
        reject
    }

```chain forward {
    type filter hook forward priority 0; policy drop;
    reject with icmpx type host-unreachable
}
}

Pour appliquer la configuration nftables ci-dessus, remplacez le fichier /etc/nftables.conf (ou /etc/sysconfig/nftables.conf) de Endpoint B et redémarrez ensuite le service nftables (par exemple sudo systemctl restart nftables).

Testez-le

Démarrez les interfaces WireGuard sur Endpoint A et Endpoint B (exécutez par exemple sudo wg-quick up wg0 sur les deux machines).

Ensuite, sur Endpoint A, ajoutez ce qui suit au début du fichier de configuration SSH d’Alice (~/.ssh/config) :

# ~/.ssh/config
Host wg-endpoint-b
    User alice
    Hostname 10.0.0.2
    PubkeyAuthentication no
    StrictHostKeyChecking no
    UserKnownHostsFile /tmp/known_hosts
    LocalCommand rm /tmp/known_hosts
    PermitLocalCommand yes

Cela configure un alias d’hôte pour wg-endpoint-b. Les directives User alice et Hostname 10.0.0.2 configuent SSH pour utiliser wg-endpoint-b comme alias pour alice@10.0.0.2. La directive PubkeyAuthentication no empêche SSH d’essayer l’authentification par clé publique SSH. Les autres directives travaillent ensemble pour ignorer la clé d’hôte fournie par Endpoint B (car nous allons plutôt compter sur la clé WireGuard d’Endpoint B pour authentifier la connexion à Endpoint B), et pour éviter de polluer le fichier known_hosts habituel d’Alice avec des entrées inutilisées provenant d’Endpoint B.

Spécifiquement, la directive StrictHostKeyChecking no instructe SSH d’accepter toutes les nouvelles clés d’hôte SSH de l’Endpoint B et d’ajouter automatiquement ces clés à le fichier known_hosts d’Alice. La directive UserKnownHostsFile /tmp/known_hosts instructe SSH d’utiliser /tmp/known_hosts au lieu de ~/.ssh/known_hosts comme le fichier known_hosts d’Alice pour l’Endpoint B. La directive LocalCommand rm /tmp/known_hosts instructe SSH de supprimer le fichier /tmp/known_hosts après chaque authentification réussie avec l’Endpoint B. Et la directive PermitLocalCommand yes active l’utilisation du LocalCommand.

Après avoir mis à jour le fichier de configuration SSH d’Alice, exécutez la commande suivante en tant qu’Alice sur l’Endpoint A :

$ ssh wg-endpoint-b
Warning: Permanently added '10.0.0.2' (ED25519) to the list of known hosts.
Last login: Sat Feb  3 12:25:32 2024 from 198.51.100.1
alice@bee:~$

Cela devrait se connecter à l’Endpoint B et s’authentifier Alice automatiquement, sans demander de mot de passe.

Dépannage

Si cela ne fonctionne pas, vérifiez les journaux SSH sur l’Endpoint B. Si l’Endpoint B utilise systemd, vous pouvez utiliser la commande journalctl -u sshd pour les afficher. Voici ce que devrait ressembler une authentification réussie :

$ journalctl -u sshd -e
...
fév 03 23:15:15 bee sshd[47919]: pam_succeed_if(sshd:auth): requirement "user innetgr wg-users" was met by user "alice"
fév 03 23:15:15 bee sshd[47893]: Accepted keyboard-interactive/pam for alice from 10.0.0.1 port 58164 ssh2
fév 03 23:15:15 bee sshd[47893]: pam_unix(sshd:session): session opened for user alice(uid=1001) by alice(uid=0)

Vous pourriez également trouver plus d’informations dans les journaux d’authentification complets sur le Point de terminaison B. Si le Point de terminaison B utilise systemd, vous pouvez utiliser la commande journalctl --facility auth pour les afficher. Voici ce que devrait ressembler une authentification réussie (sur un système exécutant SELinux) :

$ journalctl --facility auth -e
...
fév 03 23:15:14 bee audit[47903]: CRYPTO_KEY_USER pid=47903 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 msg='op=destroy kind=server fp=SHA256:18:92:11:a8:e5:d6:e0:f4:b3:52:37:69:5c:64:28:81:2e:2c:7e:a0:41:1a:43:24:98:0a:6b:6d:d9:22:66:29 direction=? spid=47903 suid=0  exe="/usr/sbin/sshd" hostname=? addr=10.0.0.1 terminal=? res=success'
fév 03 23:15:15 bee audit[47893]: CRYPTO_SESSION pid=47893 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 msg='op=start direction=from-server cipher=chacha20-poly1305@openssh.com ksize=512 mac=<implicit> pfs=curve25519-sha256 spid=47903 suid=74 rport=58164 laddr=10.0.0.2 lport=22  exe="/usr/sbin/sshd" hostname=? addr=10.0.0.1 terminal=? res=success'
fév 03 23:15:15 bee audit[47893]: CRYPTO_SESSION pid=47893 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 msg='op=start direction=from-server cipher=chacha20-poly1305@openssh.com ksize=512 mac=<implicit> pfs=curve25519-sha256 spid=47903 suid=74 rport=58164 laddr=10.0.0.2 lport=22  exe="/usr/sbin/sshd" hostname=? addr=10.0.0.1 terminal=? res=success'
fév 03 23:15:15 bee audit[47893]: CRYPTO_KEY_USER pid=47893 uid=0 auid=1001 ses=5 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 msg='op=destroy kind=server fp=SHA256:18:92:11:a8:e5:d6:e0:f4:b3:52:37:69:5c:64:28:81:2e:2c:7e:a0:41:1a:43:24:98:0a:6b:6d:d9:22:66:29 direction=? spid=47936 suid=0  exe="/usr/sbin/sshd" hostname=? addr=10.0.0.1 terminal=? res=success'
fév 03 23:15:15 bee audit[47936]: CRED_ACQ pid=47936 uid=0 auid=1001 ses=5 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 msg='op=PAM:setcred grantors=pam_env,pam_localuser,pam_unix acct="alice" exe="/usr/sbin/sshd" hostname=10.0.0.1 addr=10.0.0.1 terminal=ssh res=success'
fév 03 23:15:15 bee audit[47893]: USER_LOGIN pid=47893 uid=0 auid=1001 ses=5 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 msg='op=login id=1001 exe="/usr/sbin/sshd" hostname=? addr=10.0.0.1 terminal=/dev/pts/3 res=success'
fév 03 23:15:15 bee audit[47893]: USER_START pid=47893 uid=0 auid=1001 ses=5 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 msg='op=login id=1001 exe="/usr/sbin/sshd" hostname=? addr=10.0.0.1 terminal=/dev/pts/3 res=success'
fév 03 23:15:15 bee audit[47893]: CRYPTO_KEY_USER pid=47893 uid=0 auid=1001 ses=5 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 msg='op=destroy kind=server fp=SHA256:18:92:11:a8:e5:d6:e0:f4:b3:52:37:69:5c:64:28:81:2e:2c:7e:a0:41:1a:43:24:98:0a:6b:6d:d9:22:66:29 direction=? spid=47937 suid=1001  exe="/usr/sbin/sshd" hostname=? addr=10.0.0.1 terminal=? res=success'
fév 03 23:15:15 bee audit: BPF prog-id=78 op=LOAD
fév 03 23:15:15 bee audit: BPF prog-id=79 op=LOAD
fév 03 23:15:15 bee audit: BPF prog-id=80 op=LOAD
fév 03 23:15:15 bee audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=systemd-hostnamed comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'

Si rien ne s’affiche dans les journaux d’authentification sur le Point de terminaison B, essayez d’utiliser l’option SSH -vvv sur le Point de terminaison A lors de la connexion. Une authentification réussie devrait ressembler à ceci :

$ ssh -vvv wg-endpoint-b
OpenSSH_8.4p1 Ubuntu-0ubuntu0.20.04, OpenSSL 1.1.1f  31 Mar 2020
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to 10.0.0.2 port 22.
debug1: Connection established.
debug1: identity file /home/user/.ssh/id_rsa type -1
debug1: identity file /home/user/.ssh/id_rsa-cert type -1
debug1: identity file /home/user/.ssh/id_dsa type -1
debug1: identity file /home/user/.ssh/id_dsa-cert type -1
debug1: identity file /home/user/.ssh/id_ecdsa type -1
debug1: identity file /home/user/.ssh/id_ecdsa-cert type -1
debug1: identity file /home/user/.ssh/id_ed25519 type 3
debug1: identity file /home/user/.ssh/id_ed25519-cert type -1
debug1: identity file /home/user/.ssh/id_xmss type -1
debug1: identity file /home/user/.ssh/id_xmss-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_8.4p1 Ubuntu-0ubuntu0.20.04
debug1: Remote protocol version 2.0, remote software version OpenSSH_8.2p1 Ubuntu-4ubuntu0.5
debug1: match: OpenSSH_8.2p1 Ubuntu-4ubuntu0.5 pat OpenSSH* compat 0x04000000
debug1: Authenticating to 10.0.0.2:22 as 'user'
debug1: load_hostkeys: loading entries for host 10.0.0.2 from /home/user/.ssh/known_hosts
debug1: load_hostkeys: found key type ED25519 in /home/user/.ssh/known_hosts:1
debug1: load_hostkeys: loaded 1 keys from 10.0.0.2
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256
debug1: kex: host key algorithm: ssh-ed25519
debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ssh-ed25519 SHA256:GJIRqOXW4PSzUjdpXGQogS4sfqBBGkMkmAprbdkiZik
debug1: load_hostkeys: loading entries for host 10.0.0.2 from /home/user/.ssh/known_hosts
debug1: load_hostkeys: found key type ED25519 in /home/user/.ssh/known_hosts:1
debug1: load_hostkeys: loaded 1 keys from 10.0.0.2
debug1: Host '10.0.0.2' is known and matches the ED25519 host key.
debug1: Found matching host key in /home/user/.ssh/known_hosts:1
debug1: rekey out after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey in after 134217728 blocks
debug1: Entering interactive session.
Last login: Sat Feb  3 22:38:59 2024 from 10.0.0.1

Bonus: Telnet

Avant SSH, Telnet était la méthode la plus courante pour se connecter au réseau à un ordinateur. Sur la plupart des systèmes Linux modernes, vous pouvez toujours installer un serveur Telnet via un paquet nommé telnetd ou telnet-server, et un client Telnet via un paquet nommé telnet ou telnet-client.

Sur la plupart des distributions, le serveur Telnet fonctionne en tant qu’un unité de socket systemd — donc après l’installation du serveur Telnet, vous pouvez le démarrer et l’arrêter via l’unité telnet.socket. Nous pouvons vérifier qu’il fonctionne en examinant la sortie de la commande ss -ptunl (recherchez le port TCP 23) :

$ sudo dnf install -qy telnet-server
Installed:
  telnet-server-1:0.17-90.fc39.x86_64
$ sudo systemctl start inetd
$ sudo ss -ptunl
Netid  State   Recv-Q  Send-Q   Local Address:Port      Peer Address:Port  Process
udp    UNCONN  0       0        127.0.0.53%lo:53             0.0.0.0:*      users:(("systemd-resolve",pid=689,fd=17))
udp    UNCONN  0       0              0.0.0.0:51822          0.0.0.0:*
udp    UNCONN  0       0            127.0.0.1:323            0.0.0.0:*      users:(("chronyd",pid=735,fd=5))
tcp    LISTEN  0       128            0.0.0.0:22             0.0.0.0:*      users:(("sshd",pid=967,fd=3))
tcp    LISTEN  0       4096           0.0.0.0:23             0.0.0.0:*      users:(("inetd",pid=1,fd=54))
tcp    LISTEN  0       4096     127.0.0.53%lo:53             0.0.0.0:*      users:(("systemd-resolve",pid=689,fd=18))

Sur d’autres distributions, le serveur Telnet peut s’exécuter sous le démon générique inetd — donc après l’installation du serveur Telnet, vous pouvez démarrer et arrêter le service inetd (et le configurer via le fichier /etc/inetd.conf).

$ sudo apt-get -qq install telnetd
$ sudo systemctl start inetd
$ sudo ss -ptunl
Netid  State    Recv-Q   Send-Q      Local Address:Port      Peer Address:Port  Process
udp    UNCONN   0        0           127.0.0.53%lo:53             0.0.0.0:*      users:(("systemd-resolve",pid=2906,fd=11))
udp    UNCONN   0        0                 0.0.0.0:51822          0.0.0.0:*
tcp    LISTEN   0        128               0.0.0.0:22             0.0.0.0:*      users:(("sshd",pid=123375,fd=3))
tcp    LISTEN   0        128               0.0.0.0:23             0.0.0.0:*      users:(("inetd",pid=176367,fd=4))
tcp    LISTEN   0        4096        127.0.0.53%lo:53             0.0.0.0:*      users:(("systemd-resolve",pid=2906,fd=12))

Pour activer l’authentification par clé publique WireGuard avec Telnet, commencez par la même configuration WireGuard, Netgroup Configuration et Configuration du pare-feu sur le Point de terminaison B que nous avons configuré ci-dessus — mais nous devons également apporter quelques ajustements de configuration supplémentaires, comme ceux montrés ci-dessous.

Configuration PAM

Pour Telnet, nous configurons PAM de manière similaire à ce que nous avons fait pour SSH, mais nous devons configurer un fichier différent (pas le fichier /etc/pam.d/sshd). Sur certaines distributions, cela peut être le fichier /etc/pam.d/remote. Si votre distribution n’a pas ce fichier, essayez plutôt le fichier /etc/pam.d/login. Ajoutez ce qui suit au début de celui-ci :

# /etc/pam.d/remote
auth    sufficient    pam_succeed_if.so user innetgr wg-users
...

C’est la même ligne que nous avons ajoutée au fichier /etc/pam.d/sshd dans la section de configuration PAM ci-dessus, et elle fonctionnera de la même manière : Elle authentifiera automatiquement les membres du groupe wg-users lorsqu’ils se connecteront à Endpoint B via WireGuard.

Configuration des hôtes

La seule chose qui fonctionnera différemment avec Telnet est que le serveur Telnet essayera automatiquement de faire une recherche inverse d’hôte sur l’adresse IP source utilisée pour la connexion. Ainsi, lorsque nous nous connectons à travers WireGuard depuis Endpoint A (avec une adresse IP de 10.0.0.1), Endpoint B essaiera de faire une recherche inverse d’hôte sur 10.0.0.1, et utilisera les résultats de cette recherche pour déterminer au quel groupe l’utilisateur connectant appartient.

Pour éviter de faire confiance à cette recherche DNS, nous allons configurer le fichier /etc/hosts sur Endpoint B pour fournir un nom d’hôte privé et conceptuel pour chaque adresse IP WireGuard dans notre réseau WireGuard. Éditez le fichier /etc/hosts sur Endpoint B pour ajouter ce qui suit à la fin du fichier :

# /etc/hosts
...
10.0.0.1 alice-laptop.private
10.0.0.3 bob-workstation.private

La configuration ci-dessus assurera que lorsque Endpoint B recherche le nom d’hôte pour 10.0.0.1 (l’adresse IP WireGuard de Endpoint A), il obtiendra alice-laptop.private; et si il recherche le nom d’hôte pour 10.0.0.3 (une adresse IP WireGuard que nous pourrions utiliser à l’avenir pour la station de travail de Bob), elle résoudra en bob-workstation.private.

Configuration du groupe

Avec ces noms d’hôtes virtuels ajoutés au fichier /etc/hosts, retournez et éditez le fichier /etc/netgroup sur le Point de terminaison B pour les utiliser. Ajoutez une combinaison (alice-laptop.private,alice,) au groupe wg-alice, et une entrée (bob-workstation.private,bob,) au groupe wg-bob :

# /etc/netgroup
wg-alice (10.0.0.1,alice,) (alice-laptop.private,alice,)
wg-bob (10.0.0.3,bob,) (bob-workstation.private,bob,)
wg-users wg-alice wg-bob

Maintenant, si nous exécutons la commande getent, nous verrons les nouveaux hôtes associés à Alice et Bob — le hôte alice-laptop.private avec l’utilisateur alice, et le hôte bob-workstation.private avec l’utilisateur bob :

$ getent netgroup wg-users
wg-users              (10.0.0.3,bob,) (bob-workstation.private,bob,) (10.0.0.1,alice,) (alice-laptop.private,alice,)

Lorsque Alice se connecte via Telnet en tant qu’utilisateur alice depuis le Point de terminaison A à travers sa connexion WireGuard, le serveur Telnet sur le Point de terminaison B effectuera une recherche inverse sur son adresse IP WireGuard de 10.0.0.1, et produira le nom d’hôte alice-laptop.private. Lorsque PAM vérifie le groupe wg-users, il trouvera la combinaison (alice-laptop.private,alice,) dans celui-ci et authentifiera cette connexion.

Tester Telnet

Pour tester cela, exécutez la commande telnet -l alice 10.0.0.2 depuis le Point de terminaison A :

$ telnet -l alice 10.0.0.2
Connected to 10.0.0.2

Entering character mode
Escape character is '^]'.

Last login: Sat Feb  3 23:44:19 from 10.0.0.1
alice@bee:~$

Nous devrions être automatiquement connectés en tant qu’Alice sur le Point de terminaison B sans être invité à entrer un mot de passe.

Si cela ne fonctionne pas, vérifiez les journaux du système sur le Point de terminaison B pour l’identifiant login. C’est ce que devrait ressembler une connexion réussie :

$ journalctl -t login -e
...
Feb 04 00:38:57 bee login[118032]: pam_succeed_if(remote:auth): requirement "user innetgr wg-users" was met by user "alice"
Feb 04 00:38:57 bee login[118032]: pam_unix(remote:session): session opened for user alice(uid=1001) by alice(uid=0)
Feb 04 00:38:57 bee login[118032]: LOGIN ON pts/3 BY alice FROM alice-laptop.private

Bonus : FTP

Comme nous avons configuré un serveur Telnet sur le Point de terminaison B en remplacement de l’accès terminal SSH, nous pouvons également configurer un serveur FTP en remplacement de SCP, permettant la copie de fichiers entre le Point de terminaison A et B. Il existe plusieurs serveurs FTP modernes que nous pourrions installer sur le Point de terminaison B ; nous utiliserons ProFTPD (car il prend en charge PAM et inclut les informations d’hôte distant correctes pour ses vérifications d’authentification).

Sur la plupart des distributions, il peut être installé via un paquet nommé proftpd (ou proftpd-core) et fonctionnera comme son propre démon proftpd.

$ sudo dnf install -qy proftpd
Installed:
  libmemcached-awesome-1.1.4-2.fc39.x86_64 proftpd-1.3.8b-1.fc39.x86_64
$ sudo systemctl start proftpd
$ sudo ss -ptunl
Netid  State   Recv-Q  Send-Q   Local Address:Port      Peer Address:Port  Process
udp    UNCONN  0       0        127.0.0.53%lo:53             0.0.0.0:*      users:(("systemd-resolve",pid=689,fd=17))
udp    UNCONN  0       0              0.0.0.0:51822          0.0.0.0:*
udp    UNCONN  0       0            127.0.0.1:323            0.0.0.0:*      users:(("chronyd",pid=735,fd=5))
tcp    LISTEN  0       9              0.0.0.0:21             0.0.0.0:*      users:(("proftpd",pid=176118,fd=0))
tcp    LISTEN  0       128            0.0.0.0:22             0.0.0.0:*      users:(("sshd",pid=967,fd=3))
tcp    LISTEN  0       4096           0.0.0.0:23             0.0.0.0:*      users:(("systemd",pid=1,fd=54))
tcp    LISTEN  0       4096     127.0.0.53%lo:53             0.0.0.0:*      users:(("systemd-resolve",pid=689,fd=18))

Pour activer l’authentification à clé publique WireGuard avec ProFTPD, nous utiliserons la même configuration WireGuard, Netgroup Configuration et Configuration du pare-feu sur le Point de terminaison B que nous avons configurée pour SSH. Nous (peut-être) n’aurons besoin que de modifier la configuration PAM pour FTP, comme montré ci-dessous.

Configuration FTP

Le fichier de configuration principal de ProFTPD est généralement situé à /etc/proftpd.conf ou /etc/proftpd/proftpd.conf. Par défaut, il devrait être configuré pour utiliser l’authentification PAM et ne pas effectuer des recherches inverses d’hôtes. Si ce n’est pas le cas, ajoutez les paramètres suivants à la configuration de ProFTPD et redémarrez (sudo systemctl restart proftpd):

# /etc/proftpd.conf
...
AuthPAM on
AuthPAMConfig proftpd
AuthOrder mod_auth_pam.c* mod_auth_unix.c
UseReverseDNS off

Configuration PAM

Pour ProFTPD, nous utiliserons également une configuration similaire Configuration PAM comme avec SSH, mais nous devons à nouveau configurer un fichier différent — dans ce cas, le fichier /etc/pam.d/proftpd. Ajoutez ce qui suit au début de ce fichier :

# /etc/pam.d/proftpd
auth    sufficient    pam_succeed_if.so user innetgr wg-users
...

Tester FTP

Pour tester cela, exécutez la commande ftp alice@10.0.0.2 à partir du Point de terminaison A :

$ ftp alice@10.0.0.2
Connected to 10.0.0.2.
220 FTP Server ready.
331 Password required for alice
Password:
230 User alice logged in
Remote system type is UNIX.
Using binary mode to transfer files.
ftp>

Nous devrions être automatiquement connectés en tant qu’Alice sur le Point de terminaison B ; si on est invité à entrer un mot de passe, simplement entrez un mot de passe vide.

Pour éviter les invites de mot de passe avec le client FTP standard en ligne de commande, ajoutez ce qui suit au fichier ~/.netrc d’Alice sur le Point de terminaison A :

# ~/.netrc
machine 10.0.0.2 login alice password none

Nous devrions alors pouvoir nous connecter au Point de terminaison B sans prompts en exécutant ftp 10.0.0.2 à partir du Point de terminaison A :

$ ftp 10.0.0.2
Connected to 10.0.0.2.
220 FTP Server ready.
331 Password required for alice
230 User alice logged in
Remote system type is UNIX.
Using binary mode to transfer files.
ftp>

Si vous rencontrez des problèmes, vérifiez les journaux ProFTPD sur le Point de terminaison B. Voici ce qu’une connexion réussie devrait ressembler :

$ journalctl -u proftpd -e
...
Feb 04 01:50:20 bee proftpd[177215]: session[177215] 203.0.113.2 (10.0.0.1[10.0.0.1]): FTP session opened.
Feb 04 01:50:20 bee proftpd[177215]: pam_succeed_if(proftpd:auth): requirement "user innetgr wg-users" was met by user "alice"
Feb 04 01:50:20 bee proftpd[177215]: pam_unix(proftpd:session): session opened for user alice(uid=1001) by alice(uid=0)
Feb 04 01:50:20 bee proftpd[177215]: session[177215] 203.0.113.2 (10.0.0.1[10.0.0.1]): USER alice: Login successful.

Bonus : RSH

Rlogin (et ses programmes associés comme RSH, RCP et Rexec) étaient des versions plus modernes de Telnet et FTP utilisées dans les années 80 et 90, avant que SSH ne remplace tous ceux-ci. Aujourd’hui, la plupart de ces commandes “R” ne sont pas bien maintenues (car elles ont des problèmes fondamentaux de sécurité intégrés à leur conception), et devraient être évitées en préférence à SSH (ou Telnet & FTP via une connexion sécurisée, comme WireGuard).

Mais vous pouvez toujours installer les programmes serveur et client sur de nombreuses distributions Linux actuelles et utiliser WireGuard pour les exécuter en toute sécurité. Sur la plupart des distributions, vous pouvez installer un paquet dédié rsh-server qui comprendra les serveurs Rexec, Rlogin et RSH ; sur d’autres distributions, ils peuvent être inclus dans un plus grand paquet inetutils qui contient la plupart des GNU Inetutils. (Nous allons ignorer le serveur Rexec, car il ne prend en charge que l’authentification par mot de passe — plus il ne fait rien que RSH lui-même ne peut pas faire.)

Sur la plupart des distributions, ces serveurs s’exécutent comme une unité de socket systemd — donc après leur installation, nous pouvons démarrer et arrêter le serveur Rlogin via l’unité rlogin.socket, et le serveur RSH via l’unité rsh.socket. Nous pouvons vérifier qu’ils fonctionnent en examinant la sortie de la commande ss -ptunl (recherchez les ports TCP 513 et 514) :

$ sudo dnf install -qy rsh-server
Installed:
  rsh-server-0.17-106.fc39.x86_64
$ sudo systemctl start inetd
$ sudo systemctl stop inetd
$ sudo ss -ptunl
Netid  State   Recv-Q  Send-Q   Local Address:Port      Peer Address:Port  Process
udp    UNCONN  0       0        127.0.0.53%lo:53             0.0.0.0:*      users:(("systemd-resolve",pid=689,fd=17))
udp    UNCONN  0       0              0.0.0.0:51822          0.0.0.0:*
udp    UNCONN  0       0            127.0.0.1:323            0.0.0.0:*      users:(("chronyd",pid=735,fd=5))
tcp    LISTEN  0       128            0.0.0.0:22             0.0.0.0:*      users:(("sshd",pid=967,fd=3))
tcp    LISTEN  0       4096           0.0.0.0:513            0.0.0.0:*      users:(("inetd",pid=1234,fd=54))
tcp    LISTEN  0       4096           0.0.0.0:514            0.0.0.0:*      users:(("inetd",pid=1234,fd=55))
tcp    LISTEN  0       4096     127.0.0.53%lo:53             0.0.0.0:*      users:(("systemd-resolve",pid=689,fd=18))

Sur d’autres distributions, ces serveurs peuvent s’exécuter sous le démon générique inetd — donc après l’installation des serveurs, nous pouvons les démarrer et arrêter en démarrant et en arrêtant le service inetd. Le serveur Rexec écoute sur le port TCP 512, le serveur Rlogin écoute sur le port TCP 513, et le serveur RSH écoute sur le port TCP 514 :

$ sudo apt-get -qq install rsh-server
$ sudo systemctl start inetd
$ sudo ss -ptunl
Netid  State    Recv-Q   Send-Q      Local Address:Port      Peer Address:Port  Process
udp    UNCONN   0        0           127.0.0.53%lo:53             0.0.0.0:*      users:(("systemd-resolve",pid=2906,fd=11))
udp    UNCONN   0        0                 0.0.0.0:51822          0.0.0.0:*
tcp    LISTEN   0        128               0.0.0.0:22             0.0.0.0:*      users:(("sshd",pid=123375,fd=3))
tcp    LISTEN   0        128               0.0.0.0:514            0.0.0.0:*      users:(("inetd",pid=176367,fd=8))
tcp    LISTEN   0        128               0.0.0.0:513            0.0.0.0:*      users:(("inetd",pid=176367,fd=9))
tcp    LISTEN   0        128               0.0.0.0:512            0.0.0.0:*      users:(("inetd",pid=176367,fd=10))
tcp    LISTEN   0        4096        127.0.0.53%lo:53             0.0.0.0:*      users:(("systemd-resolve",pid=2906,fd=12))

Pour activer l’authentification par clé publique WireGuard avec Rlogin et RSH, nous utiliserons la même Configuration WireGuard et Configuration du pare-feu sur le Point de terminaison B que nous avons configurés pour SSH — mais au lieu d’utiliser les groupes netgroups, nous utiliserons la Configuration Rhosts pour associer les adresses IP WireGuard aux utilisateurs.

Configuration Rhosts

L’authentification traditionnelle Rlogin repose sur le fichier ~/.rhosts dans chaque dossier personnel d’utilisateur (conçue de manière similaire au fichier ~/.ssh/authorized_keys utilisé par l’authentification à clé publique SSH). Pour permettre à Alice de se connecter automatiquement avec Rlogin via WireGuard depuis le Point de terminaison A (avec une adresse IP WireGuard de 10.0.0.1), ajoutez l’entrée suivante au fichier ~/.rhosts d’Alice sur le Point de terminaison B :

# /home/alice/.rhosts
10.0.0.1 +

La première partie de l’entrée (10.0.0.1) est l’hôte distant ; la deuxième partie de l’entrée est le compte utilisateur sur cet hôte distant (`). Le symbole est un joker — nous utilisons un joker pour le compte utilisateur, car cela n'affecte pas la sécurité (toute personne utilisant rlogin peut prétendre utiliser tout compte utilisateur distant). Ce qui importe dans notre scénario est l'hôte : l'adresse IP10.0.0.1` ne peut pas être falsifiée, grâce à la Configuration WireGuard et à la Configuration du Pare-feu que nous avons configurées ci-dessus.

# /home/alice/.rhosts
alice-laptop.private +

$ sudo chown alice /home/alice/.rhosts && sudo chmod 600 /home/alice/.rhosts

$ sudo restorecon /home/alice/.rhosts

Test Rlogin

Les programmes clients Rlogin, RSH et autres « commandes R » font partie de différents paquets sur différentes distributions — essayer les paquets rsh-client, rsh ou inetutils. Installez le paquet approprié avec les programmes clients sur les deux Endpoint A et Endpoint B.

Ensuite, exécutez la commande rlogin -l alice 10.0.0.2 depuis Endpoint A :

$ rlogin -l alice 10.0.0.2
Dernière connexion : dim. 4 févr. 2023 05:02:32 UTC depuis 10.0.0.1
alice@bee:~$

Nous devrions être automatiquement connectés à une session de terminal sur Endpoint B en tant qu’Alice (similaire au Telnet), sans être invité à entrer un mot de passe.

Si cela ne fonctionne pas, vérifiez les journaux système sur Endpoint B pour l’identifiant rlogind. Voici ce que devrait ressembler une connexion réussie :

$ journalctl -t rlogind -e
04 févr. 2023 05:07:24 UTC bee rlogind[340100]: pam_rhosts(rlogin:auth): accès autorisé à ally@10.0.0.1 en tant qu'Alice

Test RSH

Tandis que la commande client rlogin fournit un terminal interactif (comme la commande telnet ou la commande ssh sans commande distante), la commande client rsh exécute simplement une commande distante et affiche les résultats.

Essayez d’exécuter la commande suivante à partir de l’Endpoint A (qui exécute le commandement hostname de manière distante sur l’Endpoint B) :

$ rsh -l alice 10.0.0.2 hostname
bee

Si cela ne fonctionne pas, vérifiez les journaux système de l’Endpoint B pour l’identifiant rshd. Voici ce que devrait ressembler une commande RSH réussie :

$ journalctl -t rshd -e
Feb 04 06:09:34 bee rshd[392565]: pam_rhosts(rsh:auth): allowed access to ally@10.0.0.1 as alice
Feb 04 06:09:35 bee rshd[392565]: pam_unix(rsh:session): session opened for user alice(uid=1001) by alice(uid=0)
Feb 04 06:09:35 bee rshd[392565]: pam_unix(rsh:session): session closed for user alice

$ rsh -l alice 10.0.0.2
Last login: Sun Feb 4 05:07:24 from 10.0.0.1
alice@bee:~$

Tester RCP

Le client de commande rcp utilise également le service RSH. Nous pouvons tester cela en créant un fichier foo.txt à distance sur le Point de terminaison B, puis en copiant ce fichier localement vers le Point de terminaison A :

$ rsh -l alice 10.0.0.2 'echo foo > foo.txt'
$ rsh -l alice 10.0.0.2 cat foo.txt
foo
$ rcp alice@10.0.0.2:foo.txt .
$ cat foo.txt
foo

bash: line 1: rcp: command not found

Tester Rsync

Rsync est maintenu séparément des autres « commandes R » (et il est généralement installé dans son propre package rsync) ; et les versions modernes de Rsync utilisent SSH comme transport par défaut — mais initialement, Rsync utilisait RSH. Nous pouvons toujours faire utiliser Rsync RSH via le drapeau -e (par exemple rsync -e rsh).

Nous pouvons tester cela en créant un répertoire bar contenant certains fichiers à distance sur le Point de terminaison B, puis en synchronisant ce répertoire localement vers le Point de terminaison A :

$ rsh -l alice 10.0.0.2 mkdir bar
$ rsh -l alice 10.0.0.2 'echo baz > bar/baz.txt'
$ rsh -l alice 10.0.0.2 'echo qux > bar/qux.txt'
$ rsync -e rsh -av alice@10.0.0.2:bar/ bar/
receiving incremental file list
created directory bar
./
baz.txt
qux.txt

```markdown
Envié 65 octets  reçu 202 octets  178.00 octets/sec
taille totale est 8  accélération est 0.03
$ ls bar
baz.txt  qux.txt

2/11/2024

par Justin Ludwig

• WireGuard
• Réseautage
• SSH
• Clés