O encaminhamento de porta SSH para um host que precisa entrar em contato com um terceiro host nomeado para acessar o MySQL

Question

Personalizamos e suportamos aplicativos da web padrão que nossos clientes hospedam em servidores gerenciados de diferentes hosters da web. Normalmente, o aplicativo consiste em um aplicativo da Web em PHP e em um banco de dados (principalmente MySQL).

Para nossos clientes, queremos oferecer um serviço de backup que se estenda além do que os hosters da Web oferecem (geralmente quatro semanas de tempo de retenção). Queremos fazer o backup do aplicativo da web (sem problemas) e do banco de dados (problema).

Um dos web hosters tem uma configuração que impede o usuário de acessar o banco de dados MySQL usando mysql.sock . Em vez disso, eles têm um nome separado (como user123.mydatabaseserver.com) para o próprio servidor gerenciado. Uma conexão com o banco de dados só é possível usando o parâmetro -h para mysql , desta forma:

mysql -u mydbuser -p -h user123.mydatabaseserver.com

Agora, geralmente fazemos backup dos bancos de dados do nosso servidor de backup usando um túnel SSH que se conecta ao servidor gerenciado e à porta encaminha a porta MySQL para o servidor de backup e conectamos ao banco de dados no servidor de backup através do túnel. execute mysqldump com a porta encaminhada. No entanto, devido ao parâmetro de nome de host forçado, isso não é possível neste caso.

Estamos cientes de que poderíamos nos conectar ao servidor gerenciado, despejar o banco de dados lá e copiar o arquivo de backup resultante usando scp ou alguma outra medida, mas eu queria ver se não estou perdendo algo que permitiria nos para não usar o tempo de armazenamento e / ou computação do servidor gerenciado ao vivo para esse backup.

Existe uma solução usando somente o encaminhamento de porta?

Editar 1: tentando tornar o problema mais claro

Servidor A (o sistema de backup) Servidor B (o servidor de aplicativos) Servidor C (o servidor de banco de dados)

O servidor A deve fazer backup do banco de dados no servidor C. No entanto, as permissões de acesso do MySQL permitem que somente o servidor B se conecte ao servidor C e acesse o banco de dados.

Neste caso específico, o servidor B e o servidor C têm o mesmo endereço IP, mas parece que o host desativou o acesso ao MySQL por meio de soquetes e apenas permite conexões TCP / IP.

Nesse meio tempo, tive a idéia de encadear a porta SSH para a frente:

Vincule a porta 22222 no servidor B à porta 3306 no servidor C e, em seguida, ligue 44014 no servidor A ao 22222 no servidor B. No entanto, tentar SSH no servidor C do servidor B resulta em uma mensagem de erro: host address xxx.xx.xxx.xx not allowed.

    

Answer 1

Você não precisa de um túnel SSH para ir de B para C, já que a webapp em B conecta-se a C usando sockets normais, certo?

No servidor A, você deve invocar o SSH assim:

ssh -L44014:serverc:3306 user@serverb

Isso estabelece um túnel SSH entre A e B. Quando o processo de backup, executado no servidor A, se conecta ao localhost: 44014, o encapsulamento fará com que o processo sshd no servidor B conecte-se à porta 3306 no servidor C. Ponto de vista de C, a conexão parecerá vir do servidor b em alguma porta de cliente aleatória.

Se você quiser usar isso dentro de um script, você também pode passar a opção -N para evitar gerar um shell, apenas faça o encaminhamento da porta. Assim, você pode executar o comando em segundo plano e eliminá-lo quando não precisar mais do túnel:

ssh -NL44014:serverc:3306 user@serverb &
TUNNEL_PID=$!
# do the backup on localhost:44014
kill $TUNNEL_PID

Se os administradores do servidor B tiverem desabilitado o encaminhamento de porta local, você poderá usar socat para emular esse comportamento, mas será um pouco mais complicado. Aqui nós geramos um socat localmente para fazer com que os dados passem pelo stdio do ssh, e um socat remoto para redirecioná-lo para o socket apropriado. Para que funcione, você deve ter o login sem senha do ssh funcionando:

socat TCP-LISTEN:44014 EXEC:"ssh user@serverb socat STDIO TCP:serverc:3306"