devsetup1-2  Exercise 3: A Coloured Prompt and Safe SSH Key Login
==================================================================

PART 1: THE PROMPT
------------------
On devserver, append this to ~/.bashrc:

    PS1='\[\e[1;36m\]\u@\h\[\e[0m\]:\[\e[1;34m\]\w\[\e[0m\]\$ '

Then run: source ~/.bashrc

The user@host part should now be bold cyan and the directory blue. On the web
server use a different, more cautious colour (for example red, 1;31) so the
two terminals cannot be mistaken for each other.

PART 2: THE KEY
---------------
On the computer you connect FROM:

    ssh-keygen -t ed25519
    ssh-copy-id yourname@DEVSERVER-ADDRESS
    ssh yourname@DEVSERVER-ADDRESS

The last command should log you in without asking for your account password
(it may ask for the key's passphrase if you set one, which is a good idea).

PART 3: DISABLING PASSWORD LOGINS SAFELY
----------------------------------------
Order of steps:

1. Keep your existing SSH session to devserver open. Do not close it until
   the very end.
2. Open a SECOND session using the key, to prove key login really works.
3. In the first session, create /etc/ssh/sshd_config.d/10-no-passwords.conf
   containing:
       PasswordAuthentication no
4. Check the configuration for mistakes:
       sudo sshd -t
   No output means it is valid. If it prints an error, fix the file first.
5. Apply it without dropping existing connections:
       sudo systemctl reload ssh
6. From a THIRD terminal, try to log in with a password on purpose, for
   example: ssh -o PubkeyAuthentication=no yourname@DEVSERVER-ADDRESS
   It should now be refused. Then confirm key login still works.
7. Only now close the extra sessions.

HOW TO UNDO IT IF SOMETHING GOES WRONG
--------------------------------------
Because the first session is still open, you can undo the change from there:
    sudo rm /etc/ssh/sshd_config.d/10-no-passwords.conf
    sudo sshd -t
    sudo systemctl reload ssh
Password login then works again. If you closed every session and are locked
out, you need to log in at the machine's own keyboard and remove the file the
same way. That is easy on a desk and very inconvenient on a remote server,
which is why the second, open session matters.

WHY THIS WORKS AS AN ANSWER
---------------------------
The dangerous moment is the change that removes your normal way in. Every
step is arranged so you can always recover: test first, validate the
configuration before applying it, keep a working session open, and check the
result from a separate terminal before letting go.