Compartilhando chave pública com ssh

5

É possível configurar de alguma forma um servidor ssh que não requer um nome de usuário, senha ou certificado para efetuar login? Se isso não for possível, se eu desse a todos os clientes a mesma chave pública, cada conexão seria criptografada individualmente? (ou seja, o usuário A não pode descriptografar a carga útil da conexão do usuário B)

Desejo fornecer acesso a um único programa, que solicitará um nome de usuário e senha.

A criptografia é essencial, e os usuários não devem ser capazes de espionar uns aos outros

Obrigado

    
por jtnire 22.06.2010 / 14:20

5 respostas

10

Eu não acho que você possa remover a parte de autenticação do SSH porque você sempre precisa de um nome de usuário para abrir uma sessão, mas pode definir uma senha em branco e definir PermitEmptyPasswords como yes na configuração do sshd. Mas isso não é realmente seguro, usando a autenticação de chaves é melhor.

Se você der uma chave pública aos seus clientes, isso significa que eles podem permitir que você se conecte ao servidor ssh, não ao seu.
Eu acho que você quer que os clientes se conectem ao seu servidor ssh. Nesse caso, os clientes precisam fornecer sua chave pública e permitir que eles se conectem. Se todos os clientes usassem a mesma chave pública para se conectar ao seu servidor ssh, isso significaria que todos os clientes usariam a mesma chave privada, e isso não é uma opção (não é sua função fornecer uma chave privada e uma chave privada não deve ser compartilhada )

Em relação à criptografia e snooping, a criptografia é feita com chaves de sessão e não com chave pública / privada, mas para trocar chaves de sessão, ssh use chave pública / privada.
Portanto, se todos os seus clientes usassem as mesmas chaves privadas, se eles espionassem uma sessão desde o início, eles poderiam descriptografar a sessão, se eles espionassem a sessão após a troca de chaves de sessão, seria muito difícil descriptografar a sessão.

Um bom artigo sobre como o ssh funciona link

    
por 22.06.2010 / 14:38
1

Pouco tarde, mas você pode forçar um usuário a executar um programa em particular no login (por qualquer meio), definindo seu shell para esse programa em / etc / passwd. Eu acredito que há uma maneira mais complexa de usar o sshd usando arquivos .sshrc, mas eu não estou presumindo que você esteja no OpenSSH - é tudo nos arquivos man.

    
por 03.11.2011 / 00:16
1

Pense na chave privada como o segredo . Quando você provar alguma coisa, como sua identidade neste caso, você pode reivindicar que você conhece um segredo, neste caso, a chave ssh privada. A chave pública é aquela: "pública" e, nesse sentido, não pode ser usada para provar nada.

Isso vai junto com a recomendação de que não dê a mais de um usuário a mesma chave privada, nunca . Uma enorme quantidade de brechas de segurança se origina nas tentativas de tornar os processos de segurança menos onerosos. Existem maneiras seguras de fazer isso também. Mas você, como administrador, terá que fazer o trabalho, senão você estará automaticamente deixando sua rede e seus usuários abertos para atacar.

"Não tome atalhos"

    
por 03.11.2011 / 16:07
0

Fique com nomes de usuário e senhas, se você estiver pensando em perguntar a um cliente de qualquer maneira. Você precisará fornecer a mesma chave privada a todos os clientes se estiver incorporando-a no software do cliente e, assim, eles terão acesso a tudo o que a chave puder - o que significa qualquer conta no servidor.

Você realmente deseja criar contas separadas para cada usuário, e não há motivos reais para usar chaves quando os clientes esperam inserir nomes de usuários e senhas (elas ficarão confusas em como elas são seguras se não forem tem que dar uma senha toda vez).

Para manter as coisas simples para suportar, você vai querer que seja realmente fácil mudar os nomes de usuários e senhas das pessoas - possivelmente um servidor de diretório central executando o LDAP com interfaces GUI agradáveis para o helpdesk.

    
por 22.06.2010 / 14:41
0

Os usuários serão capazes de espionar uns aos outros, já que poderão acessar o espaço de memória de outros processos (assumindo que podem executar programas arbitrários).

    
por 24.06.2010 / 06:26