The difference may have to do with having an interactive session. When you run ssh in an interactive shell, you'll be connected to a TTY, but automated scripts run by cron will not. Moreover, Bash will read from ~/.bash_profile on an interactive shell and ~/.bashrc for a non-interactive one, which can lead to subtle differences in the environment.
You might try debugging ssh by adding the -vvv option and capturing the output and see what's different between the manual and cron runs. Another thing to try would be the -t option for ssh.
Truly learning a command language interpreter, especially one with as large of a manual as Bash has, can take years. In the hopes of accelerating that learning for an up-and-coming scripter, I thought I'd share these suggestions unrelated to your query:
Your grep argument looks like a glob, but grep uses regex and yours will match files that have daycount anywhere in the name (though there must be one character before). You probably want grep '^\.daycount.+$'; see regex101.com for details on how these differ.
But you don't actually need grep: c=$(ls -1d /tmp/.daycount* | wc -l) will do. This uses globs to select the files. The -d option ensures directories matching this pattern are only one line; the -1 is implied, but I make it explicit here.
Using rm /tmp/.daycount[0-9] further limits how many files might be deleted to just those 10 possible files: /tmp/.daycount0 through /tmp/.daycount9.
You can omit both exit commands, as there is an implicit exit at the end of every script.
It's considered safer to use SSH keys rather than passwords when practical, and they come in handy when running automated scripts as no password is required. You can set one up by doing the following (only needs to be done once):
ssh-keygen -N '' # Create the key
ssh-copy-id [email protected] # Authorize (install) the key
Then you can do ssh [email protected] reboot without ever being asked for a password.
Is it possible to configure cron on 192.168.0.1? If so, you can completely avoid the SSH step that is causing problems by having the script run locally.
Note: You can escape characters like " and \ in a "" string (e.g. "\" \\"), but you cannot escape anything in a '' string, not even ' – any \ gets passed unmodified.