acesso somente ao tunelamento ssh

31

É possível configurar o ssh (no linux) para permitir o acesso apenas para encapsulamento? Ou seja, o usuário pode configurar túneis, mas não pode obter um shell / acessar arquivos?

linux ssh ssh-tunnel

— Segundo
fonte

42

Sim, basta usar /bin/falsecomo shell e instruir o usuário a iniciar o processo SSH de tunelamento sem executar nenhum comando remoto (ou seja, o -Nsinalizador para OpenSSH):

ssh -N -L 1234:target-host:5678 ssh-host

— conde
fonte

Hum, se o usuário não usar -N, ele terá acesso ao shell. Isso realmente não resolve o problema e é perigoso.

— mlissner

12

@mlissner: Não, se você tiver /bin/falsecomo shell, não terá acesso ao shell, pois todas as sessões de login serão encerradas imediatamente.

— Sven

10

No arquivo .ssh / allowed_keys do usuário, coloque algo como o seguinte:

permitopen="192.168.1.10:3306",permitopen="10.0.0.16:80",no-pty ssh-rsa AAAAB3N...

Então, basicamente, os controles estariam na frente da chave pública ssh do usuário, separados por um espaço. No exemplo, as conexões que usam a chave pública específica poderão fazer o encaminhamento de porta SSH apenas para o servidor MySQL do 192.168.1.10 e o servidor da Web 10.0.0.16, e não receberão um shell (no-pty). Você está perguntando especificamente sobre a opção "no-pty", mas as outras também podem ser úteis se o usuário precisar apenas fazer um túnel para servidores específicos.

Consulte a página de manual do sshd para obter mais opções para o arquivo allowed_keys .

Observe que a experiência do usuário pode parecer um pouco estranha: quando ele entra, parece que a sessão está interrompida (pois não está recebendo um arquivo). Isso está ok. Se o usuário especificou o encaminhamento de porta com, por exemplo, "-L3306: 192.168.1.10: 3306", o encaminhamento de porta ainda estará em vigor.

De qualquer forma, tente.

— cjc
fonte

6

Este é um conselho perigoso ; no-ptynão impede o acesso ao shell, apenas não fornece um pty ao shell. Ele não exibe o prompt (ou seja, "parece travar"), mas você ainda pode dar comandos perfeitamente. Você precisa da command="..."opção .ssh/authorized_keysse deseja restringir o acesso ao shell a partir daí.

— Aleksi Torhamo

@AleksiTorhamo está correto, mas isso é um começo; você também deve configurar o shell como / usr / sbin / nologin ou / bin / false em / etc / passwd para restringir completamente o shell. Editei a entrada acima para refletir isso, juntamente com os conselhos de Aleksi.

— Jamieson Becker

4

Dê ao usuário um shell que permita que ele efetue logout, como /bin/press_to_exit.sh

#! / bin / bash
read -n 1 -p "Pressione qualquer tecla para sair"

Dessa forma, ele pode permanecer conectado o tempo que quiser, com os túneis ativos, mas sem executar nenhum comando. Ctrl-cfecha a conexão.

— Sininho
fonte

3

Eu acho que, pelo menos em teoria, o usuário poderá pressionar CTRL + C no momento certo (entre as linhas 1 e 2) e acabar com um shell bash completo.

— mail

2

Atribua um shell que não permita que o usuário efetue login.

por exemplo

#!/bin/sh
echo "No interactive login available."
sleep 60
exit 0

impediria que eles recebessem um prompt de shell e desse um tempo limite de 60 segundos - se não houver conexão ativa por 60 segundos, ela será encerrada e, portanto, desconectada completamente (aumente o número de acordo com os requisitos).

Eles também não podem executar um comando remoto, porque esse shell não permite.

— jrg
fonte

4

A maioria das instalações Linux já vem com algo para isso. / sbin / nologin ou / bin / false ou similar.

— Rory

11

O que Ctrl-C faria no exemplo acima?

— Arjan

Arjan: Como o script é usado como shell, Ctrl-C teria o mesmo efeito que " logout" em um normal.

— grawity

2

Eu realmente gosto da resposta do conde, com a opção "-N", mas se você deseja enviar ao usuário uma mensagem útil, amigável e informativa - e impedi-lo de deixar conexões SSH por todo o lugar -, um script personalizado é agradável e claro sobre o que está fazendo

— JRG

2

@jrg Esta discussão é antiga e você pode ter mudado de ideia :) mas IMHO é perigoso lançar scripts shell feitos à mão. Já existe /sbin/nologin, que você pode personalizar com uma mensagem amigável /etc/nologin.txt.

— dr01 23/08/18

0

Minha solução é fornecer ao usuário que só pode estar encapsulando, sem um shell interativo , definir esse shell em / etc / passwd como / usr / bin / tunnel_shell .

Basta criar o arquivo executável / usr / bin / tunnel_shell com um loop infinito .

Além disso, use as opções AllowGroupse Match Group.

Totalmente explicado aqui: http://blog.flowl.info/2011/ssh-tunnel-group-only-and-no-shell-please/

— Daniel W.
fonte

2

O usuário pode sair do executável de alguma forma e escapar de um shell. Você está perfeitamente confiante de que seu executável não permitirá isso?

— dr01

2

@ dr01 Para ser sincero, não tenho certeza se isso é 100% seguro. Acho que quando você sai do executável, a sessão SSH também é encerrada. Vou pesquisar mais sobre isso e poder comentar novamente aqui.

— Daniel W.