When Greenplum Database hosts are configured to use a non-standard SSH port (for example, port 5422 instead of the default 22), some Greenplum CLI utilities fail even though passwordless SSH works correctly and utilities like gpssh function as expected. This issue is observed when the SSH port is defined in ~/.ssh/config and enforced by security policy.
Symptoms:
Customers may observe following behaviour:
gppkg sync fails with errors similar to:
gpssh-exkeys fails during host key scanning with:
error 256 obtaining RSA host key write (<host>): Connection refusedGreenplum CLI utilities use different SSH invocation mechanisms.
gpssh-exkeys uses ssh-keyscan internally
ssh-keyscan does not read ~/.ssh/config
It always defaults to port 22 unless -p <port> is explicitly provided
Newer Go-based utilities
Some utilities (for example gppkg, gpservice, gpcheck)
Implement SSH connections internally
Hardcode port 22 and ignore user SSH configuration
Legacy Python utilities:
Use standard SSH invocation
Correctly use ~/.ssh/config
This inconsistency causes partial CLI failures in environments where non-standard SSH ports are mandatory.
Workaround:
For gpssh-exkeys
Manually specify the SSH port when scanning host keys:
ssh-keyscan -p <PORT> <hostname>
Example:
ssh-keyscan -p 5422 sdw1
Or dynamically extract the port from SSH configuration:
ssh-keyscan -p $(ssh -G sdw1 | awk '$1=="port"{print $2}') sdw1
For gppkg, gpservice, gpcheck
There is no reliable workaround.
These utilities will always attempt to connect on port 22.
Permanent Fix:
This is will be fixed in Greenplum version 7.8.0 which is planned to be released in April 2026.
Utilities that support non-standard SSH ports and work correctly:
gpstate
gpactivatestandby
gpstart
gpstop
gprecoverseg
gpexpand
gpaddmirrors
gpinitstandby
gpmovemirrors
gpdeletesystem
gpreload
analyzedb
gpmemreport
gpmemwatcher
gpssh
gpsync
gpcheckperf
gpinitsystem
gpsupport
Utilities that do NOT support non-standard SSH ports (Affected):
gpssh-exkeys
gppkg
gpservice
gpcheck
gpctl