okay I tried that, using -i to specify private key. I get the same thing: blank / blinking cursor. When I use verbose -v flag, I see that in both (using -i, the config file, and originally) cases (I see about 50 lines) it ends with these two lines:

debug1: Offering public key: /home/username/.ssh/id_rsa RSA SHA256:j3MUkYzhTrjC6PHkIbre3O(etc) agent
debug1: Server accepts key: /home/username/.ssh/id_rsa RSA SHA256:j3MUkYzhTrjC6PHkIbre3OT(etc) agent

where (etc) is some redacted text. It seems the server is ACCEPTING the key, which is nice. But then it's still a blinking cursor...

The whole point of ssh-agent is to remember your passphrase.

replace passphrase with private key and you're very correct.

passphrases used to login to servers using PasswordAuthentication are not stored in the agent. i might be wrong with technical details on how the private key is actually stored in RAM by the agent, but in the context of ssh passphrases that could be directly used for login to servers, saying the agent stores passphrases is at least a bit misleading.

what you want is:

• use Key authentication, not passwords
• disable passwordauthentication on the server when you have setup and secured (some sort of backup) ssh access with keys instead of passwords.
• if you always want to provide a short password for login, then don't use an agent, i.e. unset that environment variable and check ssh_config
• give your private key a password that fits your needs (average time it shoulf take attackers to guess that password vs your time you need overall to exchange the pubkey on all your servers)
• change the privatekey every time immediately after someone might have had access to the password protected privkey file
• do not give others access to your account on your pc to not have to change your private key too often.

also an idea:

• use a token that stores the private key AND is PIN protected as in it would lock itself upon a few tries with a wrong pin. this way the "password" needed to enter for logins can be minimal while at the same time protecting the private key from beeing copied. but even then one should not let others have access to the same machine (of course not as root) or account (as user, but better not at all) as an unlocked token could also possibly be used to place a second attacker provided key on the server you wanted to protect.

all depends on the level of security you want to achieve. additional TOTP could improve security too (but beware that some authenticator providers might have "sharing" features which could compromise the TOTP token even before its first use.

FWIW, I've found that the -v flag often doesn't say why it's not using your key, just that it isn't using your key and it has fallen back to password authentication.

It's usually not terribly helpful for figuring out why it's not using your key, just that it's not using your key, which you kind of already know if it's prompting you for a password. lol

Not OP but everytime I used the verbose output of ssh it didn't help me one bit. Even adding outrageous verbosity I was still quite confused on what step failed and which didn't.

I'm probably just bad at understanding SSH but i don't know it seems like ssh workflow includes many trial and error until it finds a way to connect.

Imo the verbose output of SSH is often not very helpful if you don't know very well ssh in the first place. Obviously it is still worth a shot and a good advice but don't expect ssh to clearly state what is going on :)

I'm pretty sure I generated it to ~/.ssh/id_rsa which I think the default location. It is also the location shown in the terminal image in my post.

which ssh 

which ssh-agent

My theory is that you already have something providing ssh agent service

in the past some xserver environments started an ssh-agent for you just in case of, and for some reason i don't remember that was annoying and i disabled it to start my agent in my shell environment as i wanted it.

also a possibility is tharlt there are other agents like the gpg-agent that afaik also handles ssh keys.

but i would also look into $HOME/.ssh/config if there was something configured that matches the hostname, ip, or with wildcards* parts of it, that could interfere with key selection as the .ssh/id_rsa key should IMHO always be tried if key auth is possible and no (matching) key is known to the ssh process, that is unless there already is something configured...

not sure if a system-wide /etc/ssh/ssh_config would interfere there too, maybe have a look there too. as this behaviour seems a bit unexpected if not configured specially to do so.

I didn't really follow the former part, but I can give you this:

strace -o logfile -f ssh -p 8322 pi@192.168.2.223 of when I get blank

ssh-add -L
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQCqS5l(redacted)f0phb8x+fUV1w== username@computername

echo $SSH_AUTH_SOCK
/run/user/1000/gcr/ssh

lsof $SSH_AUTH_SOCK
COMMAND      PID    USER FD   TYPE             DEVICE SIZE/OFF    NODE NAME
gcr-ssh-a 778406 username  3u  unix 0x000000007e25ee6b      0t0   30290 /run/user/1000/gcr/ssh type=STREAM (LISTEN)
gcr-ssh-a 778406 username  6u  unix 0x0000000020f5b559      0t0 2096642 /run/user/1000/gcr/ssh type=STREAM (CONNECTED)
gcr-ssh-a 778406 username 12u  unix 0x00000000a6756d60      0t0 2100347 /run/user/1000/gcr/ssh type=STREAM (CONNECTED)
gcr-ssh-a 778406 username 15u  unix 0x00000000625cb05a      0t0 2261237 /run/user/1000/gcr/ssh type=STREAM (CONNECTED)
gcr-ssh-a 778406 username 21u  unix 0x00000000d0b214f9      0t0 2261238 /run/user/1000/gcr/ssh type=STREAM (CONNECTED)
gcr-ssh-a 778406 username 23u  unix 0x00000000a2f197fe      0t0 2349665 /run/user/1000/gcr/ssh type=STREAM (CONNECTED)
gcr-ssh-a 778406 username 27u  unix 0x00000000da22a130      0t0 2349668 /run/user/1000/gcr/ssh type=STREAM (CONNECTED)
gcr-ssh-a 778406 username 29u  unix 0x000000004f7a1723      0t0 2365382 /run/user/1000/gcr/ssh type=STREAM (CONNECTED)
gcr-ssh-a 778406 username 33u  unix 0x00000000e26976b3      0t0 2365389 /run/user/1000/gcr/ssh type=STREAM (CONNECTED)
gcr-ssh-a 778406 username 35u  unix 0x00000000b8185a8a      0t0 2375648 /run/user/1000/gcr/ssh type=STREAM (CONNECTED)
gcr-ssh-a 778406 username 39u  unix 0x00000000ba41030c      0t0 2375649 /run/user/1000/gcr/ssh type=STREAM (CONNECTED)
gcr-ssh-a 778406 username 41u  unix 0x000000006867cb01      0t0 2380999 /run/user/1000/gcr/ssh type=STREAM (CONNECTED)
gcr-ssh-a 778406 username 45u  unix 0x0000000091384b95      0t0 2381008 /run/user/1000/gcr/ssh type=STREAM (CONNECTED)
gcr-ssh-a 778406 username 47u  unix 0x00000000d5b28b08      0t0 3729149 /run/user/1000/gcr/ssh type=STREAM (CONNECTED)
gcr-ssh-a 778406 username 51u  unix 0x00000000f65088aa      0t0 3731006 /run/user/1000/gcr/ssh type=STREAM (CONNECTED)

All before issuing the ssh-agent

well seems to work without tho

edit: made no difference, but I changed it in the post title.

it got 600 both the private and public key, stored in ~/.ssh/

I just added the ~/.ssh/config file on client side:

Host pidoos
     HostName 192.168.2.223
     User pi
     IdentityFile ~/.ssh/id_rsa

Same result.

The /etc/ssh/ssh_config is only relevant on the server side, right? Well, here it is.

tried.

can you expand on that? What do you mean different names? My PC has of course a different username than the server I'm connecting to. The label name at the end of the key is just a comment, so this is also not what you're referring to, I think.

I have zsh