Desde el servidor Y, el usuario A intenta conectarse mediante ssh al servidor X y obtiene la conexión rechazada. Desde el servidor Y, el usuario B intenta conectarse mediante ssh al servidor X y se le permite el paso. Desde el servidor Y, el root intenta realizar ssh y obtiene la conexión rechazada. La emisión es 100% repetible y 100% consistente.
Los dos primeros sugerirían un problema con la ACL, pero me dijeron que la configuración es la misma para ambos usuarios, aunque no tengo permiso para verla. También se han eliminado y vuelto a agregar sin éxito. Sin embargo, la raíz no se ve afectada por la ACL y tampoco puede conectarse.
Hay dos servidores con este problema y muchos otros servidores con configuraciones idénticas en ifconfig (excepto direcciones IP, etc.) y tablas de enrutamiento que no sufren este problema.
Un tcpdump en el servidor X que busca conexiones desde el servidor Y no muestra nada cuando el usuario A intenta conectarse, pero produce una gran cantidad de información cuando el usuario B intenta conectarse. Esto muestra que el servidor X no recibe nada cuando el usuario A intenta realizar ssh.
Todos los servidores ejecutan RedHat
Supongo que el problema está en el servidor Y, pero ¿qué debo buscar? ¿Podría aparecer un problema de conectividad basado en el nombre de usuario en los firewalls entre los servidores, o dichos firewalls no se basan en el nombre de usuario?
Editar: tanto los usuarios A como B pueden enviar ssh desde el servidor Y a muchos otros servidores del grupo. Es sólo el servidor X el que tiene el problema. Ssh-ing no utiliza RSA, aunque iniciar sesión en el servidor Y sí lo hace.
Respuesta1
.ssh/configVerifique el archivo del usuario A. Es posible que tenga una Hostentrada en ese archivo para el nombre de host en cuestión, lo que hace que sshintente con un puerto o dirección IP diferente para ese nombre de host. Por ejemplo, si .ssh/configtuviera estas líneas:
Host a.example.com
Hostname b.example.com
Port 42
Luego, al ejecutar "ssh a.example.com", intentaría conectarse al puerto 42 de b.example.com.
Otra posibilidad (poco probable) es que el usuario A esté ejecutando un programa "ssh" diferente por algún motivo, por ejemplo, porque su ruta de comando es diferente y el programa alternativo no se comporta como se esperaba.
Editar: Otra posibilidad poco probable es que tenga dos hosts en la red que respondan a la misma dirección IP. Las solicitudes de conexión fallidas van al servidor equivocado y son respondidas por él. Esto provocaría que las conexiones fallaran de forma aleatoria, en lugar de consistentemente por usuario, por lo que realmente no coincide con el comportamiento que usted describe.
Respuesta2
Esto ha sido resuelto.
Había DOS listas de acceso: la primera, que se conocía comúnmente (ACL), que enumera los servidores a los que un usuario puede conectarse, y la segunda, previamente desconocida, lista de servidores a los que solo se les permite el acceso a ciertos usuarios, es decir, lo contrario de una ACL. . Con los servidores eliminados de esta lista de restricciones, se permitió el acceso a todos los usuarios.
Gracias por todos sus comentarios y orientación.