O SSH está solicitando e lendo os segredos de login por meio de um descritor de arquivo separado; certifica-se de abrir o TTY atual.
A maioria dos programas cuida para ler os segredos de login de um TTY, para que eles possam impedir que a senha seja mostrada, desabilitando temporariamente o "eco" no TTY. Eu esperaria que eles se certificassem de escrever o prompt para o mesmo TTY, pelo bem da robustez.
$ SSH_AUTH_SOCK= strace -f rsync x brick:
...
[pid 26255] openat(AT_FDCWD, "/dev/tty", O_RDWR) = 4
[pid 26255] ioctl(4, TCGETS, {B38400 opost isig icanon echo ...}) = 0
[pid 26255] ioctl(4, SNDCTL_TMR_CONTINUE or TCSETSF, {B38400 opost isig icanon -echo ...}) = 0
...
[pid 26255] write(4, "Enter passphrase for key '/home/"..., 51Enter passphrase for key '/home/alan/.ssh/id_rsa': ) = 51
[pid 26255] read(4, "", 1) = 0
[pid 26255] write(4, "\n", 1
) = 1
[pid 26255] ioctl(4, SNDCTL_TMR_CONTINUE or TCSETSF, {B38400 opost isig icanon echo ...}) = 0
...
O SSH imprimiu a mensagem de erro para o erro padrão (número de arquivo aberto 2) e não para a saída padrão (número de arquivo aberto 1) que o rsync usaria para seu protocolo.
[pid 26255] write(2, "[email protected]: "..., [email protected]: Permission denied (publickey).
) = 64
[pid 26255] exit_group(255) = ?