Misterious non functions with OpenSSH
Using SSH to execute commands on an other host I found: The script echo "-- server" ssh -l stream server ls -la /var/log/server/*.log echo "-- server-extern" ssh -l stream server-extern ls -la /var/log/server/*.log gives back -- server -rw-r----- 1 stream stream 30168 Jul 18 16:07 /var/log/server/access.log -rw-r----- 1 stream stream 756 Jul 17 14:13 /var/log/server/cache.log -rw-r----- 1 stream stream 2041 Jul 18 14:57 /var/log/server/error.log -rw-r----- 1 stream stream 14049 Jul 17 14:15 /var/log/server/start.log -- server-extern -rw-r----- 1 stream stream 21917 Jul 18 15:33 /var/log/server/access.log -rw-r----- 1 stream stream 0 Jul 15 12:16 /var/log/server/cache.log -rw-r----- 1 stream stream 963 Jul 17 20:44 /var/log/server/error.log -rw-r----- 1 stream stream 6304 Apr 19 02:52 /var/log/server/start.log if started manually in a shell (user stream, group stream). If started by cron this script will hang while running "ssh -l stream server ls ...". The command "ls" will execute, but ssh won't come back again. The connection is terminated after execution of the command. OpenSSH on host: openssh-2.9p1-23, SuSE 7.2 OpenSSH on server: openssh-2.9p1-23, SuSE 7.2 OpenSSH on server-extern: openssh-2.3.0p1-5, SuSE 7.0 Any idea, why this happens? Did someone else notice this behavior? -- Thomas
Using SSH to execute commands on an other host I found:
The script
echo "-- server" ssh -l stream server ls -la /var/log/server/*.log echo "-- server-extern" ssh -l stream server-extern ls -la /var/log/server/*.log
Whatever problem with ssh/openssh there might be following you behind, there is another mistake in the commandline in the first place: quoting. ssh -l stream server ls -la /var/log/server/*.log with files (LOCAL!) in /var/log/server that are named 1.log and 2.log expands to ssh -l stream server ls -la /var/log/server/1.log /var/log/server/2.log or, in other words, you have to quote the "*" for it to be expanded on the remote side instead of the local side. If you don't have any files in /var/log/server/ that match the pattern, then bash thinks it must be smart and feeds the literal "*" into the string. This is not consistent with other shells...
if started manually in a shell (user stream, group stream). If started by cron this script will hang while running "ssh -l stream server ls ...". The command "ls" will execute, but ssh won't come back again. The connection is terminated after execution of the command.
OpenSSH on host: openssh-2.9p1-23, SuSE 7.2 OpenSSH on server: openssh-2.9p1-23, SuSE 7.2 OpenSSH on server-extern: openssh-2.3.0p1-5, SuSE 7.0
Any idea, why this happens? Did someone else notice this behavior?
Use "-v" to see what happens. Otherwise, there's little chance to find out what goes wrong...
-- Thomas
Roman.
--
- -
| Roman Drahtmüller
Thomas Schweikle schrieb am Mittwoch, den 18. Juli 2001:
if started manually in a shell (user stream, group stream). If started by cron this script will hang while running "ssh -l stream server ls ...". The command "ls" will execute, but ssh won't come back again. The connection is terminated after execution of the command.
OpenSSH on host: openssh-2.9p1-23, SuSE 7.2 OpenSSH on server: openssh-2.9p1-23, SuSE 7.2 OpenSSH on server-extern: openssh-2.3.0p1-5, SuSE 7.0
Any idea, why this happens? Did someone else notice this behavior?
I'm not sure since when (which version) exactly, but I have openssh's ssh occasionally hanging when it's supposed to close the connection. This affects both "send-command" and interactive sessions. I never took the time to investigate this, but I never saw this happen with ssh.com's ssh 1.2.2x. It might be client-related, since it also gives problems when the connection to be terminated has been to a Solaris box where the admin installed OpenSSH 2.5.2p2 (own compile, I believe, I can ask if that matters). I haven't yet investigated the problem (packet trace alongside with ssh debug output or such). I also believe I read somethings about packets received but never delivered on the Linux-Kernel-mailinglist, it might be a patch Andrea Arcangeli submitted to Alan Cox, but I'm not sure, and I cannot currently find it, sorry.
participants (3)
-
Matthias Andree
-
Roman Drahtmueller
-
Thomas Schweikle