Problem accessing GitHub, the SSH agent doesn't automatically start

[Ctrl-Alb]

Creating a bug report/issue

• I have searched the existing open and closed issues

Required Information

• DietPi version | G_DIETPI_VERSION_CORE=10 G_DIETPI_VERSION_SUB=1 G_DIETPI_VERSION_RC=2 G_GITBRANCH='master' G_GITOWNER='MichaIng'
• Distro version | bookworm 0
• Kernel version | Linux DietPi 6.12.62+rpt-rpi-v8 #1 SMP PREEMPT Debian 1:6.12.62-1+rpt1~bookworm (2026-01-19) aarch64 GNU/Linux
• SBC model | RPi 4 Model B (aarch64)
• Power supply used | Raspberry Pi 4 official power supply
• SD card used | Raspberry Pi micro SD

Additional Information (if applicable)

• Software title | ssh-agent
• Was the software title installed freshly or updated/migrated? Installed freshly
• Can this issue be replicated on a fresh installation of DietPi?
• Bug report ID | echo $G_HW_UUID

Steps to reproduce

1. Install OpenSSH and Fish using dietpi-software (to replicate my setup)
2. Create an SSH key using this command: ssh-keygen -t ed25519 -C "Dotfiles - DietPi" -f ~/.ssh/dotfiles-dietpi
3. Copy and paste the key into the GitHub SSH and GPG settings
4. Verify the connection using: ssh -T git@github.com

Expected behaviour

• The connection to GitHub should succeed without any error messages.

Actual behaviour

• The following error appears: git@github.com: Permission denied (publickey).

Extra details

• I was able to temporarily solve the issue by manually starting the SSH agent and adding the key with these commands (using the Fish shell):

eval (ssh-agent -c)
ssh-add ~/.ssh/dotfiles-dietpi

• However, this workaround does not persist after a reboot.
  I would like to know whether this behavior is expected or if it might be a bug. Additionally, what is the recommended way to ensure that the SSH agent starts automatically and loads my key after every reboot?

[MichaIng]

Please try this:

export GPG_TTY=$(tty)

I know this from our own server: entering a passphrase for an encrypted key when accessing via gpg is otherwise not possible from SSH console, as it does not seem to accept it for the input prompt of the gpg-agent automatically. However, it should not be an issue for local logins or terminal emulators with proper login session.

Of course this also needs to be done every login, e.g. I appended this to ~/.bashrc, you may want to use the respective fish login script, or maybe it calls ~/.profile as well (for login shells only).

If above does not help: there are a number of --user services and sockets included:

/usr/lib/systemd/user/gpg-agent-browser.socket
/usr/lib/systemd/user/gpg-agent-extra.socket
/usr/lib/systemd/user/gpg-agent-ssh.socket
/usr/lib/systemd/user/gpg-agent.service
/usr/lib/systemd/user/gpg-agent.socket

Those can only work when using systemd-logind and Dbus. Hence:

sudo systemctl unmask systemd-logind
sudo apt install dbus
sudo systemctl start dbus systemd-logind

The main service is enabled for graphical user sessions OOTB, and at least the graphical.target system target is always reached, even without any screen available. Not sure whether it is the same for these --user targets.

/usr/lib/systemd/user/graphical-session-pre.target.wants/:
total 0
lrwxrwxrwx 1 root root 20 Feb 19 11:46 ssh-agent.service -> ../ssh-agent.service

/usr/lib/systemd/user/sockets.target.wants/:
total 0
lrwxrwxrwx 1 root root 30 Mar  4 14:40 systemd-ask-password.socket -> ../systemd-ask-password.socket
lrwxrwxrwx 1 root root 28 Mar  4 14:40 systemd-journalctl.socket -> ../systemd-journalctl.socket

Otherwise, the sockets are not enabled, not sure whether ssh triggers any of them. Would need to enable it for the current user:

systemctl --user enable gpg-agent-ssh.socket

gpg-agent-ssh.socket just sounds like it is what you might particularly need, but I don't know which is used by what in which way, so you need to try it out (or read manpages).

[Ctrl-Alb]

Hi @MichaIng, thank you for the in-depth answer.

entering a passphrase for an encrypted key when accessing via gpg is otherwise not possible from SSH console

I probably wasn't able to explain myself correctly, but my SSH key doesn't have a passphrase. Do you think the solution to this problem would be different given that my SSH key has no passphrase?

Also, I tried export GPG_TTY=$(tty) but it seems to have no effect.

[MichaIng]

You are missing gpg-agent, and the passphrase input box and memory is managed by gpg-agent as well, hence the idea both might trigger similarly.

But if GPG_TTY is not your issue, then most likely missing DBus and --user session services/sockets is. Hence try to go on enabling DBus and systemd-logind, do a reboot, and see whether a login session triggers the gpg-agent.service, otherwise if starting it manually helps:

systemctl --user start gpg-agent

If this works, but it does not start OOTB, the graphical-session-pre.target does not seem to be reached in your session. Can be also checked:

systemctl --user status graphical-session-pre.target

[Ctrl-Alb]

As you suggested, I tried the following commands:

sudo systemctl unmask systemd-logind
sudo apt install dbus
sudo systemctl start dbus systemd-logind

After running them, I attempted systemctl --user enable gpg-agent-ssh.socket, systemctl --user start gpg-agent, and systemctl --user status graphical-session-pre.target, but all of them returned the same error:

Failed to connect to bus: No medium found

Thank you very much for your help so far. If you have any other suggestions, I'd be happy to try them. Otherwise, I'll do some more research on my own and follow up if I find anything useful

[MichaIng]

You at least need to logout and login again, maybe reboot, to register the session with logind.

[Ctrl-Alb]

You at least need to logout and login again, maybe reboot, to register the session with logind.

After running the commands:

sudo systemctl unmask systemd-logind
sudo apt install dbus
sudo systemctl start dbus systemd-logind

I rebooted, but the problem wasn't solved.
Then, running systemctl --user enable gpg-agent-ssh.socket, systemctl --user start gpg-agent, and systemctl --user status graphical-session-pre.target returned the error: Failed to connect to bus: No medium found.
I also tried changing the terminal emulator, but that didn't work either.
Were you able to replicate the issue, or is it something that only affects my machine?

[MichaIng]

Does this work?

export DBUS_SESSION_BUS_ADDRESS="unix:path=/run/user/$(id -u)/bus"
systemctl --user status gpg-agent

[Ctrl-Alb]

This time the error message is a little bit different: Failed to connect to bus: No such file or directory

[MichaIng]

So no DBus session was created. Ah wait, that is missing:

apt install libpam-systemd

And AFAIK Dropbear does not invoke this PAM module, so when logging in via SSH, this most likely works OOTB with the OpenSSH server only.

Or execute commands with their own session:

dbus-user-session systemctl --user status gpg-agent

But the complemented PAM login most likely solves the missing gpg-agent as well.

[Ctrl-Alb]

apt install libpam-systemd

Unfortunately it doesn't seem to have solved the problem.

And AFAIK Dropbear does not invoke this PAM module, so when logging in via SSH, this most likely works OOTB with the OpenSSH server only.

Just to clarify, as mentioned in the original post, I'm using OpenSSH.

dbus-user-session systemctl --user status gpg-agent

Output: fish: Unknown command: dbus-user-session
(It doesn't work with bash either)

[MichaIng]

Oh wrong command:

dbus-run-session systemctl --user status gpg-agent

[Ctrl-Alb]

dbus-run-session systemctl --user status gpg-agent

Output: Unit gpg-agent.service could not be found.

[Ctrl-Alb]

Update: I tested it in a fresh UTM VM and the problem is exactly the same as I originally described.
For this test I still used OpenSSH but did not install the Fish shell

[Ctrl-Alb]

Update 2: I got it working! Here are the steps I followed:

1. Created the ~/.ssh/config file, which didn't exist on my system yet
2. Added the following configuration to ~/.ssh/config:

Host github.com
    HostName github.com
    User git
    IdentityFile ~/.ssh/dotfiles-dietpi
    IdentitiesOnly yes

3. Set the correct permissions by running: chmod 600 ~/.ssh/config

Everything works now :)