Servidor x remoto com ssh -X

Question

Estou tentando iniciar uma sessão remota do gnome usando: ssh -X [email protected] gnome-session

O cliente e o servidor são a versão 12.04 do Ubuntu

Eu 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

    

Answer 1

Eu assumo que o que você está tentando fazer é iniciar uma sessão remota completa do Gnome exibida em sua máquina local. Isso falha porque você já tem um gerenciador de sessão local controlando a exibição do seu servidor X.

Suas opções são:

1. Basta iniciar aplicativos remotos individuais usando ssh -X [email protected] xclock

2. Supondo que o XDMCP esteja ativado na máquina remota ...

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

   2b. Use Xephyr :1 -screen 1024x768 -query 192.168.1.107 , que é um servidor X melhor que Xnest

3. Também assumindo o XDMCP na máquina remota, configure sua máquina local para usar o seletor XDMCP em vez do padrão de saudação na inicialização.

Ativar o XDMCP é simplesmente um caso de colocar

[xdmcp]
Enable=true

em /etc/gdm/custom.conf e reiniciando gdm ou reinicializando (supondo que você esteja executando gdm ).

Se você pretende executar apenas alguns aplicativos remotamente, a opção 1 é a mais simples e continua a usar o tráfego criptografado SSH, o que nenhum deles faz (portanto, eles são usados apenas em uma rede local confiável).

Se você precisa de algo mais complicado, então 2b (Xephyr) pode ser melhor, mas eu geralmente acho que usar ssh -X ... & para vários aplicativos remotos é adequado.

Se você está fazendo tudo remotamente, ou seja, a máquina local é apenas um servidor de exibição e não faz nada, então você precisa procurar usar a opção 3, iniciando o seletor XDMCP em vez do login padrão.

PS: Como observado nos comentários, Xnest e Xephyr são aplicativos que manipulam o protocolo do servidor X e colocam a sessão inteira em uma janela. Xnest usa as funções fornecidas pelo servidor X local, enquanto Xephyr manipula muito mais do próprio protocolo do servidor, portanto, é mais robusto. Eles podem não ser instalados por padrão porque o usuário comum não os usaria.

PPS: Depois de pensar um pouco, é óbvio como criptografar uma sessão Xephyr ou Xnest ...

ssh -X [email protected] Xephyr :1 -query localhost -screen 1280x1024

    

Answer 2

Caso você queira aprender a usar o ssh padrão a partir de um terminal, pensei em dar-lhe um breve resumo, já que você teve problemas para usar as teclas ssh, ao que parece. 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 inserir a chave uma vez, você precisa fazer isso uma vez para qualquer servidor ssh remoto:

gerar chave (pode usar dsa em vez de rsa, se necessário)

ssh-keygen -t rsa    

transfira a chave para o host remoto

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

se não a porta padrão 22, use isto: Anote as cotações em torno do argumento

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

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

Em algum lugar depois disso, você precisará inserir uma senha, que é separada da sua senha de login normal. Já faz um tempo e esqueci a sequência exata, mas deveria ser óbvio. Então, na primeira vez que você se conectar, uma senha será solicitada. Eu uso o mesmo nome de login, então não preciso digitar o nome de usuário (ele assume o mesmo 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é mesmo montar um sistema de arquivos remoto usando o sshfs (supondo que o sshfs esteja instalado); substituir um caminho de diretório por local-mount-directory:

sshfs remote-host: local-mount-directory

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

Eu acho que vai usar o seu diretório home por padrão, se você deixar o diretório local-mount. '

Copiar arquivos pode ser feito com scp.