ssh comando remoto ls trava ao usar '*'

Question

Estou tendo um problema com o comando remoto no ssh.

Os seguintes comandos são executados bem:

ssh remote_server ls /path/to/folder/

(lista todos os arquivos da pasta - OK)

ssh remote_server ls /path/to/folder/file_000*

(curinga corresponde a um arquivo da pasta - OK)

O seguinte comando trava:

ssh remote_server ls /path/to/folder/file*

(o curinga combina alguns dos arquivos - HANGS)

ssh remote_server ls /path/to/folder/*

(o caractere curinga corresponde a todos os arquivos - HANGS)

A pasta remota não tem uma quantidade irracional de arquivos: cerca de 50, 40 deles corresponderiam à regex 'file *'.

A execução de ssh com o sinalizador -vvv fornece a seguinte saída

[...]
debug1: Authentication succeeded (publickey).
debug1: channel 0: new [client-session]
debug3: ssh_session2_open: channel_new: 0
debug2: channel 0: send open
debug1: Requesting [email protected]
debug1: Entering interactive session.
debug3: Wrote 136 bytes for a total of 2469
debug1: client_input_global_request: rtype [email protected] want_reply 0
debug2: callback start
debug2: client_session2_setup: id 0
debug1: Sending environment.
debug3: Ignored env HOSTNAME
debug3: Ignored env SHELL
debug3: Ignored env TERM
debug3: Ignored env HISTSIZE
debug3: Ignored env USER
debug3: Ignored env LD_LIBRARY_PATH
debug3: Ignored env LS_COLORS
debug3: Ignored env ORACLE_SID
debug3: Ignored env ORACLE_BASE
debug3: Ignored env MAIL
debug3: Ignored env PATH
debug3: Ignored env PWD
debug1: Sending env LANG = en_US.UTF-8
debug2: channel 0: request env confirm 0
debug3: Ignored env HISTCONTROL
debug3: Ignored env SHLVL
debug3: Ignored env HOME
debug3: Ignored env LOGNAME
debug3: Ignored env CLASSPATH
debug3: Ignored env LESSOPEN
debug3: Ignored env ORACLE_HOME
debug3: Ignored env G_BROKEN_FILENAMES
debug3: Ignored env OLDPWD
debug3: Ignored env _
debug1: Sending command: ls /u01/app/oracle/backup/rman/*
debug2: channel 0: request exec confirm 1
debug2: fd 3 setting TCP_NODELAY
debug2: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768
debug3: Wrote 152 bytes for a total of 2621
debug2: channel 0: rcvd adjust 2097152
debug2: channel_input_status_confirm: type 99 id 0
debug2: exec request accepted on channel 0

em que ponto, trava.

Alguma idéia?

A fonte é o Oracle Linux 6.9 O destino é o Oracle Linux 7.5

    

Answer 1

A expansão do caractere curinga bash funciona dessa maneira que /some/thing* em seu comando é sempre expandido em seu sistema local, mesmo se houver ssh no início da linha. Inesperado, mas ainda assim.

Para realizar a tarefa pretendida, use sempre aspas: ssh user@host 'ls /path/to/file*'

Em seu teste bem-sucedido: se o seu sistema não tiver /path/to/folder/file_000* , ele enviará a mesma string /path/to/folder/file_000* para remoto.

Em seu teste ruim: se o seu sistema tiver /path/to/folder/file_some_name e /path/to/folder/file_yet_another , ele enviará essas sequências para o remoto, em vez de /path/to/folder/file*

Antes de mais nada, o travamento pode estar no sistema local durante a listagem de arquivos locais - como travar no nível do sistema de arquivos.

Em segundo lugar, à medida que você envia uma string textualmente muito mais longa pela rede, você pode atingir o problema de MTU (unidade de transferência máxima). O problema do MTU passa despercebido se todos os pacotes forem menores que o MTU.

Caso de teste sugerido

Para testar apenas o problema de rede e apenas em uma direção:

ssh user@host  'echo Type here some text that is longer than 1500 bytes > /tmp/delete_me'