como ssh -Y e depois su - outro usuário e ainda encaminhar aplicativos X para sua máquina local

11

É bastante fácil "buscar" (ou seja, desenhar localmente) um aplicativo Linux em execução remota: se eu ssh -Y para a máquina remota e executar um aplicativo, esse aplicativo certamente será exibido em minha área de trabalho local.

Se, no entanto, enquanto estiver ssh'ed na máquina remota, eu su para um usuário diferente, não posso encaminhar o aplicativo X para minha máquina local. Diz wrong authentication .

Não sei como lidar com este caso. O echo $DISPLAY ainda está correto (definido pelo ssh -Y logon inicial), mas o cookie de sessão provavelmente é definido apenas para o usuário inicial que efetuou logon no ssh.

Como posso superar essa dificuldade e encaminhar outros aplicativos X que são executados por diferentes usuários?

O motivo pelo qual não estou ssh'ing é porque não quero que o usuário seja acessível por meio do ssh (é o usuário "virtualbox", que obviamente é um alvo fácil para bots que tentam usar o ssh nesse servidor) ...

    
por nass 06.09.2013 / 12:39

4 respostas

11

Quando você se conecta a uma máquina de remoção via ssh com o encaminhamento X11 ativado, o ssh no servidor cria um arquivo .Xauthority no diretório pessoal do usuário. Como o ssh escuta o X11 em um soquete TCP, qualquer um pode se conectar. Como qualquer um pode se conectar, precisamos de alguma maneira de impedir que qualquer pessoa use seu monitor. Isso é feito com esse arquivo .Xauthority . O arquivo contém um "cookie" que é apresentado ao servidor X11 que verifica se o cliente deve ter permissão para se conectar.

Ignorando todos os detalhes, se você copiar o arquivo .Xauthority para o diretório pessoal do usuário alvo (e dar a ele a propriedade), será possível conectar-se.

    
por 06.09.2013 / 14:49
4
  1. ssh -Y para a máquina remota como você mesmo.
  2. Uma vez lá, digite xauth list . Aparece uma lista de itens do MAGIC-COOKIE. Sua sessão de login é provavelmente a parte inferior da lista. (Verifique isso observando o nome do host e o código numérico do UNIX e comparando-o com o nome do host do qual você fez o shell e seu host local atual: ## DISPLAY env variable.)
  3. Trocar usuários.
  4. Digite xauth add + toda a linha MAGIC-COOKIE acima.
  5. Os gráficos devem aparecer agora. Teste com um rápido xlogo .
por 23.01.2017 / 18:05
2

Esta não é uma resposta, então se você encontrar uma, obviamente é preferível.

Se não, e esta é a causa do seu enigma:

The reason I am not ssh'ing directly is because I don't want that user to be accessible through ssh (it is the "virtualbox" user, which is obviously an easy target for bots trying to ssh to that server)...

Não me parece um bom raciocínio. "O que os bots visam" O WRT, um sshd bem configurado, é largamente irrelevante. Eles vão zumbir em torno do porto 22 em todo o lugar em qualquer lugar? Aparentemente sim. Isso significa que eles realmente têm uma chance de sucesso?

Tente pesquisar uma história sobre alguém que tenha um bot anônimo aleatório com sucesso invadir o sshd. Tenho certeza que deve ter acontecido com alguém em algum lugar (e, é claro, você pode nunca saber), mas não consigo encontrar nenhum relatório sobre isso. Seria interessante ler qual era a configuração usada.

O SSH é muito seguro quando usado corretamente. Se não fosse, o comércio pela Internet não seria viável. Então, por que esses bots se incomodam? Por "usado corretamente", quero dizer, principalmente, com pares obrigatórios de chave pública / privada. Se você fizer isso e estiver confiante de que sua chave privada é segura (e deveria estar), esteja confiante em relação ao sshd.

Eu acho que a razão pela qual todas as "tentativas de arrombamento" acontecem é que há um grande grupo de usuários que não fazem coisas como fazer perguntas em U & L; não leia páginas de manual e use apenas a proteção por senha, que é como deixar seu cartão de caixa eletrônico em uma máquina em algum lugar com uma placa dizendo "Adivinha!".

No entanto, se você pensar em sua chave privada como seu cartão de caixa eletrônico - como algo que é fisicamente protegido por você (o que essencialmente é), então o alvo se torna muito mais etéreo. Tudo o que esses bots podem fazer é provar que sim, seriam necessários milhares de milhares de anos trabalhando juntos para forçar uma chave de 2048 bits.

Se você estiver cansado de ler relatórios de tentativas de invasão, altere sua porta. Eu vi pessoas aqui poo-poo isso como "segurança pela obscuridade", no entanto, um sshd que está adequadamente protegido na porta 22 não será menos seguro na porta 57, mas não será aleatoriamente incomodado. Claro, todos os seus inimigos drone poderiam apenas escanear todo o IP - mas você sabe o que? Eles não. Eu presumo que isso seja porque o que eles estão procurando é alguém executando um sistema que nem sequer olhou para /etc/ssh/sshd_config , muito menos se instruiu e sintonizou.

    
por 06.09.2013 / 14:01
2

Eu gosto da resposta de Randy, mas não funcionou bem para mim.

Aqui está o que eu tenho para trabalhar:

  1. ssh -Y as user1
  2. xauth list | grep 'uname -n'
  3. Mude para o usuário2
  4. unset XAUTHORITY
  5. xauth generate :0 .
  6. xauth add :0 . <KEY-FROM-STEP-2>

Observe os dois períodos nas etapas 5 e 6.

Se eu apenas seguir a resposta de Randy, a variável XAUTHORITY do usuário2 ainda estará apontando para o arquivo .Xauthority do usuário1. E sua sintaxe da tecla + não funcionou.

    
por 27.01.2017 / 23:54