Zum Inhalt

Salto-Host (Hyper-V Host) — Systemdokumentation

Hostname: SALTO-HOST IP: 10.128.40.7 Stand: 19. März 2026


Hardware

Komponente Details
Typ TAROX Business PC SFF Core i5
CPU Intel Core i5 (14. Gen), 2500 MHz
RAM 16 GB
Disk 465 GB (C:), davon 299 GB frei
OS Windows 11 Pro (Build 26200)
Rolle Hyper-V Host für SaltoServer-VM

Hyper-V VM

VM vCPU RAM Typ Status
SALTO (10.128.40.6) 8 8 GB (statisch) Windows Server Running

RAM-Nutzung SALTO-VM (19.03.2026)

Prozess RAM
SQL Server 646 MB
svchost 599 MB
Altaro Backup 422 MB
Windows Defender 301 MB
ProAccess Space 292 MB
VMBackup (3 Prozesse) 497 MB
Chrome (4 Tabs) 711 MB
Gesamt belegt 6,2 GB von 8 GB

Netzwerk

Adapter Typ IP
Intel I219-V Physisch DHCP
vEthernet (DefaultLAN) Hyper-V Virtual Switch 10.128.40.7
  • Standort A (10.128.40.0/24), hinter Sophos XGS 126 (10.128.40.1)
  • Site-to-Site VPN zu Standort B (10.128.30.0/24)

SSH-Zugang (eingerichtet 19.03.2026)

  • OpenSSH Server installiert (Windows Capability, Version 9.5p2)
  • Service: sshd, Autostart, Port 22
  • Firewall-Regel: sshd (TCP 22 inbound allow)
  • Zugang von macOS: ssh salto-host (Alias in ~/.ssh/config)
  • User: administrator
  • Key-Auth über C:\ProgramData\ssh\administrators_authorized_keys
  • ProxyJump über SaltoServer (salto, 10.128.40.6)
  • Zugang von raspip5: via WinRM (Port 5985), TrustedHosts konfiguriert auf SaltoServer

SSH-Installation — Besonderheiten

Die Installation war aufwendig wegen mehrerer Windows-spezifischer Probleme:

  1. Add-WindowsCapability installierte nicht alle Dateien — ssh-keygen.exe fehlte und musste manuell aus C:\Windows\WinSxS\ kopiert werden
  2. Host Key Permissions: sshd als Service crashte mit Fehler 1067 ("Prozess unerwartet beendet"). Ursache: die Host Keys in C:\ProgramData\ssh\ hatten falsche Berechtigungen. Nur SYSTEM darf Zugriff haben — Administrator-Berechtigungen müssen explizit entfernt werden: powershell icacls C:\ProgramData\ssh\ssh_host_*_key /inheritance:r /remove "Administrator" /grant "SYSTEM:(F)"
  3. Debug-Analyse: sshd.exe -d lief manuell fehlerfrei, aber als Service crashte er ohne Log-Einträge. Lösung: Service mit Debug-Flag starten (-ddd -E debug.log), um den Permission-Fehler sichtbar zu machen

WinRM (für Remote-Verwaltung vom SaltoServer)

  • AllowUnencrypted auf SaltoServer aktiviert (sollte wieder auf $false gesetzt werden)
  • Credential-Format: 10.128.40.7\administrator
  • Komplexere ScriptBlocks liefern über WinRM teilweise keine Ausgabe — einfache Befehle bevorzugen

Prüfung: Zweite VM für Monitoring-Services (19.03.2026)

Fragestellung

Kann auf dem Hyper-V Host eine zweite VM (Linux) betrieben werden, um Monitoring-Services vom raspip5 zu verlagern? Ziel wäre, Services die das 40.x- und 30.x-Netz überwachen (SNMP, Sophos XGS Syslog, Blackbox-Exporter) näher an die Standort-Netze zu bringen.

Analyse

Ressource Gesamt SALTO-VM Host-Overhead Frei
RAM 16 GB 8 GB (statisch) ~7 GB ~1,2 GB
CPU Core i5 (14. Gen) 8 vCPU ausreichend
Disk 465 GB ~166 GB 299 GB (ausreichend)

Eine minimale Linux-VM bräuchte mindestens 2 GB RAM. Optionen geprüft:

Option Bewertung
SALTO auf 6 GB reduzieren Riskant — VM nutzt bereits 6,2 GB
Dynamic Memory (Min 6, Max 8) Gibt max. 2 GB frei, nur wenn Salto idle
RAM auf 32 GB aufrüsten Beste Option, aber Aufwand + Kosten

Entscheidung

Keine zweite VM. Die Kombination 40.6/40.7 ist operativ empfindlich. Salto ProAccess Space ist geschäftskritisch und darf nicht beeinträchtigt werden. Bei nur 16 GB RAM gibt es keinen sicheren Spielraum für eine zweite VM.

Monitoring-Services bleiben auf raspip5 und nutzen weiterhin SSH-Tunnel zum SaltoServer für SNMP und Blackbox-Exporter.


Offene Punkte

  • [ ] AllowUnencrypted auf SaltoServer (10.128.40.6) wieder auf $false setzen
  • [ ] Altbestand-Salto-Doku prüfen: Host-IP dort als 10.128.40.5 referenziert (→ aktualisieren?)