The shell man pages don’t really help either. They use terms like “login shell” and “interactive shell” without really defining or differentiating them.
They're defined, it just doesn't go into the weird details. From the man page:
A login shell is one whose first character of argument zero is a -, or
one started with the --login option.
(not mentioned: the login(1) program does the dash thing when you log into a VT (as opposed to graphically, which has a whole nother complicated dance); login(1) is traditionally spawned by getty(8) which is in turn spawned by init(8). Some terminal emulators aggressively spawn login sessions; this is wrong but a common workaround for people who failed to configure their shell correctly, or who aren't using bash and thus don't have all the configurability)
An interactive shell is one started without non-option arguments (un‐
less -s is specified) and without the -c option, whose standard input
and error are both connected to terminals (as determined by isatty(3)),
or one started with the -i option. PS1 is set and $- includes i if
bash is interactive, allowing a shell script or a startup file to test
this state.
(or in other words: an interactive shell is one that outputs a prompt and waits for you to input something, as opposed to shells that are used to execute a file/pipe/string)
Further down, and often forgotten:
Bash attempts to determine when it is being run with its standard input
connected to a network connection, as when executed by the historical
remote shell daemon, usually rshd, or the secure shell daemon sshd.
(this goes on to explain how .bashrc is loaded even when it normally wouldn't be)
These are orthogonal, and can be combined in various ways (there are also a few other possibilities mentioned in this part of the man page, but they're much less relevant):
Login shells are normally interactive, whether started sanely by login(1) or by unreasonable terminals.
Non-interactive login shells are rare and weird and sometimes declared "unsupported" by config-file authors, but do work if you're careful (a common error is to do a pseudo-motd in /etc/profile, which will break for non-interactive logins if you don't explicitly check for them; these days, a lot of things should really be done by PAM instead for better reliability).
Interactive non-login shells are what you normally create unless your terminal is dumb, or what you always create if you start bash within bash.
Non-interactive non-login shells are what scripts use.
The SSH special logic is ignored for the common case where you're doing an interactive login shell. But if you are doing a non-interactive non-login shell, it gives you chance to fix your PATHs, since no other startup files have been read. I think those are the only two possibilities with a normal SSH configuration (and in unusual configurations you are probably being restrictive); other shells would be created as a child of the initial shell. (Remember that SSH feeds its arguments to the shell directly; it does not quote them sanely!)
