The Linux terminal froze mid-command. No warning. No error. A silent failure. Minutes later you realize the connection to AWS RDS through IAM auth is dead. You try again. The same hang. This is not a network problem. It is a bug.
The AWS RDS IAM connect process relies on short-lived authentication tokens generated using the AWS CLI or SDK. On Linux, calling mysql or psql with an --enable-cleartext-plugin flag over IAM sometimes locks up when the terminal session receives input from certain stdin states. This bug appears most often in non-interactive shells, containerized environments, and CI pipelines. The token expires while the client is still waiting, leaving no output to suggest the cause.
The root issue: the IAM auth handshake runs an SSL negotiation, but Linux terminal buffering can deadlock when stdin is open yet unused. When using rds generate-db-auth-token and piping directly to the client process, the terminal never flushes, so no packets move. You see nothing. AWS RDS logs show no attempt. It's pure local stall.
Avoiding the bug means controlling the terminal and the client invocation together. Use --no-beep and explicit --ssl-mode for MySQL. For Postgres, set PGSSLMODE=require. Always pass the token through environment variables, never from a subshell output into the client without redirection. Redirect /dev/null to stdin if automation scripts must run without tty. On Linux EC2 instances, check stty -a before invoking your client to catch any odd read states.