Both PuTTY (https://www.chiark.greenend.org.uk/~sgtatham/putty/wishlist/kerberos-gssapi.html ) and OpenSSH (https://www.openssh.com/txt/release-3.0 ) can be Kerberized (i.e. they know how to ask for the current login's Kerberos ticket and know how to present it to the SSH server for checking). There's a wonderfully detailed explanation over in one of the answers to the How does Kerberos work with SSH? (technically the case you're asking about is covered by Second login).
how exactly does SSH to the server work from any client like putty or another linux machine, irrespective of whether it supports Kerberos?
The SSH protocol can support multiple authentication schemes (e.g.
gssapi-with-mic, etc.). At login time the SSH client will try each authentication scheme in a preferred order and will generally fallback to another scheme until none are left (at which point the login fails). Kerberos (e.g.
gssapi-with-mic) is just one of the schemes that can be tried.
if I configure SSH authentication with pure kerberos without SSSD, does the login still work or here does the SSHD daemon itself works as the client for Kerberos authentication
It looks like there can be various different programs that the SSH client/server may talk to in order to do Kerberos but I'm unclear on just how they all interact (although I know you don't HAVE to use SSSD to do Kerberos on a system but doing so does provide some advantages). You can see some discussion over in RHEL 7's About Kerberos. Each program that wants to "do" Kerberos is generally built against the appropriate Kerberos libraries (so Kerberos is not something that entirely transparent to a program that wants to use it for authentication).
I am confused here regarding what is client and what is server. Eg: SSH logins, Web based logins etc.
What's the "client" and what's the "server" likely depends on the context of the conversation. Wikipedia has a nice description of the Kerberos Protocol and more importantly introduces terms like AS, KDC, TGC, TGS which reduce the ambiguity.