Como sair do processo mestre de controle OpenSSH sem usar o lsof ou o fusor?

4

Existe uma maneira mais direta de sair de um processo mestre de controle do OpenSSH e excluir seu arquivo de soquete do que com a ajuda dos programas lsof ou fuser e sem conhecer o host destino (detalhes da conexão), como sugerido pela resposta aceita deste pergunta ? Eu pensei em algo assim ao longo das linhas de:

$ ssh -O exit -S ~/.ssh/7eb92b0827f3e8e1e8591fb3d1a5cd1b94b758cb.socket

Estou perguntando porque estou procurando uma maneira de sair de todas as conexões mestre de controle abertas sempre que faço logout da minha conta de usuário. Não fazê-lo faz com que meu computador sytemd -powered openSUSE aguarde um tempo limite de dois minutos até que termicamente termine a conexão mestre de controle ainda aberta desligando eventualmente.

Infelizmente, o programa cliente OpenSSH ssh requer o host destino e o padrão de nome de arquivo ControlPath para deduzir o caminho real do arquivo para o arquivo de soquete. Eu, pelo contrário, pensei no método mais direto de fornecer o arquivo de soquete concreto através da opção -S ctl_path do programa.

Na seção global do meu arquivo de configuração do cliente OpenSSH , configurei o recurso de multiplexação de conexão do OpenSSH da seguinte forma:

ControlMaster auto      
ControlPath ~/.ssh/%C.socket
ControlPersist 30m

Por favor, note que eu quero manter o padrão de nome de arquivo para arquivos de soquete, ou seja, fazer o hashing da string de token %l%h%p%r com o token %C .

Alguma idéia?

    
por Tim Friske 30.07.2018 / 22:42

1 resposta

4

Isso funciona para mim usando apenas o arquivo de soquete para o mestre de controle:

$ ssh -o ControlPath=~/.ssh/<controlfile> -O check <bogus arg>

Exemplo

Aqui está um exemplo em que já estabeleci uma conexão com um servidor remoto:

$ ssh -o ControlPath=~/.ssh/master-57db26a0499dfd881986e23a2e4dd5c5c63e26c2 -O check blah
Master running (pid=89228)
$

E com isso desconectado:

$ ssh -o ControlPath=~/.ssh/master-66496a62823573e4760469df70e57ce4c15afd74 -O check blah
Control socket connect(/Users/user1/.ssh/master-66496a62823573e4760469df70e57ce4c15afd74): No such file or directory
$

Se ainda estivesse conectado, isso forçaria a saída imediata:

$ ssh -o ControlPath=~/.ssh/master-66496a62823573e4760469df70e57ce4c15afd74 -O exit blah
Exit request sent.
$

Não está claro para mim, mas parece ser um bug em ssh que requer um argumento adicional no final, mesmo que blah não tenha sentido no contexto dos switches que estou usando. / p>

Sem isso me dá isso:

$ ssh -o ControlPath=~/.ssh/master-57db26a0499dfd881986e23a2e4dd5c5c63e26c2 -O check
usage: ssh [-1246AaCfGgKkMNnqsTtVvXxYy] [-b bind_address] [-c cipher_spec]
           [-D [bind_address:]port] [-E log_file] [-e escape_char]
           [-F configfile] [-I pkcs11] [-i identity_file]
           [-L [bind_address:]port:host:hostport] [-l login_name] [-m mac_spec]
           [-O ctl_cmd] [-o option] [-p port]
           [-Q cipher | cipher-auth | mac | kex | key]
           [-R [bind_address:]port:host:hostport] [-S ctl_path] [-W host:port]
           [-w local_tun[:remote_tun]] [user@]hostname [command]

Informações da versão

OSX
$ ssh -V
OpenSSH_6.9p1, LibreSSL 2.1.8
CentOS 7.x
$ ssh -V
OpenSSH_7.4p1, OpenSSL 1.0.2k-fips  26 Jan 2017

Confirmei que em ambas as versões, a necessidade do argumento falso adicional era necessária.

UPDATE # 1

Eu aumentei isso como um bug em potencial para o OpenSSH upstream e eles responderam o seguinte:

Yes - this is intentional.

ControlPath may contain %-expansions that need a hostname to expand fully.

We could conceivably check to see whether ControlPath actually needs this and make the hostname optional but 1) ControlPaths that use %h are common and 2) I'd rather not make the argument parsing code more of a maze than it already is.

Referências

por 31.07.2018 / 01:20

Tags