kein SSH login in einen Clone?

dieoma

New Member
Sep 3, 2025
9
0
1
Hallo zusammen,

ich habe Proxmox in der 8.4.0 Version installiert und zuletzt einen Clone einer Ubuntu Bookworm gemacht. Ich habe danach die VM editiert damit ich keinen IP Konflikt bekomme. Ich kann die VM vom Host und anderen Gästen prima anpingen. Ein SSH Login funktioniert hingegen von extern nicht: "Connection refused". Ein ssh localhost hingegen klappt - der SSH Server läuft also prinzipiell. Ich habe auch meine Keys händisch gelöscht und einen dpkg-reconfigure laufen lassen - der zeigt dann dieses:

1756900609558.png

Hat jemand da eine Idee?
Besten Dank
Markus
 
Hallo Markus,
was ist das Ergebnis von ss -tapen | grep :22
auf dem Host wo der ssh-server läuft?

Kannst du dein sshd-config mal anhängen (falls nötig an den entsprechenden Stellen geschwärzt)?
cat /etc/ssh/sshd_config
cat /etc/ssh/sshd_config.d/*

Was ist der Stdout den du bekommst, wenn du deine Verbindung von außerhalb aufbaust? ssh <target>
Probier gerne auch mal die Variant ssh -vvv <target>
Für das entsprechende Verbosity Level.

BG, Lucas
 
In der VNC Console ist der | nicht so ohne aber im Screenshot siehst du, das der Port auf den SSH gemappt ist:

1756912071784.png
sshd_config ist default:
1756912401899.png

und das Verzeichnis sshd_config.d/ ist leer.

Hier der Output von ssh -vvv:
Code:
markus@MacMini ~ % ssh -vvv 192.168.1.103
OpenSSH_9.9p2, LibreSSL 3.3.6
debug1: Reading configuration data /Users/markus/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 21: include /etc/ssh/ssh_config.d/* matched no files
debug1: /etc/ssh/ssh_config line 54: Applying options for *
debug2: resolve_canonicalize: hostname 22 is address
debug2: resolve_canonicalize: canonicalised address "22" => "0.0.0.22"
debug3: expanded UserKnownHostsFile '~/.ssh/known_hosts' -> '/Users/markus/.ssh/known_hosts'
debug3: expanded UserKnownHostsFile '~/.ssh/known_hosts2' -> '/Users/markus/.ssh/known_hosts2'
debug1: Authenticator provider $SSH_SK_PROVIDER did not resolve; disabling
debug3: channel_clear_timeouts: clearing
debug3: ssh_connect_direct: entering
debug1: Connecting to 0.0.0.22 [0.0.0.22] port 22.
debug3: set_sock_tos: set socket 3 IP_TOS 0x48
debug1: connect to address 0.0.0.22 port 22: No route to host
ssh: connect to host 0.0.0.22 port 22: No route to host
markus@MacMini ~ %

Mache ich eine SSH Session auf den Proxmox Host selbst und von dort ssh in den Gast komme ich exakt ein mal rein, aber ein einfacher druck auf die Enter Taste lässt die Verbindung abreißen und auch nicht wieder aufbauen. Siehe hier:

Code:
root@proxy:~# ssh -l markus 192.168.1.103
The authenticity of host '192.168.1.103 (192.168.1.103)' can't be established.
ED25519 key fingerprint is SHA256:blablablaganzgeheimundso.
This key is not known by any other names.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '192.168.1.103' (ED25519) to the list of known hosts.
markus@192.168.1.103's password:
Linux lyrion-frederick 6.1.0-37-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.140-1 (2025-05-22) x86_64

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Wed Sep  3 17:51:08 2025 from ::1
markus@lyrion-frederick:~$ Read from remote host 192.168.1.103: Connection reset by peer
Connection to 192.168.1.103 closed.
client_loop: send disconnect: Broken pipe
root@proxy:~# ssh -l markus 192.168.1.103
ssh: connect to host 192.168.1.103 port 22: Connection refused
root@proxy:~#

Ich bin ziemlich sicher, dass es etwas damit zu tun hat das ich die VM geclont habe. Hat jemand eine Idee?
 
Last edited:
Also auf den ersten Blick sieht die SSHD-config normal aus. Das leere Verzeichnis
Code:
/etc/ssh/sshd_config.d/
ist der default.

Da du die VM geklont hast, und ein Brocken pipe kommt, vorab die kurze Frage hast du die IP-Addressen statisch vergeben und ggf. nicht angepasst, während beide VMs im selben Layer-2 Netz laufen?
Beim Klonen via GUI und qm-tool werden die Mac Addressen der virtuellen Netzwerkdevices automatisch angepasst.
Falls du das Klonen anders bewerkstelligt hast, könnte das ebenfalls eine Ursache für die Verbindungsabbrüche sein.

----
Anonsten läuft auch irgendetwas "untendrunter" im Netzwerkstack anscheinend nicht ganz sauber
debug2: resolve_canonicalize: hostname 22 is address<br>
debug2: resolve_canonicalize: canonicalised address "22" =&gt; "0.0.0.22"
"0.0.0.22" ist kein gültiger Name für eine Zieladdressauflösung.

Prüfe ggf. mal die Arp-Tabellen auf dem Hypervisor und deinem Remote Host
Code:
cat /proc/net/arp
Ob dort innerhalb von kurzer Zeit Einträge toggeln.

Falls sich dein Problem nicht in den ersten beiden Fragen beantwortet hat, prüfe ansonsten mal die folgenden Files auf dem MacMini Client auf Anomalien:
/etc/hosts <- hier dürfte nichts besonderes drin stehen, weil du als Zieladdresse eine IP und keinen Hostnamen verwendest
/Users/markus/.ssh/config <- das ist die verwendete user spezifische config
/etc/ssh/ssh_config <- das ist die verwendete default config

GGf. finden sich dort Einträge die unvollständig oder inkorrekt sind.

BG, Lucas
 
Danke für eure Rückmeldungen. Ich antworte mal der Reihe nach:

Code:
markus@MacMini ~ % tail -n+1 ~/.ssh/config /etc/ssh/ssh_config
==> /Users/markus/.ssh/config <==
Host volumio
  HostName volumio

Host plexi
  HostName plexi
  User markus


Host assi
  HostName 192.168.1.166
  HostKeyAlgorithms=+ssh-dss

Host proxy
  HostName 192.168.1.11
  HostKeyAlgorithms=+ssh-dss

Host assi
  HostName 192.168.1.100
  HostKeyAlgorithms=+ssh-dss

Host lyrion
  HostName 192.168.1.101
  HostKeyAlgorithms=+ssh-rsa

==> /etc/ssh/ssh_config <==
#    $OpenBSD: ssh_config,v 1.36 2023/08/02 23:04:38 djm Exp $

# This is the ssh client system-wide configuration file.  See
# ssh_config(5) for more information.  This file provides defaults for
# users, and the values can be changed in per-user configuration files
# or on the command line.

# Configuration data is parsed as follows:
#  1. command line options
#  2. user-specific file
#  3. system-wide file
# Any configuration value is only changed the first time it is set.
# Thus, host-specific definitions should be at the beginning of the
# configuration file, and defaults at the end.

# This Include directive is not part of the default ssh_config shipped with
# OpenSSH. Options set in the included configuration files generally override
# those that follow.  The defaults only apply to options that have not been
# explicitly set.  Options that appear multiple times keep the first value set,
# unless they are a multivalue option such as IdentityFile.
Include /etc/ssh/ssh_config.d/*

# Site-wide defaults for some commonly used options.  For a comprehensive
# list of available options, their meanings and defaults, please see the
# ssh_config(5) man page.

# Host *
#   ForwardAgent no
#   ForwardX11 no
#   PasswordAuthentication yes
#   HostbasedAuthentication no
#   GSSAPIAuthentication no
#   GSSAPIDelegateCredentials no
#   BatchMode no
#   CheckHostIP no
#   AddressFamily any
#   ConnectTimeout 0
#   StrictHostKeyChecking ask
#   IdentityFile ~/.ssh/id_rsa
#   IdentityFile ~/.ssh/id_dsa
#   IdentityFile ~/.ssh/id_ecdsa
#   IdentityFile ~/.ssh/id_ed25519
#   Port 22
   Ciphers aes128-ctr,aes192-ctr,aes256-ctr,aes128-cbc,3des-cbc
   MACs hmac-md5,hmac-sha1,umac-64@openssh.com
#   EscapeChar ~
#   Tunnel no
#   TunnelDevice any:any
#   PermitLocalCommand no
#   VisualHostKey no
#   ProxyCommand ssh -q -W %h:%p gateway.example.com
#   RekeyLimit 1G 1h
#   UserKnownHostsFile ~/.ssh/known_hosts.d/%k
Host *
    SendEnv LANG LC_*
# HostkeyAlgorithms +ssh-rsa
# HostKeyAlgorithms +diffie-hellman-group1-sha1,diffie-hellman-group14-sha1

markus@MacMini ~ %

Die IP Adressen in den VMs sind statisch vergeben und wurden natürlich angepasst. Ich habe, um MAC Konflikte zu vermeiden, im Nachgang die Netzwerkkarte von paravirtualized auf Intel geändert.
Hier ein Beispiel einer VM:
Code:
markus@lyrion-emil:~$ cat /etc/network/interfaces
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

source /etc/network/interfaces.d/*

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
allow-hotplug ens18
# iface ens18 inet dhcp
iface ens18 inet static
address 192.168.1.102
    netmask 255.255.255.0
    gateway 192.168.1.200
    dns-nameservers 192.168.1.200, 8.8.8.8


# This is an autoconfigured IPv6 interface
iface ens18 inet6 auto
markus@lyrion-emil:

Das arp Table am proxmox ist sauber:
Code:
root@proxy:~# cat /proc/net/arp
IP address       HW type     Flags       HW address            Mask     Device
192.168.1.1      0x1         0x2         f0:18:98:f2:dd:84     *        vmbr0
192.168.1.200    0x1         0x2         08:b6:57:75:d3:ce     *        vmbr0
192.168.1.108    0x1         0x2         3c:5c:c4:6e:2b:a3     *        vmbr0
192.168.1.10     0x1         0x2         00:11:32:c8:70:47     *        vmbr0
192.168.1.111    0x1         0x2         e8:aa:cb:e1:c0:6a     *        vmbr0
192.168.1.103    0x1         0x2         c0:49:ef:1f:04:d0     *        vmbr0
root@proxy:~#

/etc/hosts
/Users/markus/.ssh/config
/etc/ssh/ssh_config
auf meinem Mac sind sauber - da ist keine der IP´s der proxmox VMs drin.

Und Joghannes S hat Recht: Es ist ein Debian Bookworm:
1756997047519.png
 
Gerade fällt mir ebenso auf, dass diese VM ungewöhlich "unstet" bei der Namensauflösung ist:
Code:
markus@lyrion-frederick:~$ ping www.web.de
ping: www.web.de: Temporärer Fehler bei der Namensauflösung
markus@lyrion-frederick:~$ ping www.web.de
PING www.g-ha-web.de (82.165.229.83) 56(84) bytes of data.
64 bytes from bap.web.de (82.165.229.83): icmp_seq=1 ttl=247 time=11.7 ms
64 bytes from bap.web.de (82.165.229.83): icmp_seq=2 ttl=247 time=11.3 ms
64 bytes from bap.web.de (82.165.229.83): icmp_seq=3 ttl=247 time=11.1 ms
64 bytes from bap.web.de (82.165.229.83): icmp_seq=4 ttl=247 time=11.2 ms
64 bytes from bap.web.de (82.165.229.83): icmp_seq=5 ttl=247 time=11.3 ms
^C
--- www.g-ha-web.de ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4005ms
rtt min/avg/max/mdev = 11.143/11.315/11.669/0.187 ms
markus@lyrion-frederick:~$ ping www.web.de
ping: www.web.de: Temporärer Fehler bei der Namensauflösung
markus@lyrion-frederick:~$ ping www.web.de
PING www.g-ha-web.de (82.165.229.83) 56(84) bytes of data.
64 bytes from bap.web.de (82.165.229.83): icmp_seq=1 ttl=247 time=11.9 ms
64 bytes from bap.web.de (82.165.229.83): icmp_seq=2 ttl=247 time=11.2 ms
64 bytes from bap.web.de (82.165.229.83): icmp_seq=3 ttl=247 time=11.6 ms
^C
--- www.g-ha-web.de ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2004ms
rtt min/avg/max/mdev = 11.164/11.539/11.883/0.294 ms
markus@lyrion-frederick:~$
Keine meiner separat aufgesetzten VMs zeigen so ein Verhalten - lediglich der Clone !?!
 
unabhängig (?) von dem SSH Thema ist die DNS Auflösung echt komisch:

Code:
markus@lyrion-frederick:~$ dig google.com
;; communications error to 192.168.1.200#53: timed out
;; communications error to 192.168.1.200#53: timed out

; <<>> DiG 9.18.33-1~deb12u2-Debian <<>> google.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18161
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;google.com.                    IN      A

;; ANSWER SECTION:
google.com.             209     IN      A       142.250.186.46

;; Query time: 0 msec
;; SERVER: 192.168.1.200#53(192.168.1.200) (UDP)
;; WHEN: Fri Sep 05 13:06:24 CEST 2025
;; MSG SIZE  rcvd: 55

markus@lyrion-frederick:~$
Natürlich ist mein DNS (192.168.1.200) kontinuierlich erreichbar. Ich bin geneigt die VM komplett zu löschen und statt clonen vollständig neu einzurichten :-(
 
Last edited:
Hallo dieoma,

das wäre ggf. der vermutlich schnellere Weg, abhängig von der Workload und der Zeit die noch für das Troubleshooting aufgewendet wird. ;)

Also was sich vmtl. ausschließen lässt, ist das dein ursprüngliches Problem an der SSH Konfiguration liegt.

Mit dem Output des dig commandos kommst du ggf. schon ein Stück weiter.
Denn gem. dem Output hat deine geklonte VM Probleme den lokalen DNS (aka das Gateway) zu erreichen, scheint zu funktionieren.
Lassen sich die Probleme beim Anpingen der entsprechenden IPs reproduzieren? (ping 8.8.8.8 ; ping 192.168.1.200 )

Je nachdem wie du deine Subnetze separiert hast, könnte das ein Hinweis sein.
(falls sich dein PVE Host und dein Mac Mini in einem anderen Subnetz befinden)

Um das genauer zu untersuchen versuche es mal mit einem tcpdump in der VM und auf dem lokalen DNS (falls du da CLI Zugriff hast)

Bash:
# dump des ssh traffics
tcpdump -veni <interface|any> host <hostip> and port 22

# dump des icmpi(ping) traffics
tcpdump -veni <interface|any> icmp


---
Ich habe, um MAC Konflikte zu vermeiden, im Nachgang die Netzwerkkarte von paravirtualized auf Intel geändert

Die Art der Netzwerkkarte ist unabhängig von der MAC-Addresse. PVE generiert die beim Klonen über die GUI automatisch neu.
Es könnte aber sein, dass je nachdem welche Optionen bei der Isntallation der Vm gewählt wurden, ihr die passenden Treiber für die Intel NIC fehlen.
Das könntest du ggf. noch zurück ändern.
 
  • Like
Reactions: Johannes S
Man sieht in dem dig, dass er die Fritzbox erst nicht, aber dann im 3. retry den DNS in der Fritze erreicht und den Namen auflösen kann.
Da ich ein flaches Netz ohne VLANs oder weitere Subnetze (alle sind in 192.168.1.xx/24 habe schließe ich auch das als Fehlerquelle aus. Ich habe die Netzwerkkarte wieder auf paravirtualized zurück gestellt - selbes Ergebniss.

Schade eigentlich, denn Clones sind ja extra dazu da Arbeit abzunehmen und nun muß ich jeden Gast separat aufsetzen :-(
 
Man sieht in dem dig, dass er die Fritzbox erst nicht, aber dann im 3. retry den DNS in der Fritze erreicht und den Namen auflösen kann.
Da ich ein flaches Netz ohne VLANs oder weitere Subnetze (alle sind in 192.168.1.xx/24 habe schließe ich auch das als Fehlerquelle aus. Ich habe die Netzwerkkarte wieder auf paravirtualized zurück gestellt - selbes Ergebniss.

Schade eigentlich, denn Clones sind ja extra dazu da Arbeit abzunehmen und nun muß ich jeden Gast separat aufsetzen :-(
Hast du auch garantiert eine neue MAC Adresse bei deinem Clone?
 
  • Like
Reactions: Johannes S
Hast du auch garantiert eine neue MAC Adresse bei deinem Clone?
Ja, hab ich:
Das hier ist der Clone:

Code:
markus@lyrion-frederick:~$ ip a
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 noprefixroute
       valid_lft forever preferred_lft forever
2: ens18: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether bc:24:11:91:1c:a6 brd ff:ff:ff:ff:ff:ff
    altname enp0s18
    inet 192.168.1.103/24 brd 192.168.1.255 scope global ens18
       valid_lft forever preferred_lft forever
    inet6 2a09:8e40:3013:d00:be24:11ff:fe91:1ca6/64 scope global dynamic mngtmpaddr
       valid_lft 7146sec preferred_lft 3546sec
    inet6 fd20:545c:bf38:0:be24:11ff:fe91:1ca6/64 scope global dynamic mngtmpaddr
       valid_lft 7146sec preferred_lft 3546sec
    inet6 fe80::be24:11ff:fe91:1ca6/64 scope link
       valid_lft forever preferred_lft forever
markus@lyrion-frederick:~$

Das hier ist das Original:
Code:
markus@lyrion-emil:~$ ip a
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 noprefixroute
       valid_lft forever preferred_lft forever
2: ens18: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether bc:24:11:d2:31:34 brd ff:ff:ff:ff:ff:ff
    altname enp0s18
    inet 192.168.1.102/24 brd 192.168.1.255 scope global ens18
       valid_lft forever preferred_lft forever
    inet6 2a09:8e40:3013:d00:be24:11ff:fed2:3134/64 scope global dynamic mngtmpaddr
       valid_lft 7127sec preferred_lft 3527sec
    inet6 fd20:545c:bf38:0:be24:11ff:fed2:3134/64 scope global dynamic mngtmpaddr
       valid_lft 7127sec preferred_lft 3527sec
    inet6 fe80::be24:11ff:fed2:3134/64 scope link
       valid_lft forever preferred_lft forever
markus@lyrion-emil:~$
 
Sieht ja soweit OK aus. Mit welchem Client versuchst du dich zu verbinden?
Eventuell mag der es nicht, dass zwei Geräte den gleichen Key benutzen.
 
Ist ein MacOS Client. Habe die Keys vorher gelöscht und per
Code:
sudo dpkg-reconfigure openssh-server
neu erstellen lassen. Wäre es ein Schlüsselproblem käme auch kein "Connection refused", das wäre eine andere Meldung...
 
Clones zu benutzen ist heutzutage Standard und funktioniert ja überall, außer bei dir. Dann muss es irgend eine Variable deines Setups sein.
 
Man sieht in dem dig, dass er die Fritzbox erst nicht, aber dann im 3. retry den DNS in der Fritze erreicht und den Namen auflösen kann.
Da ich ein flaches Netz ohne VLANs oder weitere Subnetze (alle sind in 192.168.1.xx/24 habe schließe ich auch das als Fehlerquelle aus. Ich habe die Netzwerkkarte wieder auf paravirtualized zurück gestellt - selbes Ergebniss.

Ack, das stimmt, ich habe mich in der Eile von dem 8.8.8.8 als zweiten DNSserver fehlleiten lassen.

Ich denke der beste Hinweis in dem Tracing ist:

Code:
debug1: connect to address 0.0.0.22 port 22: No route to host
ssh: connect to host 0.0.0.22 port 22: No route to host


An der Config in /etc/network/interfaces aus deinem LXC-Thread habe ich auf den ersten Blick auch nichts ungewöhnliches gefunden.

bridge-stp off Sollte immer off sein, wenn nicht explizit die Spanning Tree Architektur geplant wurde.
Sonst führen die Default Gewichte zu häufig zu nicht so lustigen Nebeneffekten, wie nach kurzer Zeit wegreißenden Verbindungen.

Ich würde im Stack untendrunter weitersuchen, falls du die Zeit investieren möchtest (portspeeds, tcpdump, ...)
GGf. hilft es die Verfügbarkeit von Hypervisor parallel zu der VM zu monitoren, um einen Hinweis zu bekommen, ob das Verhalten von außen induziert ist. Der LXContainer scheint recht ähnlich Herausforderungen zu haben.

BG, Lucas
 
Last edited: