Iniciamos o sshd usando xinetd em nosso gateway. Aqui está o arquivo de configuração do xinetd:
service ssh
{
instances = 10
socket_type = stream
wait = no
user = root
protocol = tcp
server = /usr/local/sbin/sshd
server_args = -i
disable = no
}
Aqui está a versão do OpenSSH do comando ssh -V no gateway:
OpenSSH_9.8p1, OpenSSL 3.0.14 4 Jun 2024
Aqui está a versão em execução na minha VM Fedora 37:
OpenSSH_8.8p1, OpenSSL 3.0.9 30 May 2023
Se eu tentar fazer ssh no gateway a partir da minha VM Fedora 37, recebo o erro "sshd requer execução com um caminho absoluto":
$ ssh -vvv foo@g5-5
OpenSSH_8.8p1, OpenSSL 3.0.9 30 May 2023
debug1: Reading configuration data /etc/ssh/ssh_config
debug3: /etc/ssh/ssh_config line 58: Including file /etc/ssh/ssh_config.d/50-redhat.conf depth 0
debug1: Reading configuration data /etc/ssh/ssh_config.d/50-redhat.conf
debug2: checking match for 'final all' host g5-5 originally g5-5
debug3: /etc/ssh/ssh_config.d/50-redhat.conf line 3: not matched 'final'
debug2: match not found
debug3: /etc/ssh/ssh_config.d/50-redhat.conf line 5: Including file /etc/crypto-policies/back-ends/openssh.config depth 1 (parse only)
debug1: Reading configuration data /etc/crypto-policies/back-ends/openssh.config
debug3: gss kex names ok: [gss-curve25519-sha256-,gss-nistp256-sha256-,gss-group14-sha256-,gss-group16-sha512-]
debug3: kex names ok: [curve25519-sha256,[email protected],ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512]
debug1: configuration requests final Match pass
debug1: re-parsing configuration
debug1: Reading configuration data /etc/ssh/ssh_config
debug3: /etc/ssh/ssh_config line 58: Including file /etc/ssh/ssh_config.d/50-redhat.conf depth 0
debug1: Reading configuration data /etc/ssh/ssh_config.d/50-redhat.conf
debug2: checking match for 'final all' host g5-5 originally g5-5
debug3: /etc/ssh/ssh_config.d/50-redhat.conf line 3: matched 'final'
debug2: match found
debug3: /etc/ssh/ssh_config.d/50-redhat.conf line 5: Including file /etc/crypto-policies/back-ends/openssh.config depth 1
debug1: Reading configuration data /etc/crypto-policies/back-ends/openssh.config
debug3: gss kex names ok: [gss-curve25519-sha256-,gss-nistp256-sha256-,gss-group14-sha256-,gss-group16-sha512-]
debug3: kex names ok: [curve25519-sha256,[email protected],ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512]
debug3: expanded UserKnownHostsFile '~/.ssh/known_hosts' -> '/home/xxxx/.ssh/known_hosts'
debug3: expanded UserKnownHostsFile '~/.ssh/known_hosts2' -> '/home/xxxx/.ssh/known_hosts2'
debug2: resolving "g5-5" port 22
debug3: resolve_host: lookup g5-5:22
debug3: ssh_connect_direct: entering
debug1: Connecting to g5-5 [x.x.x.x] port 22.
debug3: set_sock_tos: set socket 3 IP_TOS 0x48
debug1: Connection established.
debug1: identity file /home/xxxx/.ssh/id_rsa type -1
debug1: identity file /home/xxxx/.ssh/id_rsa-cert type -1
debug1: identity file /home/xxxx/.ssh/id_dsa type -1
debug1: identity file /home/xxxx/.ssh/id_dsa-cert type -1
debug1: identity file /home/xxxx/.ssh/id_ecdsa type -1
debug1: identity file /home/xxxx/.ssh/id_ecdsa-cert type -1
debug1: identity file /home/xxxx/.ssh/id_ecdsa_sk type -1
debug1: identity file /home/xxxx/.ssh/id_ecdsa_sk-cert type -1
debug1: identity file /home/xxxx/.ssh/id_ed25519 type -1
debug1: identity file /home/xxxx/.ssh/id_ed25519-cert type -1
debug1: identity file /home/xxxx/.ssh/id_ed25519_sk type -1
debug1: identity file /home/xxxx/.ssh/id_ed25519_sk-cert type -1
debug1: identity file /home/xxxx/.ssh/id_xmss type -1
debug1: identity file /home/xxxx/.ssh/id_xmss-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_8.8
debug1: kex_exchange_identification: banner line 0: sshd requires execution with an absolute path
kex_exchange_identification: read: Connection reset by peer
Connection reset by x.x.x.x port 22
Não recebo esse erro se o OpenSSH 9.7p1 estiver em execução no gateway e eu conseguir fazer login com sucesso.
Dei uma olhada no código em sshd.c no github: https://github.com/openssh/openssh-portable
É possível que o erro que estou recebendo seja devido à não verificação do inetd_flag na linha 1344? O código sshd.c em 9.7.p1 parece verificar o inetd_flag indiretamente.
Ou é alguma configuração nova ou adicional com relação à inicialização do 9.8p1 sshd a partir do xinetd?
Eu encontrei o mesmo problema no Slackware ( https://www.linuxquestions.org/questions/slackware-14/openssh-9-8-regression-when-using-inetd-4175739141/ ).
Parece uma regressão no openssh 9.8 ( https://bugzilla.mindrot.org/show_bug.cgi?id=3717 ) e foi corrigido no 9.9 ( https://www.openssh.com/txt/release-9.9 ).