Pular para o conteúdo
JelinaJelina DocumentationDocumentação técnica
Voltar ao site oficial

Gestão do acesso remoto

A “Gestão do acesso remoto” centraliza as credenciais de login SSH e as conexões remotas. A antiga “Gestão de conexões remotas” da frota foi renomeada, e também há uma entrada no nível do dispositivo.

Página Conteúdo
Frota → Gestão do acesso remoto → Gestão de conexões Visualizar conexões ativas e encerrá-las conforme as permissões
Frota → Gestão do acesso remoto → Gestão de chaves Armazenar credenciais SSH compartilhadas pela frota
Dispositivo → Gestão do acesso remoto Armazenar credenciais SSH específicas do dispositivo, consultar itens herdados e confirmar a identidade do host; apenas gestão de chaves
Visão geral do dispositivo → Área de trabalho remota Selecionar credenciais salvas ou usar uma senha para iniciar a conexão; sem upload

Master e Admin gerenciam credenciais e identidades de host. Por padrão, as credenciais podem ser usadas “Somente por administradores”. O administrador pode autorizar explicitamente “Membros com permissão de conexão remota”, incluindo Developer. Observer pode apenas visualizar metadados, sem conectar ou modificar.

As permissões de uso e de gestão das credenciais são separadas. Poder usar uma credencial não permite visualizar ou baixar a chave privada. Nenhuma função possui uma opção para visualizar ou exportar chaves privadas. As operações de conexão registram o usuário que efetivamente utilizou a credencial.

  1. O administrador do dispositivo configura a chave pública do usuário para a conta de destino no sistema, ou a chave pública da CA emissora e os principals permitidos.
  2. Na gestão de chaves da frota ou do dispositivo, clique em “Adicionar credencial SSH” e informe o nome, a conta do sistema no dispositivo e o método de autenticação.
  3. Envie a chave privada do usuário. Para autenticação por certificado, envie também o certificado de usuário emitido externamente. Se a chave privada estiver criptografada, forneça sua frase secreta. Não envie a chave privada da CA.
  4. Selecione os membros autorizados, defina a credencial como padrão se necessário e salve.
  5. Na página do dispositivo, registre a chave pública do host e confirme a impressão digital após verificá-la por um meio confiável.
  6. Na “Área de trabalho remota”, o usuário seleciona a conta, o método de autenticação e a credencial salva e verifica a conexão.

Ao salvar, o sistema identifica automaticamente o algoritmo e verifica a assinatura e a validade do certificado, além da correspondência com a chave privada do usuário. Salvar a credencial e suas permissões de uso constitui a autorização para conectar pela plataforma; não é necessário criar uma autorização separada para a chave pública ou a CA. As chaves públicas, a CA, os principals e as restrições de autenticação no dispositivo continuam sob responsabilidade do usuário.

O dispositivo não precisa buscar chaves na nuvem nem informar versões ou estados de aplicação dessas configurações. A plataforma não edita arquivos do dispositivo. O salvamento bem-sucedido indica que a configuração foi armazenada na nuvem; a validação do login é realizada pelo serviço SSH do dispositivo.

O tutorial completo para geração de chaves no Windows PowerShell e no Linux, emissão por CA, autorização no dispositivo, upload à nuvem e verificação da conexão está em autenticação por chaves e certificados SSH. O login comum por chave não exige uma CA. O login por certificado de usuário OpenSSH exige o certificado e a chave privada correspondente; a chave privada da CA permanece sempre com o emissor.

Prioridade do dispositivo, herança da frota e credenciais padrão

Seção intitulada “Prioridade do dispositivo, herança da frota e credenciais padrão”

A herança é determinada pela conta de destino no sistema e pelo método de autenticação:

  • Quando existe uma configuração no dispositivo, somente as credenciais correspondentes do dispositivo podem ser usadas. O item da frota é exibido como substituído.
  • Na ausência de uma configuração correspondente no dispositivo, são usadas as credenciais da frota, sem necessidade de habilitar uma opção de herança.
  • Se a credencial do dispositivo estiver expirada, desativada ou revogada, ou se o usuário atual não tiver permissão para utilizá-la, não haverá retorno automático às credenciais da frota nem mudança para autenticação por senha.
  • É possível salvar várias credenciais no mesmo nível e definir uma como padrão. A marcação como padrão não dispensa as verificações de disponibilidade e permissão.

Os itens herdados são somente leitura e devem ser editados no nível da frota. Desativar ou revogar uma credencial mantém a substituição das credenciais da frota pelo dispositivo. Excluir a última configuração correspondente no dispositivo pode restabelecer a herança da frota; verifique o impacto informado na caixa de confirmação antes de prosseguir.

O escopo das credenciais restringe apenas o acesso pelo JelinaCloud. Para também isolar diferentes frotas ou contas no próprio dispositivo, configure chaves públicas, CAs ou regras de principals de certificado distintos.

Operação Comportamento
Editar Altera o nome, os membros autorizados e a marcação como padrão; não exibe novamente a chave privada nem a frase secreta
Atualizar chave/certificado Envia uma nova chave privada de usuário, um certificado opcional e a frase secreta necessária; mantém a conta, o escopo e o método originais
Desativar/ativar A desativação é reversível; impede novas conexões e provoca nova verificação e encerramento das conexões existentes
Revogar credencial Impede a reativação desse item e remove sua chave privada criptografada; não afeta outros itens salvos de forma independente nem a confiança configurada no dispositivo
Excluir Remove o conteúdo criptografado e preserva os metadados de auditoria; excluir um item do dispositivo pode restabelecer a herança da frota

O JelinaCloud não emite nem renova automaticamente certificados de usuário. Antes do vencimento, solicite um novo certificado ao administrador da sua CA, atualize-o na página de gestão e valide-o. Alterar a validade exibida na página não prorroga o certificado.

As operações da plataforma afetam apenas as conexões realizadas pelo JelinaCloud e não removem automaticamente entradas de authorized_keys, CAs ou KRLs locais no dispositivo. Para bloquear o acesso SSH direto, o administrador do dispositivo deve implementar a revogação e remover as autorizações antigas.

Conexões por chave e por certificado exigem a verificação da identidade do host do dispositivo. Essa identidade é diferente do certificado de usuário e da CA emissora.

  1. No próprio dispositivo ou por um canal confiável, execute cat /etc/ssh/ssh_host_*_key.pub para obter a chave pública de host existente.
  2. Na “Gestão do acesso remoto” do dispositivo, expanda “Identidade do host do dispositivo”, clique em “Registrar chave pública do host” e cole uma linha por vez.
  3. Execute ssh-keygen -lf <arquivo_da_chave_pública_do_host_correspondente> -E sha256 no dispositivo e compare a impressão digital completa com a exibida na página.
  4. Se forem iguais, clique em “Verificar e confirmar”. Registre e verifique separadamente cada algoritmo.

São aceitas apenas chaves públicas de host, e não chaves públicas de usuário, certificados de usuário, chaves públicas de CA ou chaves privadas. Há suporte a Ed25519, ECDSA nistp256/384/521 e RSA de 2048 a 8192 bits. O algoritmo é identificado automaticamente, e o backend seleciona uma chave pública confirmada conforme o algoritmo efetivamente negociado pelo dispositivo. Não é necessário modificar o guacd nem pedir ao usuário que escolha um algoritmo.

Após reinstalar o dispositivo ou alterar a identidade do host, é necessário verificá-la novamente por um meio confiável. O sistema não passa a confiar automaticamente em uma nova chave pública apenas porque o dispositivo está Online.

A página de gestão mantém apenas as credenciais de login e a identidade do host. Ela não oferece mais edição separada de chaves públicas, autorizações de CA, certificados pessoais ou políticas de frota/dispositivo. O administrador do dispositivo configura quais contas podem entrar com determinadas chaves públicas ou principals de CA.

A porta padrão utilizada pela plataforma e os métodos de autenticação permitidos globalmente são mantidos pelo administrador da plataforma. A página de conexão continua exibindo os métodos atualmente permitidos. Para restringir formas de autenticação no acesso SSH direto ao dispositivo, como senha, altere a configuração SSH do próprio dispositivo.

As cotas de conexão, os limites por usuário e dispositivo e os tempos de inatividade e duração máxima continuam sujeitos aos limites do plano da organização e à capacidade do servidor. Os locatários apenas consultam os valores efetivos e não podem ampliá-los.

Conexões em tempo real e registros de operações

Seção intitulada “Conexões em tempo real e registros de operações”

A gestão de conexões exibe as conexões ativas e permite encerrá-las conforme as permissões. As sessões em tempo real são mantidas na memória do serviço, sem histórico persistente de sessões; as operações continuam sendo registradas nos logs existentes. Após reiniciar o serviço ou liberar o estado de uma sessão, a conexão antiga não pode ser restaurada. É necessário conectar novamente.

Proteção da chave privada e transferência do dispositivo

Seção intitulada “Proteção da chave privada e transferência do dispositivo”

A chave privada do usuário e a frase secreta necessária são armazenadas de forma criptografada. A lista de metadados mostra apenas nome, conta do sistema, escopo, algoritmo, validade, permissões e estado. A chave privada da CA fica com o emissor do usuário e não é enviada à plataforma. A plataforma não armazena chaves privadas no cache local do navegador para permitir logins repetidos.

Após mover um dispositivo para outra frota ou organização, suas antigas credenciais e autorizações específicas deixam de ser utilizáveis, e o conteúdo criptografado das credenciais antigas é removido. Elas não são restauradas automaticamente se o dispositivo retornar ao escopo anterior. Configure novamente as credenciais do escopo atual e verifique a identidade do host. A confiança antiga existente no dispositivo continua sob responsabilidade do administrador do dispositivo.