i'm having a problem with remote command in ssh.

The following commands run just fine:

ssh remote_server ls /path/to/folder/

(list all files of the folder - OK)

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

(wildcard match one file of the folder - OK)

The following command hangs:

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

(wildcard matchs some of the files - HANGS)

ssh remote_server ls /path/to/folder/*

(wildcard matchs all the files - HANGS)

The remote folder does not have a unreasonable amount of files: about 50, 40 of them would match 'file*' regex.

Running ssh with -vvv flag gives me the following output

debug1: Authentication succeeded (publickey).
debug1: channel 0: new [client-session]
debug3: ssh_session2_open: channel_new: 0
debug2: channel 0: send open
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug3: Wrote 136 bytes for a total of 2469
debug1: client_input_global_request: rtype hostkeys-00@openssh.com 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

in which point, hangs.

Any ideas?

Source is Oracle Linux 6.9 Destiny is Oracle Linux 7.5

  • What you get when you do: ssh -T remote_server ls /path/to/folder/ ssh -T: Disable pseudo-terminal allocation. This prevents the server aborting the transaction entirely if a text-terminal (tty) is requested. – Rafa Marques Nov 9 '18 at 16:15
  • Same behavior =S – chesterman Nov 9 '18 at 16:19

The bash wildcard expansion works this way that /some/thing* in your command is always expanded on your local system, even if there is ssh at the beginning of the line. Unexpected, but still.

To accomplish your intended task, always use quotes: ssh user@host 'ls /path/to/file*'

In your successful test: if your system does not have /path/to/folder/file_000* it sends the same string /path/to/folder/file_000* to remote.

In your bad test: If your system has /path/to/folder/file_some_name and /path/to/folder/file_yet_another then it sends these strings to remote instead of /path/to/folder/file*

First of all the hang may be on the local system during listing local files - such as hang at the filesystem level.

Secondly, as you send a textually much longer string through the network, you might hit the MTU problem (maximum transfer unit). The MTU problem goes unnoticed if all packets are smaller than the MTU.

Suggested test case

To test for only network problem and only in one direction:

ssh user@host  'echo Type here some text that is longer than 1500 bytes > /tmp/delete_me'
  • hi kubanczyk, tks for your time. I forgot to add this information after i post the question, but the problem also happens with quotes. But i agree with you about the MTU problem. There is a VPN between these 2 servers that is out of my administration. – chesterman Nov 9 '18 at 16:46
  • This problem does not happens between each of these servers and others server in the same network of each of them. – chesterman Nov 9 '18 at 16:47
  • hi @kubanczyk, the test case works ok. tried a small text and a bigger text (bigger than 1500 bytes) and worked ok – chesterman Nov 9 '18 at 17:22
  • 1
    i did another test. there is two files in remote host: /tmp/delete with 1300 bytes /tmp/delete2 with 1500 bytes ssh user@host "cat /tmp/delete" OK ssh user@host "cat /tmp/delete2" HANGS – chesterman Nov 9 '18 at 17:28
  • 1
    So an MTU problem ingress. Network/VPN is responsible. – kubanczyk Nov 9 '18 at 17:50

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.