Outro método de autenticação seria por meio de um par de chaves pública e privada. Nesse método, cada cliente possui uma chave privada que o identifica e deve ser protegida. O servidor recebe a chave pública correspondente de cada cliente para autenticar. Desta forma, não há, à princípio, necessidade de senha. Porém, o próprio certificado pode exigir uma senha para ser acessado, mas assim, ele será único para todos os servidores e não haverá tráfego de senha entre servidor e cliente. Vejamos como fazer isto:

No cliente, é preciso gerar as chaves com o seguinte comando:

ssh-keygen

Ele perguntará por uma senha. Caso queira fornecer, digite-a. Caso queira que o acesso seja direto, deixe em branco. Por padrão, ele gerará dois arquivos: ~/.ssh/id_rsa e ~/.ssh/id_rsa.pub. Respectivamente eles são a chave privada e pública em algorítmo RSA. Copie a chave pública para o servidor (assumindo que o IP dele é 10.0.0.8):

scp ~/.ssh/id_rsa.pub 10.0.0.8:~

No servidor, insira a chave pública recém recebida na lista de chaves autorizadas:

cat ~/id_rsa.pub >> ~/.ssh/authorized_keys

Feito isto, basta alterar o modo de autenticação do servidor. Acesse o arquivo de configuração /etc/ssh/sshd_config e altere, acrescente ou descomente as seguintes opções para que confira com o modelo:

# Define autenticação por chave pública RSA.
RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile     .ssh/authorized_keys

# Desabilita autenticação por senha
PasswordAuthentication no
PermitEmptyPasswords no

Reinicialize o serviço do ssh. No Slackware execute /etc/rc.d/rc.sshd restart. Agora está pronto, basta testar. No cliente, pode-ser conectar usando duas sintaxes:

ssh 10.0.0.8

Use o exemplo acima caso o nome do arquivo e caminho da chave seja o padrão, ~/.ssh/id_rsa. Se for diferente, a seguinte sintaxe será necessária:

ssh -i <caminho completo para chave privada> 10.0.0.8

Para mais informações, o bom e velho man sempre ajuda.

domain dominio_nis server endereço_do_servidor

Agora é preciso indicar ao sistema que procure as informações de login no NIS. Para isto, alteraremos o arquivo /etc/nsswitch.conf. Localize as linhas que contenham as configurações para os arquivos passwd, group e shadow. Altere para o seguinte:

passwd:		files nis
shadow:		files nis
group:		files nis

Isto fará com que o sistema procure primeiramente nos arquivos locais, caso não encontre, procurará via NIS. Mais outro detalhe, é importante para que isto aconteça. No final do arquivo /etc/passwd, acrescente uma linha igual à esta:

+::::::

No arquivo /etc/group, por sua vez, acrescente:

+:::

Está quase pronto. Agora para usarmos a autenticação remota, precisamos definir nosso domínio NIS com o comando:

nisdomainname [dominio]

Observe que o domínio do servidor e cliente deverão ser o mesmo. Após, apenas inicializaremos o NIS cliente com o comando:

/usr/sbin/ypbind

Depois de tudo isto, os usuários terão que ser cadastrados apenas no servidor, podendo ser logados de qualquer máquina cliente do servidor NIS.

Para ele funcionar, é necessário que o serviço de rpc esteja habilitado e rodando, tanto no servidor como no cliente, pois as trocas de informações são feitas pelo portmap.

Vamos à configuração!

O servidor é extremamente simples. Com o serviço rpc rodando, você precisará apenas  definir seu domínio NIS com o comando:

nisdomainname [dominio]

Após, rode o comando ypserv, que normalmente está em /usr/sbin.

/usr/sbin/ypserv

Para um servidor master, precisará também executar o comando rpc.yppasswdd que está em /usr/sbin.

/usr/sbin/rpc.yppasswdd

Para servidor slave, em lugar do rpc.yppasswdd, use o comando rpc.ypxfrd, que é um proxy para o master.

/usr/sbin/rpc.ypxfrd

Para cada usuário criado no sistema, é necessário ir até o diretório /var/yp e rodar o comando:

make

Sem isto, o usuário criado não será válido no NIS. Pronto, seu servidor está rodando e aguardando requisições de login!