Como eu crio um servidor SSH que executa um programa em vez de um shell completo?

1

Eu tenho um programa que quero compartilhar sobre ssh (ou até mesmo telnet, segurança do programa não é importante), mas eu não quero permitir que a conexão acesse qualquer outra coisa no meu sistema, exceto para a E / S desse programa (por exemplo, sem scp, sem acesso ao shell completo, sem túneis ssh). Isso é possível, e como eu faria isso em um sistema Ubuntu?

Pontos de bônus para poder executar isso como um usuário local ou como nobody .

    
por Adam M-W 17.10.2011 / 14:05

3 respostas

1

GNU Netcat seems to work to some degree (with -e) but can only support one user/session/instance, ideally I'd want to be able to connect more than once without having to restart the server.

socat pode bifurcar-se.

Sugiro navegar pelos exemplos

socat TCP4-LISTEN:5555,fork,tcpwrap=script \ EXEC:/bin/myscript,chroot=/home/sandbox,su-d=sandbox,pty,stderr

a simple server that accepts connections (TCP4-LISTEN) and fork's a new child process for each connection; every child acts as single relay. The client must match the rules for daemon process name "script" in /etc/hosts.allow and /etc/hosts.deny, otherwise it is refused access (see "man 5 hosts_access"). For EXEC'uting the program, the child process chroot's to /home/sandbox, su's to user sandbox, and then starts the program /home/sandbox/bin/myscript. Socat and myscript communicate via a pseudo tty (pty); myscript's stderr is redirected to stdout, so its error messages are transferred via socat to the connected client.

    
por 17.10.2011 / 15:43
4

Eu vejo duas abordagens simples:

  1. Crie usuários locais que executem seu programa como shell de login.

  2. Adicione um serviço xinetd que chame seu programa (o usuário pode então fazer telnet para este serviço)

por 17.10.2011 / 14:20
0

Crie os usuários que usarão o servidor da seguinte forma:

adduser -s /bin/software username

Onde / bin / software é a localização do software e username é, bem, o nome de usuário do usuário.

Esteja ciente de que as pessoas ainda podem obter acesso a um shell se encontrarem uma violação de segurança em seu software.

    
por 17.10.2011 / 15:51