Os recursos de registro de log do SSH são equivalentes ao su logging para autenticação de chave privada / pública?

Question

Aqui, no trabalho, temos uma conta de login compartilhada não-raiz no UNIX que é usada para administrar um aplicativo específico. A política é não permitir logins diretos na conta compartilhada; você deve logar como você mesmo e usar o comando "su" para mudar para a conta compartilhada. Isso é para fins de registro / segurança.

Comecei a usar a autenticação de chave pública / privada SSH com um agente para permitir que eu insira minha senha uma vez por dia e permitir que o encaminhamento do agente elimine os prompts de senha pelo resto do dia. É muito legal.

No entanto, alguns sistemas estão bloqueados, por isso preciso usar o comando "su" para acessar a conta compartilhada. Arg! Voltar a digitar senhas o tempo todo!

Há informações suficientes registradas com a autenticação de chave pública / privada SSH para que eu possa ter uma chance razoável de solicitar uma alteração de política para permitir logins remotos em uma conta compartilhada se forem usadas chaves públicas / privadas?

Eu tive uma aparência de administrador em / var / log / secure e ela apenas diz que uma chave pública foi aceita para uma conta de usuário de um determinado endereço IP. Não foi dito quem era a chave pública ou quem foi a chave privada que fez a autenticação.

    

Answer 1

Existem muitos níveis de registro disponíveis através do arquivo sshd_config . Veja a página de manual e procure por LogLevel . O nível padrão é INFO , mas é trivialmente fácil colocá-lo em VERBOSE ou até mesmo um dos níveis DEBUG# .

Além disso, você deve explorar sudo como uma alternativa para su . Uma discussão completa dos benefícios de sudo seria uma questão própria. Mas eu posso dizer que com sudo você pode personalizar quantas vezes você tem que digitar sua senha, quais comandos podem ser executados, etc., tudo controlável através do sudo arquivo de configuração.

    

Answer 2

Outra maneira seria mover authorized_keys fora do escopo do usuário (por exemplo, para /etc/ssh/authorized_keys ), de modo que apenas os sysadmins controlassem quais chaves públicas podem ser usadas para efetuar login em determinadas contas.

Estamos habituados a alterar a diretiva AuthorizedKeysFile em sshd_config para algo como o seguinte.

AuthorizedKeysFile /etc/ssh/authorized_keys/%u

Em seguida, crie e preencha o diretório /etc/ssh/authorized_keys com arquivos para cada usuário que deveria poder fazer login, certificando-se de que o arquivo root seja legível / gravável somente para raiz e outros arquivos legíveis por um usuário apropriado, como: / p>

-rw-------  1 root root    1,7K 2008-05-14 14:38 root
-rw-r-----  1 root john     224 2008-11-18 13:15 john

Cada arquivo contém um conjunto de chaves públicas que poderão fazer login em uma determinada conta. É bastante comum que cada conta de usuário também tenha um respectivo grupo.

O uso de chaves públicas / privadas é um método muito melhor para controlar o acesso de usuários remotos. Você não precisa alterar a senha todos os meses (você também não precisa defini-la), e não precisa alterá-la apenas porque um funcionário deixou sua empresa, basta remover sua chave pública; e, claro, com opções de SSH ( http://www.openbsd.org/cgi-bin/man.cgi?query=sshd&sektion=8#SSHRC ) você pode refinar o que e de onde um determinado usuário pode ter acesso.

    

Answer 3

A autenticação de chave pública / privada SSH é separada da autenticação do host. Você está sem sorte aqui. Você pode solicitar que os membros de um determinado grupo tenham permissão para executar determinados comandos administrativos via sudo sem senha - como no exemplo abaixo, os usuários do secretaries group podem gerenciar contas:

# file: /etc/sudoers
...
%secretaries    ALL= NOPASSWD: /usr/bin/adduser, /usr/bin/rmuser   
...