Set up SSH

Your key is already on the stick – it is how you are logged in right now. Copy it to admin rather than pasting it again:

Run this on the live system:

arch-chroot /mnt install -d -m 0700 -o admin -g admin /home/admin/.ssh
install -m 0600 /root/.ssh/authorized_keys /mnt/home/admin/.ssh/authorized_keys
arch-chroot /mnt chown admin:admin /home/admin/.ssh/authorized_keys
arch-chroot /mnt ls -la /home/admin/.ssh/

(stdout)

drwx------ 1 admin admin  30 .
drwx------ 1 admin admin  72 ..
-rw------- 1 admin admin 347 authorized_keys

The ownership and the modes are not decoration. sshd refuses to use an authorized_keys file that other users could write to, and it does so silently from the client’s point of view – you simply get asked for a password that will not be accepted.

tip

user gets no key here, because admin is the account you administer from. If you also want to SSH in as user day to day, repeat the three commands with user in place of admin.

Refuse everything except keys

Run this inside the chroot:

cat > /etc/ssh/sshd_config.d/10-hardening.conf <<EOF
PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
EOF

Arch’s sshd_config ends with Include /etc/ssh/sshd_config.d/*.conf, so a drop-in overrides the defaults without touching the shipped file – which means package updates never conflict with your changes.

All three lines matter. PasswordAuthentication no alone is not enough: on a system with PAM, keyboard-interactive is a second route to the same password prompt, which is why it is switched off explicitly.

Check the config parses

[bash]: Run this on your workstation:

sshd -t

(stdout)

sshd: no hostkeys available -- exiting.

That message is the success case here. The installed system has no host keys yet – they are generated on first boot – and sshd checks the configuration before it looks for them. So a complaint about host keys means the config parsed; a complaint naming a line or an option means it did not, and you should fix that now.