ssh and host resolve names following completely different paths, so it is not surprising that they yield different results sometimes, especially when the name to resolve is not a FQDN (hence the suggestion to use FQDNs everywhere.)
You don’t mention anything about your OS and your system configuration, so I have to keep it general, with an eye on Linux: MacOS details are somewhat different, and Windows even more, but the general concepts are the same.
host queries theDNS, so basically it looks in /etc/resolv.conf and queries the servers listed there, possibly attaching a domain name if the hostname is not already fully qualified. It ignores every other possible source, but beware that these days many systems run a local caching DNS server (usually dnsmasq) which reads /etc/hosts and other sources before querying other DNS servers, so if host queries that local server, results from /etc/hosts can creep in.
ssh follows its own path. I describe what openssh does under linux, other implementations differ. First it looks for host nicknames defined in config files (system-wide /etc/ssh/ssh_config and per-user ~/.ssh/config), then it searches other sources in the order specified by the hosts: directive in /etc/nsswitch.conf. Say it is something like:
hosts: files dns
this means: look in /etc/hosts and then query the DNS (/etc/resolv.conf again). Other possible sources are the obsolete nis and netinfo services, LDAP, active directory, you name them.
To debug your particular case, you should follow the path your implementation of ssh follows and find out where it gets stuck.
storageis a live top-level domain on the Internet. – Michael Hampton♦ 5 hours ago