I can remember this confusion of my own the first time I started digging into the internals of a UNIX system. This is a much simplified explanation; understanding modern systems requires a lot of background knowledge that is too wide to fit into a StackExchange answer like this one.
The login credentials are requested by a privileged process called
login and you can see the executable with
ls -l /bin/login. (Source is also available, of course.) More information from
Among other things this process will use a number of library calls (via the PAM library, see
man 7 pam) to check your credentials, ensure that there are no time restrictions, that your home directory exists, etc. When all the criteria have been satisfied it will discard its privileges and start a copy of your preferred shell. Often (but not exclusively) this is defined as the last field in
You can see your own password entry (that strangely, perhaps, does not include even an encrypted copy of your password) with the
getent passwd "$USER"
More information about the structure of this file can be found with
man 5 passwd.
Note that there is no hard and fast requirement for your shell to be
/bin/bash. It could be something entirely custom, as it runs only with your own account privileges.
Hopefully this will have explained that the shell itself knows nothing about your credentials. It is just a normal program (a complex one, perhaps) that when running in interactive mode reads from stdin and writes to stdout. The same program can be used in non-interactive mode to read and write to files, pipes, or sockets.
In principle there is little to stop to you writing your own shell that reads a line from its input, splits the words by whitespace, and then forks a child process to call
execvpe() and execute a program. (In practice there are a great many extra hurdles to overcome, such as not splitting quoted strings, actioning
cd) directly in the parent, and signals.)