Gostaria de permitir que um usuário configurasse um túnel SSH para uma máquina específica em uma porta específica (digamos, 5000), mas quero restringir esse usuário o máximo possível. (A autenticação será com par de chaves pública / privada).
Sei que preciso editar o arquivo ~ / .ssh / authorized_keys relevante, mas não tenho certeza de qual conteúdo colocar nele (além da chave pública).
Respostas:
No Ubuntu 11.10, descobri que podia bloquear os comandos ssh, enviados com e sem -T, e bloquear a cópia do scp, enquanto permitia o encaminhamento de portas.
Especificamente, tenho um redis-server em "somehost" vinculado a localhost: 6379 que desejo compartilhar com segurança por meio de túneis ssh com outros hosts que têm um arquivo de chave e irão ssh com:
$ ssh -i keyfile.rsa -T -N -L 16379:localhost:6379 someuser@somehost
Isso fará com que o redis-server, "localhost" porta 6379 em "somehost" apareça localmente no host que está executando o comando ssh, remapeado para "localhost" porta 16379.
No remoto "somehost" Aqui está o que usei para authorized_keys:
cat .ssh/authorized_keys (portions redacted)
no-pty,no-X11-forwarding,permitopen="localhost:6379",command="/bin/echo do-not-send-commands" ssh-rsa rsa-public-key-code-goes-here keyuser@keyhost
O no-pty tropeça na maioria das tentativas de ssh que desejam abrir um terminal.
O permitopen explica quais portas podem ser encaminhadas, neste caso a porta 6379, a porta do redis-server que eu queria encaminhar.
O comando = "/ bin / echo do-not-send-command" ecoa de volta "do-not-send-command" se alguém ou algo conseguir enviar comandos para o host via ssh -T ou outro.
Em um Ubuntu recente man sshd, authorized_keys / command é descrito a seguir:
command = "command" Especifica que o comando é executado sempre que esta chave é usada para autenticação. O comando fornecido pelo usuário (se houver) é ignorado.
As tentativas de usar a cópia de arquivo seguro scp também falharão com um eco de "do-not-send-comandos". Descobri que o sftp também falha com esta configuração.
Acho que a sugestão de shell restrito, feita em algumas respostas anteriores, também é uma boa ideia. Além disso, eu concordaria que tudo o que está detalhado aqui pode ser determinado lendo "man sshd" e pesquisando nele por "authorized_keys"
~user/.ssh/authorized_keysseria propriedade de usere useradministraria as chaves autorizadas usadas para acessar a conta. O SSH é exigente quanto às permissões e pode impor expectativas sobre ~/.ssh/e seu conteúdo. Eu fiz um sudo chown root: .ssh/authorized_keyse parece ter me impedido de fazer o login, mas sei por experiência anterior que o usuário não precisa ser o proprietário desse arquivo - rootpode gerenciá-lo se preferir.
Você provavelmente desejará definir o shell do usuário para o shell restrito . Remova a variável PATH em ~ / .bashrc ou ~ / .bash_profile do usuário e eles não poderão executar nenhum comando. Mais tarde, se você decidir que deseja permitir que os usuários executem um conjunto limitado de comandos, como lessou tailpor exemplo, você pode copiar os comandos permitidos para um diretório separado (como /home/restricted-commands) e atualizar o PATH para apontar para esse diretório.
ssh use@host "/bin/bash", não é?
user@hosttenha rbash como shell. Ver The Restricted Shell
/bin/bashfalha porque contém barras.
less é provavelmente uma má ideia, porque a partir daí você pode escapar para um shell irrestrito com !/bin/bash. Consulte pen-testing.sans.org/blog/2012/06/06/… para outros exemplos. Portanto, permitir comandos individuais deve ser feito com muito, muito cuidado, se for o caso.
Além da opção authorized_keys como no-X11-forwarding, na verdade há exatamente uma que você está pedindo: permitopen = "host: port". Usando esta opção, o usuário só pode configurar um túnel para o host e porta especificados.
Para obter detalhes sobre o formato de arquivo AUTHORIZED_KEYS, consulte man sshd.
no-ptytambém não restringe o acesso ao shell, você ainda obterá o shell, apenas não mostrará o prompt; Você ainda pode dar comandos e ver o resultado perfeitamente. Você precisa da command="..."opção se quiser restringir o acesso ao shell de .ssh/authorized_keys.
Minha solução é fornecer ao usuário que só pode fazer tunelamento, sem um shell interativo , definir esse shell em / etc / passwd para / usr / bin / tunnel_shell .
Basta criar o arquivo executável / usr / bin / tunnel_shell com um loop infinito .
#!/bin/bash
trap '' 2 20 24
clear
echo -e "\r\n\033[32mSSH tunnel started, shell disabled by the system administrator\r\n"
while [ true ] ; do
sleep 1000
done
exit 0
Totalmente explicado aqui: http://blog.flowl.info/2011/ssh-tunnel-group-only-and-no-shell-please/
tunnel_shell, você terá shell -> /bin/bash tunnel_shellque escapar de volta para o shell, mas se você definir tunnel_shell como o shell do usuário, você apenas /bin/bash tunnel_shellexecutará, sem nenhum shell para onde escapar , tão longe quanto eu consigo ver. Eu testei e não consegui escapar com ctrl-z. Se você fez experimentá-lo e poderia escapar, você pode postar a configuração? Da mesma forma, se você souber de alguma documentação que diga que deve funcionar assim, você poderia postar?
Consigo configurar o arquivo authorized_keys com a chave pública para fazer login. O que não tenho certeza são as informações adicionais que preciso para restringir o que essa conta tem permissão para fazer. Por exemplo, sei que posso colocar comandos como:
no-pty,no-port-forwarding,no-X11-forwarding,no-agent-forwarding
Você deve querer uma linha em seu arquivo authorized_keys que se pareça com esta.
permitopen="host.domain.tld:443",no-pty,no-agent-forwarding,no-X11-forwardi
ng,command="/bin/noshell.sh" ssh-rsa AAAAB3NzaC.......wCUw== zoredache
Se você deseja permitir o acesso apenas para um comando específico - como svn - você também pode especificar esse comando no arquivo de chaves autorizadas:
command="svnserve -t",no-port-forwarding,no-pty,no-agent-forwarding,no-X11-forwarding [KEY TYPE] [KEY] [KEY COMMENT]
De http://svn.apache.org/repos/asf/subversion/trunk/notes/ssh-tricks
Aqui você tem uma boa postagem que achei útil: http://www.ab-weblog.com/en/creating-a-restricted-ssh-user-for-ssh-tunneling-only/
A ideia é: (com o novo nome de usuário restrito como "sshtunnel")
useradd sshtunnel -m -d /home/sshtunnel -s /bin/rbash
passwd sshtunnel
Observe que usamos rbash (restricted-bash) para restringir o que o usuário pode fazer: o usuário não pode fazer o cd (alterar o diretório) e não pode definir nenhuma variável de ambiente.
Em seguida, editamos a variável env PATH do usuário em /home/sshtunnel/.profilenada - um truque que fará com que o bash não encontre nenhum comando para executar:
PATH=""
Por fim, não permitimos que o usuário edite quaisquer arquivos definindo as seguintes permissões:
chmod 555 /home/sshtunnel/
cd /home/sshtunnel/
chmod 444 .bash_logout .bashrc .profile
Eu fiz um programa C que se parece com este:
#include <stdio.h>
#include <unistd.h>
#include <signal.h>
#include <stdlib.h>
void sig_handler(int signo)
{
if (signo == SIGHUP)
exit(0);
}
int main()
{
signal(SIGINT, &sig_handler);
signal(SIGTSTP, &sig_handler);
printf("OK\n");
while(1)
sleep(1);
exit(0);
}
Eu defini o shell do usuário restrito para este programa.
Não acho que o usuário restrito possa executar nada, mesmo que o faça ssh server command, porque os comandos são executados usando o shell, e este shell não executa nada.
Veja esta postagem sobre autenticação de chaves públicas .
As duas coisas principais que você precisa lembrar são:
chmod 700 ~/.sshVocê irá gerar uma chave na máquina do usuário por meio de qualquer cliente ssh que eles estejam usando. pUTTY, por exemplo, tem um utilitário para fazer exatamente isso. Ele irá gerar uma chave privada e uma pública.
O conteúdo do arquivo de chave pública gerado será colocado no arquivo authorized_keys.
Em seguida, você precisa ter certeza de que o cliente ssh está configurado para usar a chave privada que gerou a chave pública. É bastante simples, mas um pouco diferente dependendo do cliente que está sendo usado.
no-ptynão permita a abertura da seção interativa, não impede a execução do comando, de modo que o usuário pode editar oauthorized_keysarquivo se tiver acesso com algo semelhantessh server 'sed -i -e s/no-pty// ~/.ssh/authorized_keys'.