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

Aqui no trabalho, temos uma conta de login compartilhada não raiz no UNIX, usada para administrar um aplicativo específico. A política é não permitir logins diretos na conta compartilhada; você deve fazer o login 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 digite minha senha uma vez por dia e permita que o encaminhamento do agente elimine as solicitações de senha pelo resto do dia. É muito legal

No entanto, alguns sistemas estão bloqueados, então eu realmente tenho que usar o comando "su" para acessar a conta compartilhada. Arg! Voltar para inserir senhas o tempo todo!

Existem informações suficientes registradas com 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 chaves públicas / privadas forem usadas?

Eu tinha uma aparência de administrador em / var / log / secure e apenas diz que uma chave pública foi aceita para uma conta de usuário de um endereço IP específico. Não disse quem é a chave pública ou quem fez a autenticação.

Existem muitos níveis de log disponíveis através do sshd_configarquivo. Veja a página de manual e procure LogLevel. O nível padrão é, INFOmas é trivialmente fácil aumentar para um VERBOSEou até um dos DEBUG#níveis.

Além disso, você deve explorar sudocomo uma alternativa ao su. Uma discussão completa dos benefícios sudoseria uma questão própria. Mas posso dizer que, com sudovocê, você pode personalizar com que frequência precisa digitar sua senha, quais comandos podem ser executados etc., todos controláveis ​​através do arquivo de configuração do sudoers .

Outra maneira seria sair authorized_keysdo escopo do usuário (por exemplo, para /etc/ssh/authorized_keys) para que apenas os administradores do sistema controlassem quais chaves públicas podem ser usadas para fazer logon em determinadas contas.

Costumávamos alterar a AuthorizedKeysFilediretiva sshd_configpara algo como o seguinte.

AuthorizedKeysFile /etc/ssh/authorized_keys/%u

Em seguida, crie e preencha o /etc/ssh/authorized_keysdiretório com arquivos para cada usuário que deve poder fazer login, certificando-se de que o rootarquivo seja legível / gravável apenas para root e outros arquivos legíveis por um usuário apropriado, como este:

-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 terão permissão para fazer login em uma determinada conta. É bastante comum que, para cada conta de usuário, também exista um grupo respectivo.

Usar 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 (também não precisa defini-la) e não precisa alterá-la apenas porque um funcionário deixou sua empresa, apenas remove sua chave pública; e, é claro, com as opções SSH ( http://www.openbsd.org/cgi-bin/man.cgi?query=sshd&sektion=8#SSHRC), você pode detalhar o que e de onde um determinado usuário pode ter acesso.

A autenticação de chave pública / privada SSH é separada da autenticação do host. Você está sem sorte aqui. No entanto, você pode solicitar que membros de um determinado grupo executem determinados comandos administrativos via sudosem senha - como o exemplo abaixo, permite que os usuários do secretariesgrupo gerenciem contas:

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