Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

# Direktes SSH
<a name="direct-ssh-access"></a>

**Sicherheitshinweis**  
Direct SSH öffnet einen eingehenden TCP-Port auf Ihren Cluster-Pods. Wir empfehlen[Fernzugriff mit SSH über SSM](vscode-access.md), da dafür keine offenen eingehenden Ports erforderlich sind. Aktivieren Sie Direct SSH nur, wenn der Fernzugriff über SSM Ihre Anforderungen nicht erfüllt (z. B. kein Internetzugang oder Standard-SSH-Tools erforderlich).

Überprüfen Sie vor der Aktivierung Folgendes:

Cluster-wide Auswirkung  
`directSSH.enabled: true`öffnet den konfigurierten Port auf allen Workspace-Pods im gesamten Cluster, nicht nur auf ausgewählten Workspaces oder Benutzern.

Sicherheitsgruppen-Bereich  
Beschränken Sie die Regel für eingehenden Datenverkehr auf den engstmöglichen Quellblock für Classless Inter-Domain Routing (CIDR). `0.0.0.0/0`Niemals verwenden. Überprüfe regelmäßig mithilfe der verwalteten AWS Regel Config [ restricted-ssh. ](https://docs.aws.amazon.com/config/latest/developerguide/restricted-ssh.html)

Lebenszyklus des SSH-Schlüssels  
Sie verwalten den Lebenszyklus von SSH-Schlüsseln. SSH-Schlüssel sind langlebige Anmeldeinformationen. Ohne eine Rotationsrichtlinie gewährt ein kompromittierter Schlüssel dauerhaften Zugriff. Richten Sie eine Richtlinie zur SSH-Schlüsselrotation ein und rotieren Sie die Schlüssel regelmäßig, bevor Sie sie Ihrem Team zur Verfügung stellen.

VPC-Netzwerkisolierung  
Sie verwalten die VPC-Netzwerkisolierung. Wenn Sie Direct SSH aktivieren, wird sshd auf dem Pod gestartet, und Ihre VPC-Sicherheitsgruppen und Ihr Routing steuern, wer es erreichen kann. Stellen Sie sicher, dass nur vertrauenswürdige Netzwerkquellen (VPN-Subnetz, Direct Connect CIDR oder Unternehmensnetzwerkbereich) den konfigurierten Port erreichen können. Direct SSH macht den SSH-Port auf der privaten IP-Adresse des Pods in Ihrer VPC verfügbar. Ein Client kann ihn nur erreichen, wenn er über dieselbe VPC, VPC-Peering, ein VPN oder Direct Connect eine Netzwerkkonnektivität zu dieser VPC hat.

## Voraussetzungen
<a name="direct-ssh-prereq"></a>

Direct SSH erfordert externalDNS, eine Amazon Route 53 Private Hosted Zone, VPC-Konnektivität von Client-Computern und (optional) den Load Balancer Controller. AWS Die vollständige Liste der Voraussetzungen finden Sie unter. [Voraussetzungen für Direct SSH](permission-setup.md#permission-direct-ssh)

Wenn der Webbrowser-Zugriff auf Ihrem Cluster bereits aktiviert ist, sind alle Voraussetzungen erfüllt. Bevor Sie fortfahren, überprüfen Sie, ob Ihr externalDNS mit konfiguriert ist. `--policy=sync` Details hierzu finden Sie unter [Externe DNS-Konfiguration](#direct-ssh-appendix-externaldns).

Wenn der Webbrowser-Zugriff noch nicht konfiguriert ist, finden Sie weitere Informationen unter. [(Optional) Voraussetzungen einrichten](#direct-ssh-appendix) Weitere Informationen zum Aktivieren des Webbrowserzugriffs finden Sie unter[Installation des EKS-Addons — Jupyter K8s mit WebUI](operator-install.md#webui-install).

## Konfigurieren Sie Direct SSH für Ihren Cluster
<a name="direct-ssh-admin"></a>

**Cluster-wide Geltungsbereich**  
`directSSH.enabled: true`startet sshd auf dem konfigurierten Port in allen Workspace-Pods im gesamten Cluster. SSH bietet den gleichen Zugriff wie das JupyterLab Terminal: derselbe Benutzer (`sagemaker-user`), dasselbe Dateisystem.

### Schritt 1: Sicherheitsgruppenregel für SSH hinzufügen
<a name="direct-ssh-admin-sg"></a>

Für den Webbrowser-Zugriff wird HTTPS (443) über einen Application Load Balancer (ALB) verwendet. Da Direct SSH eine direkte Verbindung zu Pod-IPs auf dem konfigurierten Port herstellt, müssen Sie eine Sicherheitsgruppen-Regel für eingehenden Datenverkehr hinzufügen.

**Die VPC-Konfiguration liegt in Ihrer Verantwortung**  
Sie müssen Ihre VPC korrekt konfigurieren, einschließlich Sicherheitsgruppen, Routing und Netzwerkzugriffskontrollen. Direct SSH startet sshd auf dem Pod. Ihre VPC bestimmt, wer sie erreichen kann. Beschränken Sie den Zugriff nur auf die CIDRs, die über SSH in Workspaces zugreifen können (z. B. den Netzwerkbereich Ihres Unternehmens, das VPN-Tunnel-Subnetz oder Direct Connect CIDR). Verwenden Sie nicht `0.0.0.0/0`.

**Überprüfen Sie die richtige Sicherheitsgruppe, bevor Sie Änderungen vornehmen**  
HyperPod Instanzgruppen können die VPC-Konfiguration auf Gruppenebene bis hin `OverrideVpcConfig` zu Sicherheitsgruppen außer Kraft setzen. Die richtige Sicherheitsgruppe, die geändert werden muss, hängt davon ab, ob es für Ihre Workspace-Instanzgruppe eine Überschreibung gibt. Das Hinzufügen der Regel zur falschen Sicherheitsgruppe führt zu einem unbeaufsichtigten `Connection timed out` Fehler.

Überprüfe, ob deine Workspace-Instanzgruppe eine SG-Override hat:

```
aws sagemaker describe-cluster \
  --cluster-name <HYPERPOD_CLUSTER_NAME> \
  --region <AWS_REGION> \
  --query 'InstanceGroups[*].{Name:InstanceGroupName, OverrideSGs:OverrideVpcConfig.SecurityGroupIds}'
```

#### Option A: Die Instanzgruppe hat eine Sicherheitsgruppen-Override
<a name="direct-ssh-admin-sg-override"></a>

Wenn sie ungleich Null `OverrideSGs` ist, fügen Sie die Regel zu dieser Sicherheitsgruppe hinzu:

```
SG_ID=<SG_ID_FROM_OVERRIDE_VPC_CONFIG>
aws ec2 authorize-security-group-ingress \
  --group-id $SG_ID \
  --protocol tcp \
  --port <SSH_PORT> \
  --cidr <SOURCE_CIDR> \
  --region <AWS_REGION>
```

#### Option B: Für die Instanzgruppe gibt es keine Sicherheitsgruppenüberschreibung
<a name="direct-ssh-admin-sg-cluster"></a>

Wenn Null `OverrideSGs` ist, verwenden Sie die Sicherheitsgruppe auf Clusterebene aus der SageMaker HyperPod Cluster-VPC-Konfiguration:

```
SG_ID=$(aws sagemaker describe-cluster --cluster-name <HYPERPOD_CLUSTER_NAME> --region <AWS_REGION> \
  --query 'VpcConfig.SecurityGroupIds[0]' --output text)
aws ec2 authorize-security-group-ingress \
  --group-id $SG_ID \
  --protocol tcp \
  --port <SSH_PORT> \
  --cidr <SOURCE_CIDR> \
  --region <AWS_REGION>
```

Die folgende Tabelle zeigt, wo die einzelnen Platzhalterwerte zu finden sind.


| Placeholder | Wo kann man ihn bekommen | 
| --- | --- | 
| <HYPERPOD\_CLUSTER\_NAME> | Wählen Sie im SageMaker AWS-Managementkonsole die Option  HyperPod Cluster aus. Oder renneaws sagemaker list-clusters. | 
| <SSH\_PORT> | Der Port, in dem Sie konfiguriert haben directSSH.port (der Standard ist 22). Er muss der Regel für eingehenden Datenverkehr der Sicherheitsgruppe entsprechen. | 
| <AWS\_REGION> | Die AWS Region, in der Ihre HyperPod und EKS-Cluster bereitgestellt werden. | 
| <SOURCE\_CIDR> | Der CIDR Ihres vertrauenswürdigen Netzwerks: VPN-Tunnelsubnetz, Direct Connect CIDR oder Unternehmensnetzwerkbereich (z. B. 10.192.16). 0/24). Darf nicht 0.0.0 sein. 0/0. | 

### Schritt 2: Direct SSH aktivieren
<a name="direct-ssh-admin-enable"></a>

Fügen Sie `directSSH` Ihrer Addon-Konfiguration hinzu und fügen Sie Folgendes hinzu: `clusterWebUI`

```
jupyter-k8s-aws-hyperpod:
  clusterWebUI:
    enabled: true
    domain: "<DOMAIN_NAME>"
    awsCertificateArn: "<ACM_CERTIFICATE_ARN>"
    traefik:
      shouldInstall: true
  directSSH:
    enabled: true
    port: <SSH_PORT>          # default: 22
    domain: "<ROUTE53_HOSTED_ZONE_DOMAIN>"
```

Die folgende Tabelle zeigt, wo die einzelnen Platzhalterwerte zu finden sind.


| Placeholder | Wo kann man ihn bekommen | 
| --- | --- | 
| <DOMAIN\_NAME> | Die Domain, die Sie konfiguriert haben, als Sie den Webbrowser-Zugriff aktiviert haben (z. B. spaces.example.com). Weitere Informationen finden Sie unter [Installation des EKS-Addons — Jupyter K8s mit WebUI](operator-install.md#webui-install). | 
| <ACM\_CERTIFICATE\_ARN> | AWS Certificate Manager (ACM) AWS-Managementkonsole, wählen Sie  Zertifikate und wählen Sie dann Ihren ARN für  das Platzhalterzertifikat aus | 
| <ROUTE53\_HOSTED\_ZONE\_DOMAIN> | Route 53 AWS-Managementkonsole, wählen Sie  Hosted Zones und dann den Namen der privaten gehosteten Zone aus, der für externalDNS verwendet wird (z. B. workspaces.internal) | 
| <SSH\_PORT> | Port sshd hört interne Workspace-Pods ab. Standard 22. Verwenden Sie einen nicht privilegierten Port (z. B. 2222), wenn Ihre Sicherheitsgruppe oder Unternehmensrichtlinie Port 22 einschränkt. Die Regel für eingehenden SG-Verkehr muss diesem Wert entsprechen. | 

**DirectSSH und RemoteAccess schließen sich gegenseitig aus**  
`directSSH`und schließen sich gegenseitig `remoteAccess` aus. Wenn Sie beide aktivieren`helm upgrade`, schlägt Folgendes fehl: „DirectSSH und RemoteAccess schließen sich gegenseitig aus. Aktiviere nur einen.“ `remoteAccess`Vor der Aktivierung deaktivieren`directSSH`.

Aktualisiere das Addon:

```
aws eks update-addon \
  --cluster-name <CLUSTER_NAME> \
  --addon-name amazon-sagemaker-spaces \
  --configuration-values file://addon-config.yaml \
  --resolve-conflicts OVERWRITE \
  --region <AWS_REGION>
```

Informationen zur Deaktivierung von Direct SSH finden Sie unter[Widerrufen des direkten SSH-Zugriffs](#direct-ssh-revoke).

### Schritt 3: Vergewissern Sie sich, dass Direct SSH aktiv ist
<a name="direct-ssh-admin-verify"></a>

```
# Check addon status
aws eks describe-addon \
  --cluster-name <CLUSTER_NAME> \
  --addon-name amazon-sagemaker-spaces \
  --region <AWS_REGION>

# Check headless services created for workspaces
kubectl get svc -l app.kubernetes.io/component=direct-ssh

# Verify DNS record resolves (from within VPC)
dig <workspace-name>.<namespace>.<ROUTE53_HOSTED_ZONE_DOMAIN>
```

## Stelle mithilfe von Direct SSH eine Verbindung zu deinem Workspace her
<a name="direct-ssh-enduser"></a>

Verwende die folgenden Verfahren, um mithilfe von Direct SSH eine Verbindung zu deinem Workspace herzustellen, deine SSH-Schlüssel zu verwalten und Verbindungsprobleme zu beheben.

### Wie funktioniert die SSH-Authentifizierung
<a name="direct-ssh-enduser-auth"></a>

Direct SSH verwendet die Standardauthentifizierung mit öffentlichen Schlüsseln. Jeder Benutzer generiert sein eigenes SSH-Schlüsselpaar und fügt den öffentlichen Schlüssel zu seinem Workspace hinzu. Private Schlüssel verlassen niemals den Computer des Benutzers.

Im Folgenden sind die wichtigsten Fakten zum SSH-Zugriff aufgeführt:
+ SSH gewährt den gleichen Zugriff wie das JupyterLab Terminal: derselbe Benutzer (`sagemaker-user`), dasselbe Dateisystem, dieselben Tools.
+ Die Schlüssel sind pro Arbeitsbereich gültig. Ein Schlüssel in einem Arbeitsbereich gewährt keinen Zugriff auf andere Arbeitsbereiche.
+ Das SageMaker AI Spaces-Startskript erstellt automatisch das `.ssh/` Verzeichnis mit den richtigen Berechtigungen.
+ Schlüssel bleiben auch bei Workspace-Neustarts erhalten (auf dem PC gespeichert) und werden gelöscht, wenn der Workspace gelöscht wird.

**Aktuelle Beschränkung**  
Der SSH-Benutzername ist immer `sagemaker-user` unabhängig davon, wer eine Verbindung herstellt. Sie können keinen persönlichen Benutzernamen verwenden. Alle Sitzungen werden unter demselben Workspace-Benutzer ausgeführt. Per-user Die Identität in Shell-Prompts und Audit-Logs ist in der aktuellen Version nicht verfügbar.

### Schritt 1: Generieren Sie einen SSH-Schlüssel auf Ihrem Client-Computer
<a name="direct-ssh-enduser-keygen"></a>

Führen Sie diesen Befehl einmal aus, um Ihr Schlüsselpaar zu erstellen:

```
ssh-keygen -t ed25519 -f ~/.ssh/my-workspace-key
```

Dadurch entsteht:
+ `~/.ssh/my-workspace-key`— privater Schlüssel (geheim halten, niemals teilen)
+ `~/.ssh/my-workspace-key.pub`— öffentlicher Schlüssel (zu deinem Workspace hinzufügen)

### Schritt 2: Füge deinen öffentlichen Schlüssel zu deinem Workspace hinzu
<a name="direct-ssh-enduser-addkey"></a>

**Verwende ** eine der folgenden Methoden, um deinen öffentlichen Schlüssel hinzuzufügen. Sie müssen nicht beides tun.

#### Fügen Sie Ihren Schlüssel über den Webbrowser hinzu
<a name="direct-ssh-enduser-addkey-webui"></a>

1. Öffne deinen Workspace im Browser (siehe[Zugriff über den Webbrowser](browser-access.md)).

1. Öffnen Sie ein -Terminalfenster. Wähle in „**Datei“ JupyterLab**, „**Neu“ ** und „**Terminal**“. Wählen Sie im Code-Editor ** Terminal**, ** Neues Terminal**.

1. Kopieren Sie Ihren öffentlichen Schlüssel von Ihrem lokalen Computer: `cat ~/.ssh/my-workspace-key.pub`

1. In das Workspace-Terminal einfügen:

   ```
   echo "ssh-ed25519 AAAA...your-key... user@machine" >> ~/.ssh/authorized_keys
   ```

#### Füge deinen Schlüssel über kubectl hinzu
<a name="direct-ssh-enduser-addkey-kubectl"></a>

```
POD=$(kubectl get pods -n <namespace> -l workspace.jupyter.org/workspace-name=<space-name> \
  -o jsonpath='{.items[0].metadata.name}')
cat ~/.ssh/my-workspace-key.pub | kubectl exec -n <namespace> -i $POD -c workspace -- \
  bash -c "cat >> /home/sagemaker-user/.ssh/authorized_keys"
```

### Schritt 3: Stellen Sie mithilfe von SSH eine Verbindung zu Ihrem Workspace her
<a name="direct-ssh-enduser-connect"></a>

```
ssh -p <SSH_PORT> -i ~/.ssh/my-workspace-key sagemaker-user@<space-name>.<namespace>.<domain>
```

**SSH-Anschluss**  
Verwenden Sie den SSH-Port, den Ihr Administrator für Direct SSH konfiguriert hat. Wenn Ihr Administrator den Standardport (22) beibehalten hat, können Sie die `-p` Option weglassen. Wenn sie einen anderen Port konfiguriert haben (z. B. 2222), müssen Sie diesen angeben, da `-p <SSH_PORT>` sonst die Verbindung fehlschlägt. `Connection refused` Wenden Sie sich an Ihren Administrator, wenn Sie sich nicht sicher sind, welchen Port Sie verwenden sollen.

Beispiel:

```
ssh -p 2222 -i ~/.ssh/my-workspace-key sagemaker-user@my-space.default.spaces.example.com
```

### Schritt 4: Konfigurieren Sie SSH für den einfachen Zugriff
<a name="direct-ssh-enduser-config"></a>

Dieser optionale Schritt vereinfacht zukünftige Verbindungen. Fügen Sie Folgendes zu `~/.ssh/config` hinzu:

```
Host my-space
    HostName <space-name>.<namespace>.<domain>
    Port <SSH_PORT>
    User sagemaker-user
    IdentityFile ~/.ssh/my-workspace-key
    ServerAliveInterval 15
    ServerAliveCountMax 3
```

Stellen Sie `Port` den Port ein, den Ihr Administrator konfiguriert hat. Sie können diese Zeile weglassen, wenn Direct SSH den Standardport (22) verwendet. Stellen Sie dann eine Verbindung her mit: `ssh my-space`

### Schritt 5: Verbinden Sie eine Remote-IDE
<a name="direct-ssh-enduser-ide"></a>

Nachdem Direct SSH von Ihrem Terminal aus funktioniert (Schritt 3), stellt jede Remote-SSH fähige IDE über denselben `~/.ssh/config` Eintrag eine Verbindung her. Für diese Verbindung benötigen Sie keine zusätzliche AWS Konfiguration.

#### Installieren Sie die Remote-SSH Erweiterung
<a name="direct-ssh-enduser-ide-install"></a>


| IDE | Erweiterung | 
| --- | --- | 
| VS Code | Erweiterungen, suchen Sie nach „Remote - SSH“ und wählen Sie Installieren (von Microsoft) | 
| Kiro | Erweiterungen, suchen Sie nach „Remote - SSH“ und wählen Sie Installieren | 
| Cursor | Erweiterungen, suchen Sie nach „Remote - SSH“ und wählen Sie Installieren | 

#### Stellen Sie von der IDE aus eine Verbindung her
<a name="direct-ssh-enduser-ide-connect"></a>

1. Öffnen Sie die ** Befehlspalette ** und wählen Sie dann "Remote-SSH: Mit Host verbinden...“

1. Wähle deinen Workspace aus der Liste aus (Verwendungen `~/.ssh/config` aus Schritt 4).

1. Die IDE installiert ihre Serverkomponente auf dem Workspace (einmalig, ca. 30 Sekunden).

1. Ein Remote-Fenster mit allen Editor-Funktionen, einschließlich IntelliSense Terminal und Datei-Explorer, wird geöffnet.

**Öffnen Sie Ihre Workspace-Dateien in VS Code**  
Wählen Sie in VS Code nach dem Herstellen der Verbindung ** Datei**, Ordner ** öffnen**, `/home/sagemaker-user` um Ihre Workspace-Dateien direkt zu öffnen.

### Verwaltung und Widerruf von Schlüsseln
<a name="direct-ssh-enduser-keys"></a>

Sie verwalten Ihre SSH-Schlüssel. SSH-Schlüssel sind langlebige Anmeldeinformationen, die nicht automatisch ablaufen. Ein Schlüssel `authorized_keys` gewährt Zugriff auf deinen Workspace, bis du ihn explizit entfernst.

#### Um deinen Schlüssel zu drehen
<a name="direct-ssh-enduser-keys-rotate"></a>

Wir empfehlen, die Schlüssel regelmäßig zu wechseln.

1. Generieren Sie ein neues Schlüsselpaar auf Ihrem Client-Computer: `ssh-keygen -t ed25519 -f ~/.ssh/my-workspace-key-new`

1. Füge den neuen öffentlichen Schlüssel zu deinem Workspace hinzu (Schritt 2). Sowohl der alte als auch der neue Schlüssel funktionieren gleichzeitig.

1. Stellen Sie sicher, dass der neue Schlüssel funktioniert: `ssh -p <SSH_PORT> -i ~/.ssh/my-workspace-key-new sagemaker-user@<hostname>`

1. Entferne den alten Schlüssel aus `authorized_keys` deinem Workspace-Terminal:

   ```
   # List current keys with line numbers
   cat -n ~/.ssh/authorized_keys
   # Remove a specific line (for example, line 1)
   sed -i '1d' ~/.ssh/authorized_keys
   ```

#### Wenn dein privater Schlüssel kompromittiert ist
<a name="direct-ssh-enduser-keys-compromised"></a>

Handeln Sie sofort. Ein kompromittierter Schlüssel gewährt vollen Zugriff auf den Workspace, bis du ihn wieder entfernst. `authorized_keys`

1. Öffne deinen Workspace über den Webbrowser (JupyterLab oder den Code-Editor). Detaillierte Anweisungen finden Sie unter [Zugriff über den Webbrowser](browser-access.md).

1. Entferne den kompromittierten Schlüssel von`authorized_keys`:

   ```
   # View all authorized keys
   cat ~/.ssh/authorized_keys
   # Option A: Edit directly
   nano ~/.ssh/authorized_keys
   # Option B: Remove all keys and re-add only trusted ones
   > ~/.ssh/authorized_keys
   echo "ssh-ed25519 AAAA...new-trusted-key..." >> ~/.ssh/authorized_keys
   ```

1. Stellen Sie sicher, dass der kompromittierte Schlüssel nicht mehr funktioniert, indem Sie versuchen, eine Verbindung herzustellen. Sie sollten erhalten`Permission denied (publickey)`.

1. Wenn Sie nicht über einen Webbrowser auf den Workspace zugreifen können, wenden Sie sich an Ihren Cluster-Administrator, um `authorized_keys` direkt in den Pod zu gelangen und ihn zu löschen.

#### Bewährte Methoden
<a name="direct-ssh-enduser-keys-practices"></a>


| Üben Sie | Warum | 
| --- | --- | 
| Verwenden Sie ed25519-Schlüssel | Kürzer, schneller, sicherer als RSA | 
| Verwenden Sie eine Passphrase für Ihren privaten Schlüssel | Schützt vor Schlüsseldiebstahl. Selbst wenn der Schlüssel gestohlen wird, kann er ohne die Passphrase nicht verwendet werden. | 
| Ein Schlüssel pro Gerät | Es ist einfacher, den Zugriff eines einzelnen Geräts zu widerrufen, ohne dass dies Auswirkungen auf andere hat | 
| Teilen Sie niemals private Schlüssel | Jeder Benutzer und jedes Gerät müssen über ein eigenes Schlüsselpaar verfügen | 
| authorized\_keysRegelmäßig überprüfen | Entfernen Sie die Schlüssel für Geräte, die Sie nicht mehr verwenden | 

## Widerrufen des direkten SSH-Zugriffs
<a name="direct-ssh-revoke"></a>

Um zu vermeiden, dass nach der Deaktivierung von Direct SSH eine Sicherheitsgruppenregel geöffnet bleibt, führen Sie alle drei Schritte der Reihe nach aus. Überspringen Sie Schritt 2 nicht.

**Informieren Sie Ihre Benutzer, bevor Sie den Zugriff widerrufen**  
Informieren Sie Ihre Benutzer, bevor Sie den Zugriff widerrufen. ExternalDNS entfernt DNS-Einträge innerhalb von etwa 30 Sekunden nach Schritt 3, wodurch neue Verbindungen blockiert werden.

### Schritt 1: Im Helm-Diagramm deaktivieren
<a name="direct-ssh-revoke-helm"></a>

Entfernen Sie den `directSSH` Abschnitt vollständig aus Ihrer Addon-Konfigurationsdatei. Helm verwendet standardmäßig`directSSH.enabled`, `false` wenn der Schlüssel fehlt:

```
jupyter-k8s-aws-hyperpod:
  clusterWebUI:
    enabled: true
    domain: "<DOMAIN_NAME>"
    ...
  # directSSH section removed
```

Alternativ explizit gesetzt`enabled: false`:

```
directSSH:
  enabled: false
```

### Schritt 2: Entfernen Sie die Regel für eingehenden Sicherheitsgruppenverkehr
<a name="direct-ssh-revoke-sg"></a>

```
# Find the rule ID
aws ec2 describe-security-group-rules \
  --filters Name=group-id,Values=<SG_ID> \
  --query 'SecurityGroupRules[?IpProtocol==`tcp` && FromPort==`<SSH_PORT>`].[SecurityGroupRuleId,CidrIpv4]' \
  --output table \
  --region <AWS_REGION>

# Remove the rule
aws ec2 revoke-security-group-ingress \
  --group-id <SG_ID> \
  --security-group-rule-ids <RULE_ID> \
  --region <AWS_REGION>
```

### Schritt 3: Auf Cluster anwenden
<a name="direct-ssh-revoke-apply"></a>

```
aws eks update-addon \
  --cluster-name <CLUSTER_NAME> \
  --addon-name amazon-sagemaker-spaces \
  --configuration-values file://addon-config.yaml \
  --resolve-conflicts OVERWRITE \
  --region <AWS_REGION>
```

Wenn Sie diesen Befehl ausführen, werden die Headless-Dienste für alle Workspaces entfernt. ExternalDNS löscht dann die Route 53 A-Datensätze innerhalb von etwa 30 Sekunden. Nachdem ExternalDNS die Datensätze entfernt hat, können neue SSH-Verbindungen den Workspace-Hostnamen nicht mehr auflösen.

### Was passiert nach dem Widerruf
<a name="direct-ssh-revoke-after"></a>


| Komponente | Staat nach dem Widerruf | 
| --- | --- | 
| DNS-Datensätze | ExternalDNS entfernt sie innerhalb von etwa 30 Sekunden. Neue Verbindungen können den Workspace-Hostnamen nicht auflösen. | 
| SG-Regel für eingehenden Datenverkehr | Nach Schritt 2 geschlossen. Kein Netzwerkpfad erreicht den Port. | 
| Neue SSH-Verbindungen | Blockiert. Der Hostname wird nicht mehr aufgelöst und die SG-Regel schließt den Port. | 
| Workspace-Daten (PVC) | Unbetroffen. Der PC speichert Ihre Dateien, authorized\_keys und den Hostschlüssel. | 

## Fehlerbehebung
<a name="direct-ssh-troubleshooting"></a>


| Symptom | Ursache | Reparieren | 
| --- | --- | --- | 
| NXDOMAIN | DNS wird nicht aufgelöst | Stellen Sie sicher, dass die gehostete Zone existiert, mit der VPC verknüpft ist und externalDNS ausgeführt wird | 
| Connection timed out | SG-Blockierung: Die Regel wurde zur falschen SG hinzugefügt oder fehlt vollständig | Überprüfen Sie OverrideVpcConfig die Instanzgruppe (Admin-Schritt 1). Stellen Sie sicher, dass die TCP-Regel für eingehenden Datenverkehr Ihren Quell-CIDR abdeckt. | 
| Connection refused | sshd läuft nicht | Prüfen Sie, ob sich der Speicherplatz im Status Running befindet und aktiviert directSSH ist | 
| Permission denied (publickey) | Schlüssel nicht eingegeben authorized\_keys | Fügen Sie den öffentlichen Schlüssel über den Webbrowser oder kubectl hinzu (Schritt 2 für Endbenutzer) | 
| Host key changedWarnung | Der Speicherplatz wurde neu erstellt (neuer Pod, neuer Hostschlüssel) | Auf Ihrem Client-Computer: Stellen Sie ssh-keygen -R <hostname> dann erneut eine Verbindung her | 
| Stale DNS records after space deletion | ExternalDNS läuft mit --policy=upsert-only | Aktualisieren Sie die ExternalDNS-Bereitstellung auf und fügen Sie sie hinzu. --policy=sync --txt-owner-id=<cluster-name> Bereinigen Sie vorhandene veraltete Datensätze manuell: aws route53 list-resource-record-sets --hosted-zone-id <ZONE\_ID> | 
| IDE: „Verbindung konnte nicht hergestellt werden“ | sshd ist noch nicht bereit | Warten Sie nach der Erstellung des Arbeitsbereichs 60-90 Sekunden und versuchen Sie es erneut | 
| IDE: Hängt bei „VS Code Server wird installiert“ | Workspace hat keinen Internetzugang | Ihr Workspace lädt die VS Code-Server-Binärdatei bei der ersten Verbindung von einem externen Host herunter. Wende dich an deinen Administrator, wenn der Workspace einen Air-Gap hat. | 
| IDE: Permission denied | IdentityFile Pfad stimmt nicht überein | Stellen Sie zuerst sicher, dass Terminal-SSH funktioniert, und checken Sie IdentityFile dann ein \~/.ssh/config | 
| IDE: Die Verbindung wird nach dem Leerlauf unterbrochen | Kein Keepalive konfiguriert | Hinzufügen ServerAliveInterval 15 und zu ServerAliveCountMax 3 \~/.ssh/config | 

## (Optional) Voraussetzungen einrichten
<a name="direct-ssh-appendix"></a>

Verwenden Sie diesen Abschnitt nur, wenn der Webbrowser-Zugriff noch nicht aktiviert ist, oder um Ihre ExternalDNS-Konfiguration zu überprüfen oder zu aktualisieren.

### Von Grund auf neu installieren
<a name="direct-ssh-appendix-scratch"></a>

Wenn der Webbrowser-Zugriff noch nicht konfiguriert ist, benötigen Sie Folgendes, bevor Sie Direct SSH aktivieren können:

1. **Gehostete Route 53-Zone ** — eine Domain oder Subdomain, die Ihnen gehört und die in Route 53 registriert ist

1. **Externes DNS ** — wird über EKS-Add-Ons bereitgestellt, wobei die IAM-Rolle über Route 53-Berechtigungen verfügt

1. **AWS Load Balancer Controller ** — erforderlich, wenn Sie den Webbrowser-Zugriff (ALB Ingress) verwenden. Hinweise zur HyperPod-specific Installation finden Sie unter. [AWS Load Balancer Controller: HyperPod vpCID-Anforderung](#direct-ssh-appendix-lbc)

1. **VPC-Konnektivität ** — VPN oder Direktverbindung von Client-Computern zur VPC

Die zusätzlichen Abhängigkeiten und die Schritte zur Konfiguration des Webbrowserzugriffs finden Sie unter. [Installieren Sie SageMaker AI Spaces Add-on](operator-install.md)

### AWS Load Balancer Controller: HyperPod vpCID-Anforderung
<a name="direct-ssh-appendix-lbc"></a>

In der Standardinstallationsdokumentation für den AWS Load Balancer Controller wird der Parameter nicht erwähnt. `vpcId` Bei HyperPod Clustern `vpcId` führt das Auslassen dazu, dass die Installation fehlschlägt. Sie müssen es explizit angeben.

Holen Sie sich Ihre VPC-ID:

```
aws sagemaker describe-cluster \
  --cluster-name <HYPERPOD_CLUSTER_NAME> \
  --region <AWS_REGION> \
  --query 'VpcConfig.VpcId' \
  --output text
```

Installieren Sie mit den erforderlichen HyperPod Parametern:

```
helm install aws-load-balancer-controller eks/aws-load-balancer-controller \
  -n kube-system \
  --set clusterName=<EKS_CLUSTER_NAME> \
  --set serviceAccount.create=false \
  --set serviceAccount.name=aws-load-balancer-controller \
  --set enableServiceMutatorWebhook=false \
  --set vpcId=<VPC_ID>
```


| Parameter | Warum erforderlich am HyperPod | 
| --- | --- | 
| vpcId | HyperPod VPC kann vom Controller nicht automatisch erkannt werden. Ohne sie schlägt die Installation fehl. | 
| enableServiceMutatorWebhook=false | Der mutierende Webhook steht in Konflikt mit HyperPod der Dienstkonfiguration | 
| serviceAccount.create=false | Das Dienstkonto muss vor der Installation mit der richtigen IRSA- oder Pod Identity-Anmerkung erstellt werden | 

Erstellen Sie das Dienstkonto (aws-load-balancer-controller) mit der entsprechenden IAM-Rollenannotation, bevor Sie diesen Befehl ausführen. Weitere Informationen zur IAM-Richtlinie und zu den Schritten zur Erstellung eines Dienstkontos finden Sie unter [ Amazon EKS Load Balancer Controller IRSA-Setup im Amazon EKS-Benutzerhandbuch. ](https://docs.aws.amazon.com/eks/latest/userguide/lbc-helm.html)

### Externe DNS-Konfiguration
<a name="direct-ssh-appendix-externaldns"></a>

ExternalDNS synchronisiert Kubernetes-Dienste mit DNS-Anbietern. Konfigurieren Sie ExternalDNS mit den folgenden Einstellungen, wenn Sie es mit Amazon Route 53 in einer Produktionsumgebung verwenden.

**ExternalDNS erfordert die Synchronisierungsrichtlinie**  
Sie müssen ExternalDNS mit konfigurieren. `--policy=sync`

Standardmäßig verwendet ExternalDNS. `--policy=upsert-only` Dadurch werden DNS-Einträge erstellt und aktualisiert, aber niemals gelöscht. Wenn Sie einen Workspace löschen, bleiben die A- und TXT-Einträge in Amazon Route 53 als veraltete Einträge erhalten.

Verwenden Sie es `--policy=upsert-only` nur für Testzwecke und ändern Sie es in `--policy=sync` für die Produktion. Sie müssen auch das `--txt-owner-id` Flag setzen, das ExternalDNS mitteilt, welche Datensätze es besitzt und welche Datensätze bei der Bereinigung gelöscht werden sollen.

Konfigurieren Sie Ihre ExternalDNS-Bereitstellung mit den folgenden Argumenten:

```
--provider=aws
--source=service                          # watches Services (required for headless Services)
--domain-filter=<ROUTE53_HOSTED_ZONE>     # restricts ExternalDNS to your hosted zone only
--policy=sync                             # enables deletion of stale records on space deletion
--txt-owner-id=<CLUSTER_NAME>             # identifies which records this ExternalDNS instance owns
```

Ersetzen Sie in den vorangegangenen Argumenten die folgenden Werte:
+ `<ROUTE53_HOSTED_ZONE>`— Ihre private gehostete Zonendomäne von Amazon Route 53 (zum Beispiel`workspaces.internal`)
+ `<CLUSTER_NAME>`— Ihr EKS-Clustername (zum Beispiel`my-hyperpod-cluster`)

Führen Sie den folgenden Befehl aus, um Ihre aktuelle ExternalDNS-Richtlinie zu überprüfen:

```
kubectl get deployment -n kube-system external-dns \
  -o jsonpath='{.spec.template.spec.containers[0].args}' | tr ',' '\n' | grep -E 'policy|owner|source|domain'
```