As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

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

**Aviso de segurança**  
O SSH direto abre uma porta TCP de entrada em seus pods de cluster. Recomendamos [Acesso remoto usando SSH sobre SSM](vscode-access.md) porque não requer portas de entrada abertas. Ative o SSH direto somente se o acesso remoto por meio do SSM não atender às suas necessidades (por exemplo, sem necessidade de acesso à Internet ou ferramentas SSH padrão).

Antes de ativar, revise o seguinte:

Cluster-wide impacto  
`directSSH.enabled: true`abre a porta configurada em todos os pods do espaço de trabalho em todo o cluster, não apenas nos espaços de trabalho ou usuários selecionados.

escopo dos grupos de segurança  
Restrinja a regra de entrada ao bloco CIDR ( Inter-Domain Roteamento Sem Classe) de origem mais estreito possível. Nunca use`0.0.0.0/0`. Faça auditorias regularmente usando a regra gerenciada AWS Config [ restricted-ssh. ](https://docs.aws.amazon.com/config/latest/developerguide/restricted-ssh.html)

Ciclo de vida da chave SSH  
Você gerencia o ciclo de vida da chave SSH. As chaves SSH são credenciais de longa duração. Sem uma política de rotação, uma chave comprometida concede acesso persistente. Estabeleça uma política de rotação de chaves SSH e alterne as chaves periodicamente antes de implementá-las em sua equipe.

Isolamento de rede VPC  
Você gerencia o isolamento da rede VPC. Quando você ativa o Direct SSH, o sshd começa no pod e seus grupos de segurança e roteamento da VPC controlam quem pode acessá-lo. Certifique-se de que somente fontes de rede confiáveis (sub-rede VPN, CIDR do Direct Connect ou alcance da rede corporativa) possam alcançar a porta configurada. O Direct SSH expõe a porta SSH no endereço IP privado do pod dentro da sua VPC. Um cliente só pode acessá-lo se tiver conectividade de rede com essa VPC, por meio da mesma VPC, emparelhamento de VPC, VPN ou Direct Connect.

## Pré-requisitos
<a name="direct-ssh-prereq"></a>

O Direct SSH exige DNS externo, uma zona hospedada privada do Amazon Route 53, conectividade VPC das máquinas clientes e (opcionalmente) o controlador do Load Balancer. AWS Para ver a lista completa de pré-requisitos, consulte. [Pré-requisitos para o Direct SSH](permission-setup.md#permission-direct-ssh)

Se o acesso ao navegador da Web já estiver habilitado em seu cluster, todos os pré-requisitos estarão em vigor. Antes de continuar, verifique se o ExternalDNS está configurado com. `--policy=sync` Para obter detalhes, consulte [Configuração de DNS externo](#direct-ssh-appendix-externaldns).

Se o acesso ao navegador da Web ainda não estiver configurado, consulte[(Opcional) Configurando pré-requisitos](#direct-ssh-appendix). Para obter mais informações sobre como ativar o acesso ao navegador da Web, consulte[Instalação do complemento EKS - Jupyter K8s com WebUI](operator-install.md#webui-install).

## Configure o Direct SSH para seu cluster
<a name="direct-ssh-admin"></a>

**Cluster-wide escopo**  
`directSSH.enabled: true`inicia o sshd na porta configurada em todos os pods do espaço de trabalho em todo o cluster. O SSH fornece o mesmo acesso que o JupyterLab terminal: mesmo usuário (`sagemaker-user`), mesmo sistema de arquivos.

### Etapa 1: Adicionar regra de grupo de segurança para SSH
<a name="direct-ssh-admin-sg"></a>

O acesso ao navegador da Web usa HTTPS (443) por meio de um Application Load Balancer (ALB). Como o Direct SSH se conecta diretamente aos IPs do pod na porta configurada, você precisa adicionar uma regra de entrada do grupo de segurança.

**A configuração do VPC é de sua responsabilidade**  
Você deve configurar sua VPC corretamente, incluindo grupos de segurança, roteamento e controles de acesso à rede. O SSH direto inicia o sshd no pod. Sua VPC determina quem pode alcançá-la. Restrinja o acesso somente aos CIDRs que podem usar SSH em espaços de trabalho (por exemplo, seu alcance de rede corporativa, sub-rede de túnel VPN ou CIDR de conexão direta). Não use `0.0.0.0/0`.

**Verifique o grupo de segurança correto antes de modificar**  
HyperPod grupos de instâncias podem substituir a configuração da VPC no nível do grupo`OverrideVpcConfig`, incluindo grupos de segurança. O grupo de segurança correto a ser modificado depende de seu grupo de instâncias do workspace ter uma substituição. Adicionar a regra ao grupo de segurança errado resulta em um `Connection timed out` erro silencioso.

Verifique se o grupo de instâncias do seu espaço de trabalho tem uma substituição de SG:

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

#### Opção A: O grupo de instâncias tem uma substituição de grupo de segurança
<a name="direct-ssh-admin-sg-override"></a>

Se não `OverrideSGs` for nulo, adicione a regra a esse grupo de segurança:

```
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>
```

#### Opção B: O grupo de instâncias não tem nenhuma substituição de grupo de segurança
<a name="direct-ssh-admin-sg-cluster"></a>

Se `OverrideSGs` for nulo, use o grupo de segurança em nível de cluster da configuração da VPC do SageMaker HyperPod cluster:

```
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>
```

A tabela a seguir mostra onde encontrar cada valor de espaço reservado.


| Espaço reservado | Onde obtê-lo | 
| --- | --- | 
| <HYPERPOD\_CLUSTER\_NAME> | No SageMaker Console de gerenciamento da AWS, escolha  HyperPod Clusters. Ou corraaws sagemaker list-clusters. | 
| <SSH\_PORT> | A porta que você configurou directSSH.port (o padrão é 22). Ele deve corresponder à regra de entrada do grupo de segurança. | 
| <AWS\_REGION> | A AWS região em que seu cluster HyperPod e o EKS estão implantados. | 
| <SOURCE\_CIDR> | O CIDR da sua rede confiável: sub-rede de túnel VPN, CIDR do Direct Connect ou alcance da rede corporativa (por exemplo, 10.192.16). 0/24). Não deve ser 0.0.0. 0/0. | 

### Etapa 2: habilitar o SSH direto
<a name="direct-ssh-admin-enable"></a>

Adicione `directSSH` à sua configuração adicional junto com`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>"
```

A tabela a seguir mostra onde encontrar cada valor de espaço reservado.


| Espaço reservado | Onde obtê-lo | 
| --- | --- | 
| <DOMAIN\_NAME> | O domínio que você configurou ao habilitar o acesso ao navegador da Web (por exemplo, spaces.example.com). Para obter mais informações, consulte [Instalação do complemento EKS - Jupyter K8s com WebUI](operator-install.md#webui-install). | 
| <ACM\_CERTIFICATE\_ARN> | AWS Gerenciador de certificados (ACM) Console de gerenciamento da AWS, escolha  Certificados  e selecione seu certificado curinga ARN | 
| <ROUTE53\_HOSTED\_ZONE\_DOMAIN> | Route 53 Console de gerenciamento da AWS, escolha Zonas   hospedadas e selecione o nome da zona hospedada privada usado para ExternalDNS (por exemplo, workspaces.internal) | 
| <SSH\_PORT> | A porta sshd escuta nos pods internos do espaço de trabalho. Padrão 22. Use uma porta não privilegiada (por exemplo, 2222) se seu grupo de segurança ou política corporativa restringir a porta 22. A regra de entrada do SG deve corresponder a esse valor. | 

**DirectSSH e RemoteAccess são mutuamente exclusivos**  
`directSSH`e `remoteAccess` são mutuamente exclusivos. Permitir que ambas as causas `helm upgrade` falhem com: “O DirectSSH e o RemoteAccess são mutuamente exclusivos. Ative somente um.” Desative `remoteAccess` antes de ativar`directSSH`.

Atualize o complemento:

```
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>
```

Para desativar o Direct SSH, consulte[Revogando o acesso direto ao SSH](#direct-ssh-revoke).

### Etapa 3: Verificar se o Direct SSH está ativo
<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>
```

## Conecte-se ao seu espaço de trabalho usando o Direct SSH
<a name="direct-ssh-enduser"></a>

Use os procedimentos a seguir para se conectar ao seu espaço de trabalho usando o Direct SSH, gerenciar suas chaves SSH e solucionar problemas de conexão.

### Como funciona a autenticação SSH
<a name="direct-ssh-enduser-auth"></a>

O Direct SSH usa autenticação de chave pública padrão. Cada usuário gera seu próprio par de chaves SSH e adiciona a chave pública ao seu espaço de trabalho. As chaves privadas nunca saem da máquina do usuário.

A seguir estão os principais fatos sobre o acesso SSH:
+ O SSH fornece o mesmo acesso que o JupyterLab terminal: mesmo usuário (`sagemaker-user`), mesmo sistema de arquivos, mesmas ferramentas.
+ As chaves são por espaço de trabalho. Uma chave em um espaço de trabalho não concede acesso a outros espaços de trabalho.
+ O script de inicialização do SageMaker AI Spaces cria automaticamente o `.ssh/` diretório com as permissões corretas.
+ As chaves persistem nas reinicializações do espaço de trabalho (armazenadas em PVC) e são excluídas quando o espaço de trabalho é excluído.

**Limitação atual**  
O nome de usuário SSH é sempre `sagemaker-user` independente de quem está se conectando. Você não pode usar um nome de usuário pessoal. Todas as sessões são executadas como o mesmo usuário do espaço de trabalho. Per-user A identidade nos prompts e registros de auditoria do shell não está disponível na versão atual.

### Etapa 1: gerar uma chave SSH na sua máquina cliente
<a name="direct-ssh-enduser-keygen"></a>

Execute este comando uma vez para criar seu par de chaves:

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

Isso cria:
+ `~/.ssh/my-workspace-key`— chave privada (mantenha em segredo, nunca compartilhe)
+ `~/.ssh/my-workspace-key.pub`— chave pública (adicione ao seu espaço de trabalho)

### Etapa 2: adicione sua chave pública ao seu espaço de trabalho
<a name="direct-ssh-enduser-addkey"></a>

Use ** um ** dos métodos a seguir para adicionar sua chave pública. Você não precisa fazer as duas coisas.

#### Adicione sua chave por meio do acesso ao navegador da web
<a name="direct-ssh-enduser-addkey-webui"></a>

1. Abra seu espaço de trabalho no navegador (consulte[Acesso pelo navegador da web](browser-access.md)).

1. Abra um terminal. Em JupyterLab, escolha ** Arquivo**, ** Novo**, ** Terminal**. No Editor de código, escolha ** Terminal**, ** Novo terminal**.

1. Copie sua chave pública da sua máquina local: `cat ~/.ssh/my-workspace-key.pub`

1. Cole no terminal do espaço de trabalho:

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

#### Adicione sua chave por meio do kubectl
<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"
```

### Etapa 3: conecte-se ao seu espaço de trabalho usando SSH
<a name="direct-ssh-enduser-connect"></a>

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

**Porta SSH**  
Use a porta SSH que seu administrador configurou para o Direct SSH. Se o administrador manteve a porta padrão (22), você pode omitir a `-p` opção. Se eles configuraram uma porta não padrão (por exemplo, 2222), você deve incluir `-p <SSH_PORT>` ou a conexão falhará com. `Connection refused` Entre em contato com o administrador se não tiver certeza de qual porta usar.

Exemplo:

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

### Etapa 4: configurar o SSH para facilitar o acesso
<a name="direct-ssh-enduser-config"></a>

Essa etapa opcional simplifica as conexões futuras. Adicione o seguinte ao `~/.ssh/config`:

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

`Port`Defina como a porta que seu administrador configurou. Você pode omitir essa linha se o Direct SSH usar a porta padrão (22). Em seguida, conecte-se com: `ssh my-space`

### Etapa 5: Conectar um IDE remoto
<a name="direct-ssh-enduser-ide"></a>

Depois que o Direct SSH funcionar a partir do seu terminal (Etapa 3), qualquer IDE Remote-SSH compatível se conecta usando a mesma `~/.ssh/config` entrada. Você não precisa de AWS configuração adicional para essa conexão.

#### Instale a Remote-SSH extensão
<a name="direct-ssh-enduser-ide-install"></a>


| IDE | Extensão | 
| --- | --- | 
| VS Code | Extensões, pesquise “Remote - SSH”, escolha Instalar (pela Microsoft) | 
| Kiro | Extensões, pesquise “Remote - SSH”, escolha Instalar | 
| Cursor | Extensões, pesquise “Remote - SSH”, escolha Instalar | 

#### Conecte-se a partir do IDE
<a name="direct-ssh-enduser-ide-connect"></a>

1. Abra a paleta de ** comandos ** e escolha "Remote-SSH: Conectar ao host...”

1. Selecione seu espaço de trabalho na lista (usos `~/.ssh/config` da Etapa 4).

1. O IDE instala seu componente de servidor no espaço de trabalho (uma vez, aproximadamente 30 segundos).

1. Uma janela remota é aberta com recursos completos do editor IntelliSense, incluindo terminal e explorador de arquivos.

**Abra seus arquivos de espaço de trabalho no VS Code**  
No VS Code, após a conexão, escolha ** Arquivo**, ** Abrir pasta**, `/home/sagemaker-user` para abrir seus arquivos do espaço de trabalho diretamente.

### Gerenciamento e revogação de chaves
<a name="direct-ssh-enduser-keys"></a>

Você gerencia suas chaves SSH. As chaves SSH são credenciais de longa duração sem expiração automática. Uma chave em `authorized_keys` concede acesso ao seu espaço de trabalho até que você a remova explicitamente.

#### Para girar sua chave
<a name="direct-ssh-enduser-keys-rotate"></a>

Recomendamos que você gire suas chaves periodicamente.

1. Gere um novo par de chaves em sua máquina cliente: `ssh-keygen -t ed25519 -f ~/.ssh/my-workspace-key-new`

1. Adicione a nova chave pública ao seu espaço de trabalho (Etapa 2). As teclas antigas e novas funcionam simultaneamente.

1. Verifique se a nova chave funciona: `ssh -p <SSH_PORT> -i ~/.ssh/my-workspace-key-new sagemaker-user@<hostname>`

1. Remova a chave antiga do terminal `authorized_keys` do seu espaço de trabalho:

   ```
   # 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
   ```

#### Se sua chave privada estiver comprometida
<a name="direct-ssh-enduser-keys-compromised"></a>

Aja imediatamente. Uma chave comprometida concede acesso total ao espaço de trabalho até que você a remova. `authorized_keys`

1. Abra seu espaço de trabalho por meio do acesso ao navegador da web (JupyterLab ou editor de código). Para instruções, consulte [Acesso pelo navegador da web](browser-access.md).

1. Remova a chave comprometida de`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. Verifique se a chave comprometida não funciona mais tentando se conectar a ela. Você deve receber`Permission denied (publickey)`.

1. Se você não conseguir acessar o espaço de trabalho por meio do acesso ao navegador da Web, entre em contato com o administrador do cluster para entrar no pod e limpar `authorized_keys` diretamente.

#### Práticas recomendadas
<a name="direct-ssh-enduser-keys-practices"></a>


| Prática | Por que | 
| --- | --- | 
| Use as teclas ed25519 | Mais curto, mais rápido e mais seguro do que o RSA | 
| Use uma frase secreta na sua chave privada | Protege contra roubo de chaves. Mesmo se roubada, a chave não pode ser usada sem a frase secreta. | 
| Uma chave por dispositivo | É mais fácil revogar o acesso de um único dispositivo sem afetar outros | 
| Nunca compartilhe chaves privadas | Cada usuário e dispositivo devem ter seu próprio par de chaves | 
| Revise authorized\_keys periodicamente | Remova as chaves dos dispositivos que você não usa mais | 

## Revogando o acesso direto ao SSH
<a name="direct-ssh-revoke"></a>

Para evitar deixar uma regra de grupo de segurança aberta depois de desativar o Direct SSH, conclua as três etapas em ordem. Não pule a Etapa 2.

**Notifique seus usuários antes de revogar o acesso**  
Notifique seus usuários antes de revogar o acesso. O ExternalDNS remove os registros DNS em aproximadamente 30 segundos após a Etapa 3, o que bloqueia novas conexões.

### Etapa 1: Desativar no gráfico do Helm
<a name="direct-ssh-revoke-helm"></a>

Remova totalmente a `directSSH` seção do arquivo de configuração do complemento. O Helm usa como padrão `false` quando `directSSH.enabled` a chave está ausente:

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

Como alternativa, defina explicitamente: `enabled: false`

```
directSSH:
  enabled: false
```

### Etapa 2: remover a regra de entrada do grupo de segurança
<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>
```

### Etapa 3: aplicar ao cluster
<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>
```

A execução desse comando remove os serviços headless de todos os espaços de trabalho. O ExternalDNS então exclui os registros do Route 53 A em aproximadamente 30 segundos. Depois que o ExternalDNS remove os registros, novas conexões SSH não podem mais resolver o nome do host do espaço de trabalho.

### O que acontece após a revogação
<a name="direct-ssh-revoke-after"></a>


| Componente | Estado após a revogação | 
| --- | --- | 
| Registros de DNS | O ExternalDNS os remove em aproximadamente 30 segundos. Novas conexões não podem resolver o nome do host do espaço de trabalho. | 
| Regra de entrada do SG | Fechado após a Etapa 2. Nenhum caminho de rede alcança a porta. | 
| Novas conexões SSH | Bloqueado. O nome do host não é mais resolvido e a regra SG fecha a porta. | 
| Dados do espaço de trabalho (PVC) | Não afetado. O PVC mantém seus arquivos, authorized\_keys e chave de host. | 

## Solução de problemas
<a name="direct-ssh-troubleshooting"></a>


| Sintomas | Causa | Correção | 
| --- | --- | --- | 
| NXDOMAIN | O DNS não está resolvendo | Verifique se existe uma zona hospedada, associada à VPC, DNS externo em execução | 
| Connection timed out | Bloqueio de SG: regra adicionada ao SG errado ou totalmente ausente | Verifique o OverrideVpcConfig grupo de instâncias (etapa administrativa 1). Verifique se a regra de entrada TCP abrange seu CIDR de origem. | 
| Connection refused | sshd não está funcionando | Verifique se o espaço está em estado de execução e directSSH está ativado | 
| Permission denied (publickey) | A chave não está inserida authorized\_keys | Adicionar chave pública por meio do acesso ao navegador da web ou kubectl (etapa 2 do usuário final) | 
| Host key changedaviso | O espaço foi recriado (novo pod, nova chave de host) | Na sua máquina cliente: em ssh-keygen -R <hostname> seguida, reconecte | 
| Stale DNS records after space deletion | DNS externo em execução com --policy=upsert-only | Atualize a implantação do ExternalDNS para --policy=sync e adicione. --txt-owner-id=<cluster-name> Limpe manualmente os registros obsoletos existentes: aws route53 list-resource-record-sets --hosted-zone-id <ZONE\_ID> | 
| IDE: “Não foi possível estabelecer a conexão” | sshd ainda não está pronto | Aguarde de 60 a 90 segundos após a criação do espaço de trabalho e tente novamente | 
| IDE: trava em “Instalando o VS Code Server” | O espaço de trabalho não tem acesso à Internet | Seu espaço de trabalho baixa o binário do servidor VS Code de um host externo na primeira conexão. Entre em contato com o administrador se o espaço de trabalho estiver vazio. | 
| IDE: Permission denied | IdentityFile incompatibilidade de caminho | Verifique se o terminal SSH funciona primeiro e depois faça o check-in IdentityFile \~/.ssh/config | 
| IDE: A conexão cai após a inatividade | Nenhum keepalive configurado | Adicionar ServerAliveInterval 15 e ServerAliveCountMax 3 para \~/.ssh/config | 

## (Opcional) Configurando pré-requisitos
<a name="direct-ssh-appendix"></a>

Use esta seção somente se o acesso ao navegador da Web ainda não estiver habilitado ou para verificar ou atualizar sua configuração de DNS externo.

### Instalando do zero
<a name="direct-ssh-appendix-scratch"></a>

Se o acesso ao navegador da Web ainda não estiver configurado, você precisará do seguinte antes de ativar o Direct SSH:

1. **Zona hospedada do Route 53 ** — um domínio ou subdomínio que você possui, registrado no Route 53

1. **DNS externo ** — implantado por meio de complementos do EKS, com a função IAM com permissões do Route 53

1. **AWS Controlador de balanceador de carga ** — necessário se você usar o acesso ao navegador da web (entrada ALB). Para obter notas de HyperPod-specific instalação, consulte[AWS Controlador de balanceador de carga: requisito de HyperPod vPCid](#direct-ssh-appendix-lbc).

1. **Conectividade VPC ** — VPN ou conexão direta de máquinas clientes à VPC

Para ver as dependências adicionais e as etapas de configuração de acesso ao navegador da Web, consulte[Instale o SageMaker AI Spaces Add-on](operator-install.md).

### AWS Controlador de balanceador de carga: requisito de HyperPod vPCid
<a name="direct-ssh-appendix-lbc"></a>

A documentação padrão AWS de instalação do Load Balancer Controller não menciona o `vpcId` parâmetro. Em HyperPod clusters, a omissão `vpcId` faz com que a instalação falhe. Você deve fornecê-lo explicitamente.

Obtenha seu ID de VPC:

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

Instale com os HyperPod parâmetros necessários:

```
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>
```


| Parâmetro | Por que exigido em HyperPod | 
| --- | --- | 
| vpcId | HyperPod A VPC não pode ser descoberta automaticamente pelo controlador. A instalação falha sem ele. | 
| enableServiceMutatorWebhook=false | O webhook mutante entra em conflito com a configuração HyperPod do serviço | 
| serviceAccount.create=false | A conta de serviço deve ser pré-criada com a anotação correta do IRSA ou do Pod Identity antes da instalação | 

Crie a conta de serviço (aws-load-balancer-controller) com a anotação de função do IAM apropriada antes de executar esse comando. Para obter mais informações sobre a política do IAM e as etapas de criação da conta de serviço, consulte a configuração do [ Amazon EKS Load Balancer Controller IRSA ](https://docs.aws.amazon.com/eks/latest/userguide/lbc-helm.html) no Guia do usuário do Amazon EKS.

### Configuração de DNS externo
<a name="direct-ssh-appendix-externaldns"></a>

O ExternalDNS sincroniza os serviços do Kubernetes com os provedores de DNS. Configure o ExternalDNS com as seguintes configurações ao usá-lo com o Amazon Route 53 em um ambiente de produção.

**O ExternalDNS requer a política de sincronização**  
Você deve configurar o ExternalDNS com. `--policy=sync`

Por padrão, o ExternalDNS usa. `--policy=upsert-only` Isso cria e atualiza registros DNS, mas nunca os exclui. Quando você exclui um espaço de trabalho, os registros A e TXT no Amazon Route 53 permanecem como entradas obsoletas.

Use `--policy=upsert-only` somente para testes e altere `--policy=sync` para produção. Você também deve definir o `--txt-owner-id` sinalizador, que informa ao ExternalDNS quais registros ele possui e quais registros excluir na limpeza.

Configure sua implantação de DNS externo com os seguintes argumentos:

```
--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
```

Nos argumentos anteriores, substitua os seguintes valores:
+ `<ROUTE53_HOSTED_ZONE>`— seu domínio de zona hospedada privada do Amazon Route 53 (por exemplo,`workspaces.internal`)
+ `<CLUSTER_NAME>`— o nome do seu cluster EKS (por exemplo,`my-hyperpod-cluster`)

Para verificar sua política atual de ExternalDNS, execute o seguinte comando:

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