Pergunta

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 tanto quanto possível.(A autenticação será com par de chaves pública/privada).

Eu sei que preciso editar o arquivo ~/.ssh/authorized_keys relevante, mas não tenho certeza exatamente de qual conteúdo colocar lá (além da chave pública).

Foi útil?

Solução

No Ubuntu 11.10, descobri que poderia bloquear comandos ssh, enviados com e sem -T, e bloquear a cópia do scp, permitindo ao mesmo tempo o encaminhamento de porta.

Especificamente, tenho um servidor redis em "somehost" vinculado a localhost:6379 que desejo compartilhar com segurança por meio de túneis ssh para outros hosts que possuem um arquivo-chave e farão ssh com:

$ ssh -i keyfile.rsa -T -N -L 16379:localhost:6379 someuser@somehost

Isso fará com que o servidor redis, porta "localhost" 6379 em "somehost" apareça localmente no host que executa o comando ssh, remapeado para a porta "localhost" 16379.

No "somehost" remoto Aqui está o que usei para chaves_autorizadas:

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 atrapalha a 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 servidor redis que eu queria encaminhar.

O command="/bin/echo do-not-send-commands" ecoa de volta "do-not-send-commands" se alguém ou algo conseguir enviar comandos ao host via ssh -T ou de outra forma.

De um Ubuntu recente man sshd, as chaves_autorizadas/comando são descritas a seguir:

Command = "Command" especifica que o comando é executado sempre que essa tecla é usada para autenticação.O comando fornecido pelo usuário (se houver) é ignorado.

As tentativas de usar a cópia segura de arquivos scp também falharão com um eco de "não enviar 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 detalhado aqui poderia ser determinado lendo "man sshd" e pesquisando por "authorized_keys"

Outras dicas

Você provavelmente desejará definir o shell do usuário como o shell restrito.Desmarque a variável PATH no ~/.bashrc ou ~/.bash_profile do usuário e ele não poderá executar nenhum comando.Mais tarde, se você decidir permitir que o(s) usuário(s) execute(m) um conjunto limitado de comandos, como less ou tail por exemplo, você pode copiar os comandos permitidos para um diretório separado (como /home/restricted-commands) e atualize o PATH para apontar para esse diretório.

Além da opçãoauthorized_keys, como no-X11-forwarding, na verdade há exatamente uma que você está solicitando:permitopen="host:porta".Ao usar 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.

Minha solução é fornecer ao usuário que só pode estar tunelando, sem um shell interativo, para definir esse shell /etc/senha 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/

Consigo configurar o arquivo Autorizado_Keys com a chave pública para fazer login.O que eu não tenho certeza são as informações adicionais necessárias para restringir o que essa conta tem permissão para fazer.Por exemplo, eu sei que posso colocar comandos como:

no-pty,no-port-forwarding,no-X11-forwarding,no-agent-forwarding

Você desejaria uma linha em seu arquivoauthorized_keys semelhante a 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ê quiser permitir 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 postagem legal 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 cd (alterar diretório) e não pode definir nenhuma variável de ambiente.

Em seguida, editamos a variável PATH env do usuário em /home/sshtunnel/.profile para nada - um truque que fará com que o bash não encontre nenhum comando para executar:

PATH=""

Finalmente, 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 em C que se parece com isso:

#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 configurei 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 esse shell não executa nada.

Ver esta postagem sobre autenticação de chaves públicas.

As duas coisas principais que você precisa lembrar são:

  1. Assegure-se de que você chmod 700 ~/.ssh
  2. Anexe o bloco de chave pública às chaves autorizadas

Você gerará uma chave na máquina do usuário por meio de qualquer cliente ssh que ele esteja usando.O pUTTY, por exemplo, tem um utilitário para fazer exatamente isso.Ele irá gerar uma chave privada e pública.

O conteúdo do arquivo de chave pública gerado será colocado no arquivoauthorized_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.

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top