a computer (let's name it A) […] another computer (let's name it B). […] I had to add the public key of A in the
authorized_keys
file of B.
Uma situação comum é adicionar a chave pública do usuário particular de A no arquivo auhorized_keys
do usuário de B. Não é a chave que representa o todo computador A; da mesma forma, o arquivo authorized_keys
não pertence ao todo B.
Você provavelmente adicionou a chave pública de algum usuário alpha
de A no arquivo authorized_keys
de algum usuário beta
de B (os dois usuários podem usar o mesmo login, ainda assim eles estão em máquinas diferentes, então vamos mantenha nomes distintos alpha
e beta
).
Minha solução: defina o shell de login de beta
em B para /bin/false
. Você pode fazer isso (em B) com sudo usermod -s /bin/false beta
.
Isso causaria as seguintes restrições:
-
beta
normalmente não pode logar em B; em particularssh beta@B
de A não dará shell a ninguém, apesar do sucesso da autenticação SSH; - comandos como
ssh beta@B whatever
não serão bem-sucedidos; - nem o SCP nem o SFTP tentando acessar a conta de
beta
não funcionarão (consulte este comentário ).
Parece que não há como alpha
em A ver ou modificar os arquivos em B. No entanto, ao mesmo tempo:
-
qualquer pessoa capaz de autorizar como
beta
pode usarssh -N
para estabelecer conexão SSH a B sem executar nenhum comando lá; este é um exemplo de comandoalpha
deve invocar em A:ssh -N -R 1234:127.0.0.1:22 beta@B
-
você não precisa ser
beta
para usar o encapsulamento (embora-R
sem especificar um endereço de encadernação seja vinculado apenas à interface de loopback de B, então você precisa estar em B para usar o túnel, veja tambémman 5 sshd_config
,GatewayPorts
option).
Além disso, verifique as opções MaxSessions
e PermitOpen
em man 5 sshd_config
. Eu acho que se você usá-los corretamente, um possível invasor usando a chave privada de alpha
não será capaz de "capturar" muitas portas em B.