Am construit un serviciu de tunel SSH care rulează într-un container bazat pe Alpine, pe baza abordării prezentate aici: https://github.com/cagataygurturk/docker-ssh-tunnel
Serviciul se conectează prin IdentityFiles și configurează mai multe ControlSockets și tuneluri.
Testez acest lucru pe un bastion Amazon Linux, ajungând la o bază de date PostgreSQL.
Conectarea SSH și crearea tunelurilor sunt corecte, iar tunelurile pot fi folosite, dar se pare că există un timeout undeva.
- Dacă un tunel - poate conexiunea la serverul SSH țintă în ansamblu? - a fost lăsat inactiv timp de 5 minute și apoi conectat la, procesul de conectare se blochează timp de 30 de secunde înainte de a continua cu succes.
- Conexiunile la tunel imediat după prima conexiune sunt rapide - sub secundă.
- Lăsați tunelul/serverul să fie inactiv timp de 5 minute, iar întârzierea de 30 de secunde revine.
Iată dovezile:
client ssh-config
Găzduiește-mi bastionul
Nume gazdă 99.99.99.99
Utilizator ec2-user
IdentityFile ~/.ssh/key.pem
Gazda *
ControlMaster automat
ControlPath ~/.ssh/controlmasters/cp_%r_%h
ControlPersist da
StrictHostKeyChecking nr
ServerAliveCountMax 60
ServerAliveInterval 30
TCPKeepAlive nr
ForkAfterAuthentication da
StdinNull da
ExitOnForwardFailure da
IPQoS 0x00
Testarea fluxului de lucru
Tunelul stabilit anterior folosind ControlSocket.
Testarea cu o solicitare psql care nu reușește autentificarea, dar exercită tunelul.
psql face 2 conexiuni prin tunel în timpul testului.
Primul acces după cel puțin 5 minute inactiv.
# dată și oră psql „host=localhost port=5430 dbname=xxx user=UUU password=X”
Marți, 8 martie, 12:10:57 PST 2022
psql: eroare: FATAL: autentificarea parolei a eșuat pentru utilizatorul „UUU”
FATAL: autentificarea parolei a eșuat pentru utilizatorul „UUU”
0m32.497s real - lent!
Jurnalul clientului SSH -vv
Prima cerere psql
[2022-03-08 20:10:57] debug1: a fost solicitată conexiunea la portul 5430, redirecționarea către portul 5432 xxx.us-east-1.rds.amazonaws.com.
[2022-03-08 20:10:57] debug1: canal 3: nou [direct-tcpip]
30 sec Întârziere aici
[2022-03-08 20:10:57] debug2: canal 3: deschideți confirmarea ferestrei 2097152 rmax 32768
[2022-03-08 20:11:29] depanare 2: canal 3: citire<=0 rfd 7 len 0
A doua cerere psql
[2022-03-08 20:11:29] debug1: a fost solicitată conexiunea la portul 5430, redirecționarea către portul 5432 xxx.us-east-1.rds.amazonaws.com.
[2022-03-08 20:11:29] debug1: canal 4: nou [direct-tcpip]
răspuns subsecunde pe canalul 4
[2022-03-08 20:11:29] debug2: canal 4: deschideți confirmarea ferestrei 2097152 rmax 32768
[2022-03-08 20:11:29] depanare 2: canal 4: citire<=0 rfd 8 len 0
Acces imediat după 1.
# dată și oră psql „host=localhost port=5430 dbname=xxx user=UUU password=X”
Marți, 8 martie, 12:11:41 PST 2022
psql: eroare: FATAL: autentificarea parolei a eșuat pentru utilizatorul „UUU”
FATAL: autentificarea parolei a eșuat pentru utilizatorul „UUU”
0m0.874s real - rapid!
utilizator 0m0.021s
sys 0m0.016s
Prima cerere psql
[2022-03-08 20:11:41] debug1: a fost solicitată conexiunea la portul 5430, redirecționarea către portul 5432 xxx.us-east-1.rds.amazonaws.com.
[2022-03-08 20:11:41] debug2: setarea fd 7 TCP_NODELAY
[2022-03-08 20:11:41] debug2: setarea fd 7 O_NONBLOCK
[2022-03-08 20:11:41] depanare1: canal 3: nou [direct-tcpip]
Răspuns subsecunde la cerere
[2022-03-08 20:11:41] debug2: canal 3: deschideți confirmarea ferestrei 2097152 rmax 32768
[2022-03-08 20:11:42] depanare 2: canal 3: citire<=0 rfd 7 len 0
...
A doua cerere psql
[2022-03-08 20:11:42] debug1: a fost solicitată conexiunea la portul 5430, redirecționarea către portul 5432 xxx.us-east-1.rds.amazonaws.com.
[2022-03-08 20:11:42] debug1: canal 4: nou [direct-tcpip]
[2022-03-08 20:11:42] debug2: canal 4: deschideți confirmarea ferestrei 2097152 rmax 32768
Am căutat pe alții cu această problemă, dar nu am găsit că se vorbește despre această problemă. Am incercat sfaturi de la https://jrs-s.net/2017/07/01/slow-ssh-logins/ și setați IpQos=0x00 pentru a rezolva eventualele probleme de router.
