Servidor x remoto com ssh -X

Estou tentando iniciar uma sessão remota do gnome usando: ssh -X username@192.168.1.107 gnome-session

Cliente e servidor são Ubuntu versão 12.04

Recebo o seguinte (e não acontece muita coisa) ...

GNOME_KEYRING_CONTROL=/tmp/keyring-3aeNAh
GPG_AGENT_INFO=/tmp/keyring-3aeNAh/gpg:0:1
GNOME_KEYRING_PID=3573
GNOME_KEYRING_CONTROL=/tmp/keyring-3aeNAh
GPG_AGENT_INFO=/tmp/keyring-3aeNAh/gpg:0:1
GNOME_KEYRING_CONTROL=/tmp/keyring-3aeNAh
GPG_AGENT_INFO=/tmp/keyring-3aeNAh/gpg:0:1
SSH_AUTH_SOCK=/tmp/keyring-3aeNAh/ssh
GNOME_KEYRING_CONTROL=/tmp/keyring-3aeNAh
GPG_AGENT_INFO=/tmp/keyring-3aeNAh/gpg:0:1
SSH_AUTH_SOCK=/tmp/keyring-3aeNAh/ssh

(gnome-settings-daemon:3572): color-plugin-WARNING **: failed to get contents of /sys/class/dmi/id/board_version: Failed to open file '/sys/class/dmi/id/board_version': No such file or directory

** (gnome-settings-daemon:3572): WARNING **: You can only run one xsettings manager at a time; exiting

** (gnome-settings-daemon:3572): WARNING **: Unable to start xsettings manager: Could not initialize xsettings manager.
compiz (core) - Error: Screen 0 on display "localhost:10.0" already has a window manager; try using the --replace option to replace the current window manager.
Initializing nautilus-gdu extension
Created new window in existing browser session.
** Message: applet now removed from the notification area
** Message: using fallback from indicator to GtkStatusIcon

(gnome-settings-daemon:3572): keyboard-plugin-WARNING **: Failed to set the keyboard layouts: GDBus.Error:org.freedesktop.Accounts.Error.PermissionDenied: Not authorized

** (gnome-settings-daemon:3572): WARNING **: Failed to connect context: Connection refused

(gnome-settings-daemon:3572): clipboard-plugin-WARNING **: Clipboard manager is already running.

(gnome-settings-daemon:3572): color-plugin-WARNING **: failed to create device: GDBus.Error:org.freedesktop.ColorManager.Failed: failed to obtain org.freedesktop.color-manager.create-device auth

(gnome-settings-daemon:3572): color-plugin-WARNING **: GDBus.Error:org.freedesktop.ColorManager.Failed: failed to obtain org.freedesktop.color-manager.create-profile auth

(gnome-settings-daemon:3572): color-plugin-WARNING **: no xrandr-Samsung Electric Company-SAMSUNG device found: Failed to find output xrandr-Samsung Electric Company-SAMSUNG
Shutting down nautilus-gdu extension

** (gnome-settings-daemon:3572): WARNING **: Failed to connect context: Connection refused
Connection failure: Connection refused
pa_context_connect() failed: Connection refused

ssh xserver

— Benlad
fonte

Eu queria acessar uma máquina Ubuntu usada como servidor / player de mídia remotamente, sem alterar o que acontece na tela da máquina remota. Também só queria brincar com essas coisas para ver o que poderia fazer. :-)

— benlad

Se você quiser brincar, digitei uma resposta com algumas dicas para usar o ssh básico em uma linha de comando, incluindo gerar uma chave e copiá-la para o host remoto. Depois de aprender a usar o ssh, você ficará surpreso com o quanto pode ser feito usando-o.

— Marty Fried

Respostas:

Suponho que o que você está tentando fazer é iniciar uma sessão remota completa do Gnome exibida na sua máquina local. Isso falha porque você já possui um gerenciador de sessões local controlando a exibição do servidor X.

Suas opções são:

Basta iniciar aplicativos remotos individuais usando ssh -X user@192.168.1.107 xclock
Supondo que o XDMCP esteja ativado na máquina remota ...

2a Use Xnest -query 192.168.1.107 -geometry 1024x768 :1para iniciar uma sessão de logon remoto em uma janela local.

2b. Use Xephyr :1 -screen 1024x768 -query 192.168.1.107um servidor X melhor do queXnest
Também assumindo o XDMCP na máquina remota, configure sua máquina local para usar o seletor XDMCP em vez do greeter padrão na inicialização.

Ativar o XDMCP é simplesmente um caso de colocar

[xdmcp]
Enable=true

no /etc/gdm/custom.confe reiniciar gdmou reiniciar (supondo que você está executando gdm).

Se você deseja executar apenas alguns aplicativos remotamente, a opção 1 é a mais simples e continua a usar o tráfego criptografado SSH, o que nenhum dos outros faz (portanto, é melhor usá-los apenas em uma rede local confiável).

Se você precisar fazer algo mais complicado, o 2b (Xephyr) pode ser melhor, mas geralmente acho que apenas o uso ssh -X ... &de vários aplicativos remotos é adequado.

Se você estiver fazendo tudo remotamente, ou seja, a máquina local é apenas um servidor de exibição e não faz nada por si só, é necessário examinar a opção 3, iniciando o seletor XDMCP em vez do login padrão.

PS: Como observado nos comentários, tanto Xneste Xephyrsão aplicações que lidam com o protocolo do servidor X e colocar toda a sessão em uma janela. Xnestusa as funções fornecidas pelo servidor X local e Xephyrlida com muito mais protocolo do servidor, tornando-o mais robusto. Eles podem não estar instalados por padrão, porque o usuário médio não os usaria.

PPS: Após um pouco de reflexão, é óbvio como criptografar uma Xephyrou Xnestsessão ...

ssh -X username@192.168.1.107 Xephyr :1 -query localhost -screen 1280x1024

— StarNamer
fonte

Pode ser útil indicar o que o Xnest / Xephyr faz e por que, como eles não são instalados por padrão, não acho. Eu nunca encontrei nenhuma necessidade de usar o xdmcp, então não tenho idéia de mim mesmo. Uso simples a ssh -Ypartir de um terminal e, em seguida, corro o que preciso a partir daí.

— Marty Fried

@ MartyFried: Parece que ambos são servidores X que podem ser executados em uma janela. Parece que o usuário deseja encaminhar X uma sessão / exibição inteira. Pessoalmente, eu apenas usaria o VNC, que cria uma nova exibição no servidor X existente e poupa a dor de cabeça.

— Ish

@izx: Eu usei o VNC no passado para sistemas Windows, mas com dois sistemas Ubuntu, geralmente gosto do ssh interno, embora às vezes fico confuso ao executar aplicativos GUI, pois é difícil diferenciar aplicativos locais x remotos. Mas, pelo que faço (principalmente editando ou administrando um servidor), parece funcionar melhor.

— Marty Fried

@MartyFried A desvantagem do VNC é que você está simplesmente controlando a tela da máquina remota. Portanto, você não pode ter um usuário conectado nessa tela com outro usuário conectado remotamente. As soluções XDMCP criam sessões completamente separadas, permitindo que 2 ou mais usuários usem a mesma máquina.

— StarNamer

Sua solução 2b funcionou bem. Tentei a versão ssh, mas tive um problema com as chaves ssh. A mensagem é muito longa para ser postada aqui. Vou usar o método que funciona por enquanto.

— benlad

Caso você queira aprender a usar o ssh padrão de um terminal, pensei em dar-lhe um resumo rápido, já que você teve problemas ao usar as teclas ssh. A vantagem é que é mais universal e muito flexível.

Para usar chaves ssh, que são mais seguras, às vezes necessárias e mais convenientes, já que você só precisa digitar a chave uma vez, faça isso uma vez para qualquer servidor ssh remoto:

chave de geração (pode usar dsa em vez de rsa, se necessário)

ssh-keygen -t rsa

transferir a chave para o host remoto

ssh-copy-id <username>@<host>

se não for a porta 22 padrão, use o seguinte: Observe aspas ao redor do argumento

ssh-copy-id "<username>@<host> -p <port_nr>"

Se estiver usando dsa, há um comando ligeiramente diferente, adicionando -i <homedirectory>/.ssh/id_dsa

Em algum lugar depois disso, você precisará digitar uma senha, que é separada da sua senha de login normal. Já faz um tempo, e eu esqueci a sequência exata, mas deve ser óbvia. Em seguida, na primeira vez em que você se conectar, será solicitada essa senha uma vez. Eu uso o mesmo nome de login, portanto, não preciso digitar o nome de usuário (ele assume o mesmo que o nome de usuário remoto). Além disso, para servidores em sua LAN, você pode inserir ".local" em vez do endereço IP, acredito (funciona para mim).

Você pode até montar um sistema de arquivos remoto usando sshfs (assumindo que o sshfs esteja instalado); substitua um caminho de diretório por local-mount-directory:

sshfs remote-host: local-mount-directory

(desmontar usando fusermount -u local-mount-directory)

Eu acho que ele usará seu diretório pessoal por padrão, se você deixar de fora o diretório local de montagem. `

A cópia de arquivos pode ser feita com o scp.

— Marty Fried
fonte