> ## Documentation Index
> Fetch the complete documentation index at: https://docs.basaltic.sh/llms.txt
> Use this file to discover all available pages before exploring further.

# Acesso SSH com IAM

> Use logins Linux individuais e credenciais SSH revogáveis para pessoas e automação.

Adicione uma chave pública SSH ao seu perfil ou a uma conta de serviço e, em seguida, conceda essa permissão de identidade para acessar a instância. Uma chave não tem permissões próprias e você não a anexa a cada instância.

As pessoas usam o nome de usuário permanente que escolherem para seu perfil Basaltic, como `ana`. É globalmente único e compartilhado em todas as organizações que eles se juntam. As contas de serviço usam `sa_<name>`: uma conta de serviço chamada `deploy` faz login como `sa_deploy`.

O UID e o GID primário pertencem à associação à organização. Você pode consultá-los, junto com o diretório pessoal, em **Settings** do usuário na organização. Novas identidades humanas usam `/home/bsu_<uid>`; contas de serviço usam `/home/bsa_<uid>`. As identidades existentes mantêm seus diretórios atuais, inclusive `/home/<username>`. Use o campo `home_directory` retornado ou `$HOME`, em vez de deduzir o caminho pelo login. O UID e o GID definem a propriedade dos arquivos.

<a id="choose-a-username" />

## Escolha um nome de usuário

O console solicita que você escolha um nome de usuário após fazer login, se não tiver um. Escolha com cuidado: ele não pode ser alterado ou reutilizado por outra pessoa depois de você excluir seu perfil. Nomes de exibição e endereços de e-mail permanecem separados.

Use 1 a 32 letras minúsculas, dígitos, sublinhados ou hífens, começando com uma letra ou sublinhado. Nomes de contas de sistema e os prefixos `sa_`, `bsu_` e `bsa_` são reservados. Os convites usam o nome de usuário escolhido pelo destinatário; um administrador da organização não pode escolhê-lo ou alterá-lo para eles.

Os nomes de conta de serviço usam 2 a 29 letras minúsculas, dígitos ou hífens, começam com uma letra e terminam com uma letra ou um dígito. Eles são imutáveis e únicos dentro da conta proprietária. Não há nenhuma configuração separada de nome de usuário Linux.

Um convidado em execução deve usar o guest-agent 1.12.1-1 ou posterior para diretórios home nomeados. Uma conta de convidado local em conflito bloqueia o login em vez de assumir os arquivos ou privilégios dessa conta.

Excluir uma identidade não remove seus diretórios pessoais nas instâncias. Remover e adicionar novamente uma pessoa, ou excluir e recriar uma conta de serviço com o mesmo nome, aloca um novo UID e um diretório distinto. O nome de login permanece igual; a nova identidade não herda o diretório anterior nem seus arquivos. Identidades existentes mantêm o diretório alocado durante atualizações comuns e a escolha do nome de usuário. O agente nunca transfere a propriedade automaticamente e recusa um diretório que pertença a outra identidade.

<a id="add-your-public-key" />

## Adicione sua chave pública

Mantenha a chave privada no seu computador. Faça o upload da única linha de chave pública do OpenSSH a partir do arquivo `.pub`. Cada identidade suporta até 50 chaves, com uma expiração opcional. A expiração e a revogação impedem novos logins sem reconstruir a VM.

<Tabs>
  <Tab title="Console">
    Abra o perfil da sua conta e encontre **SSH Keys**. Escolha **Add SSH Key**, digite um **Name** e cole a chave pública. Seu perfil mostra seu nome de usuário permanente. IDs numéricos específicos da organização aparecem nas configurações de usuário da organização.
  </Tab>

  <Tab title="API">
    ```http theme={null}
    POST https://iam.basaltic.sh/v1/auth/ssh-keys
    Content-Type: application/json

    {
      "name": "workstation",
      "public_key": "ssh-ed25519 <your-public-key>"
    }
    ```

    Use sua sessão de login humano. As credenciais SSH pessoais não podem ser gerenciadas usando uma conta de serviço ou credenciais de função assumida.
  </Tab>

  <Tab title="CLI">
    ```bash theme={null}
    basaltic iam ssh-key create --name workstation --public-key "$(cat ~/.ssh/id_ed25519.pub)"
    basaltic iam auth get-linux-identity
    ```

    Use um perfil autenticado como seu usuário.
  </Tab>

  <Tab title="Go">
    ```go theme={null}
    key, err := iam.New(cfg).CreatePersonalSSHKey(ctx, &iam.SSHKeyCreateRequest{
        Name: "workstation",
        PublicKey: publicKey,
    })
    ```

    Configure o cliente com sua sessão humana. `publicKey` contém a linha de chave pública do OpenSSH, nunca a chave privada.
  </Tab>
</Tabs>

Para automação, gerencie as credenciais SSH na página da conta de serviço. Suas rotas de API `ssh-keys` e `linux-identity` estão em `/v1/service-accounts/{service_account_id}`. Gerenciar essas credenciais requer `iam:ManageCredentials` nessa conta de serviço. O SSH não emite credenciais de API para o convidado nem dá a identidade de login às cargas de trabalho.

<a id="grant-login-and-sudo-separately" />

## Conceder login e sudo separadamente

Uma pessoa tem uma função efetiva do IAM em cada conta, incluindo funções atribuídas por meio de grupos. Vários grupos podem atribuir a mesma função. Um segundo papel conflitante é rejeitado. O SSH usa essa função de conta atual; não há seletor de função em uma chave SSH.

Conceda estas ações nos CRNs de instância pretendidos:

| Ação e aventura | Acesso ao site |
| - | - |
| `compute:SSHLogin` | Abra uma sessão SSH como o usuário Linux da identidade |
| `compute:SSHAdminLogin` | Use sudo; também requer `compute:SSHLogin` |

Por exemplo, esta política permite o login comum em uma instância:

```json theme={null}
{
  "version": "2024-01-01",
  "statements": [{
    "effect": "allow",
    "actions": ["compute:SSHLogin"],
    "resources": ["crn:compute:sa-saopaulo-1:my-account:instance/web"]
  }]
}
```

Anexe a política à função de conta do humano ou diretamente à conta do serviço de automação. A confiança de função, a associação de grupo atual, as condições de marca de recurso, os limites de permissão e as negações explícitas continuam a ser aplicadas. A função de carga de trabalho do IAM da instância é separada da autoridade de login do SSH.

<a id="login-shell" />

## Shell de login

Com o agente convidado 1.14.0-1 ou posterior, os usuários do IAM usam o Bash quando ele está instalado, caso contrário, `/bin/sh`. Esse padrão se aplica a usuários do IAM novos e existentes. Reconecte-se após atualizar o agente convidado para iniciar uma sessão com o shell selecionado.

Usuários do IAM são contas virtuais e não têm entradas em `/etc/passwd`. O shell de login deles é selecionado automaticamente; a personalização do shell por usuário não é suportada. `chsh` e `usermod` não podem alterar estas contas virtuais. As contas Linux locais mantêm seus shells configurados e usam as ferramentas usuais de conta de distribuição.

<a id="enable-an-existing-guest" />

## Ativar um convidado existente

A integração SSH do IAM suporta Debian 11, 12 e 13, Ubuntu 20.04, 22.04 e 24.04 e Rocky Linux 9 com aplicação do SELinux. Novas instâncias criadas a partir dessas imagens de plataforma habilitam o IAM SSH durante a primeira inicialização.

Para uma VM existente, atualize o agente convidado do repositório de pacotes Basaltic configurado para a versão 1.11.0-1 ou posterior. Mantenha uma sessão de administração em funcionamento enquanto habilita a integração:

```sh theme={null}
sudo -n /usr/bin/basaltic-guest-agent ssh-install
sudo -n systemctl daemon-reload
sudo -n systemctl restart basaltic-guest-agent.service
sudo -n systemctl reload ssh.service
```

No Rocky Linux 9, use `sshd.service` no último comando. O instalador preserva o perfil e os recursos selecionados do authselect por meio de um perfil gerenciado. O SELinux continua a ser aplicado.

Em seguida, verifique uma nova conexão com o nome de usuário Linux do seu perfil ou conta de serviço. O primeiro login bem sucedido cria seu diretório home. Com o agente convidado 1.14.3-1 ou posterior, as novas casas incluem os arquivos de inicialização padrão da distribuição do shell de `/etc/skel`, incluindo suas configurações de cor de prompt e comando. Logins posteriores deixam os arquivos existentes inalterados. A ativação do acesso nomeado não migra um login `basaltic` existente ou altera a propriedade de seus arquivos.

<Note>
  Outras distribuições e configurações personalizadas do SSH Match precisam de uma integração validada separadamente. Uma configuração authselect deve passar por `authselect check` antes da instalação; arquivos gerados modificados localmente precisam ser reconciliados através do authselect primeiro. O instalador recusa configurações que não pode gerenciar com segurança. Não desative os controles de segurança do convidado para forçar a ativação.
</Note>

<a id="revocation-and-existing-sessions" />

## Revogação e sessões existentes

As verificações de pesquisa de chaves, login e sudo consultam o estado atual do IAM. Remover uma chave, desabilitar sua identidade ou remover sua permissão aplicável bloqueia novos logins SSH. Uma interrupção do plano de controle ou dos metadados também bloqueia o novo acesso porque uma permissão não pode ser verificada.

As sessões SSH já estabelecidas e os shells root continuam. A revogação não encerra processos existentes. O Sudo reverifica as permissões de login/administrador atuais e se a identidade está habilitada. Revogar uma chave sozinha não remove essas permissões de uma sessão já autenticada.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.