Várias conexões SSH para o mesmo sistema - é possível?


14

Eu tenho um computador linux atuando como um servidor que pode aceitar conexões SSH de entrada.

É possível conectar com segurança vários dispositivos ao mesmo tempo, como meu telefone e laptop, além de outros desktops, ao mesmo servidor usando SSH?

Obrigado pela ajuda.


63
Por que você simplesmente não tentou antes de perguntar?
Dmitry Grigoryev 28/01

1
Não apenas isso, mas você pode ter vários links entre o mesmo par de sistemas. Você também pode achar screenou moshútil se desejar o comportamento "Área de trabalho remota do Windows" para a linha de comando: uma única interface transmitida por vários links.
Pjc50

7
Há duas razões pelas quais eu simplesmente não tentei antes de perguntar; a primeira é a falta de fé que tenho em meu próprio entendimento do linux - se tivesse funcionado, ainda não confiaria em sua confiabilidade, se eu confiar nela. O segundo é que a comunidade Superusuário é, de um modo geral, impressionante e rápida para ajudar quem pede - obrigado comunidade.
precisa saber é o seguinte

Respostas:


50

A resposta curta - sim. Geralmente funciona por padrão.

A resposta longa - Dependendo do que você está usando, pode ficar lento com várias conexões, mas isso é um problema de largura de banda, não um problema ssh.


15

Sim, é possível, é o comportamento padrão.

Confiar em

Você pode contar se você estiver usando uma versão atualizada do sshe o protocolo não é mais um.

grep "Protocol"  /etc/ssh/sshd_config

O comando acima deve fornecer a você Protocol 2.

Limites para as conexões

Você pode ver sshcomo a evolução criptografada de telnet, nascida no final dos anos 69, para permitir o acesso remoto a um servidor. Observe que se sshconecta pelo TCP e é capaz de encaminhar sessões X (sessão gráfica) também. Multitarefa e multiusuário são da natureza interna do Unix ... mesmo que não seja sem limites !!!

Você pode ver alguns desses limites nos limites TCP e SSH:

  • cat /proc/sys/net/core/somaxconn, geralmente 128, para ver a conexão pendente máxima em TCP que você pode ter;

    A variável kern.ipc.somaxconn sysctl (8) limita o tamanho da fila de escuta para aceitar novas conexões TCP. O valor padrão de 128 geralmente é muito baixo para o manuseio robusto de novas conexões em um servidor da Web muito carregado.

  • cat /proc/sys/net/core/netdev_max_backlog, geralmente 1000, o comprimento máximo da fila de pacotes TCP
  • less /etc/security/limits.conf você pode encontrar os limites para o usuário.
  • MaxSessions in/etc/ssh/sshd_config

    MaxSessions Especifica o número máximo de sessões abertas permitidas por conexão de rede. O padrão é 10 .

  • #MaxStartups 10:30:60geralmente comentado no /etc/ssh/sshd_confige por padrão definido como 10

    Especifica o número máximo de conexões simultâneas não autenticadas ao daemon SSH ... O padrão é 10.


Referências

  • man ssh, man sshdna sua máquina.
  • A página de manual do sshd ou do sshd_config .

2
somaxconné o número máximo de conexões pendentes , ou seja, o número máximo de registros em espera, não o 'número máximo de conexões TCP que você pode ter'. O número máximo de conexões TCP que você pode ter é de ordens de magnitude maiores que 128. Caso contrário, servidores práticos não seriam possíveis.
precisa saber é o seguinte

@ejp obrigado pelo lugar, eu estava com pressa e sinto falta de "novo" antes da conexão. BTW "excelente" é mais preciso. Adicionei mais algumas palavras na esperança de que fique mais claro.
Hastur 29/01

MaxSessionslimita apenas o número de sessões multiplexadas em uma única conexão TCP ( mais detalhes ), para que você não se limite a se conectar ao mesmo host novamente. (Um limite padrão de 10 para o total de sessões ssh seria absurdo. Imagine um host compartilhado com centenas ou milhares de contas de usuário e apenas 10 sessões ssh permitidas.)
Josef diz Reinstate Monica em

@Josef Está escrito MaxSessions Especifica o número máximo de sessões abertas permitidas por conexão de rede , nada diferente (conforme relatado na página de manual): talvez não seja claro o suficiente. Obrigado pela referência adicional e para sublinhar este ponto. (Nota: BTW, o uso comum de um computador Linux com ssh não é um host compartilhado com 10 ^ 5 + conta de usuário e, nesse caso, a configuração padrão não pode ser apropriada por definição :-))
Hastur

6

Sim, é totalmente. Mas isso deve ser definido pela implementação. Você também pode programar seu próprio servidor ssh (provavelmente não tão seguro e pior) que não pode lidar com várias conexões. Mas, assim como os servidores HTTP comuns, claro, suportam isso, o openssh também.

Na verdade, esse é o próprio conceito do Unix: um sistema multiusuário em que um servidor faz todo o trabalho e apenas pequenos clientes se conectam (terminais).


4

Sim, isso é muito comum. De fato, se usado como servidor de arquivos e por muitos usuários, é absolutamente essencial. O SFTP usa SSH e há muita atividade EDI que também depende disso.

Nos dispositivos, é possível disparar eventos com logons personalizados do usuário (como desligamento ou reinicialização).

Considere também o SCP (o WinSCP é comumente usado para acessar o código-fonte), e os usuários do KDE ainda podem usar o fish: no Konqueror.

Também é notável o uso de portas adicionais em caso de perda durante a manutenção (Ubuntu do-release-upgrade, digamos).

Então, sim, acho que você nunca teve vários terminais PuTTY abertos?


Estranhamente, eu não tinha! Mas obrigado pelas informações extras, o que você quis dizer com portas adicionais para manutenção?
Sam3000

1
Durante a atualização do-relesase a partir de um terminal remoto, existe o risco de perda de comunicação (reinício do SSH ou da rede, por exemplo). Se estes não puderem ser restabelecidos na porta 22, o Ubuntu fornecerá uma porta alternativa 1022 usando uma segunda instância SSH. A atualização ocorre dentro da "tela", que pode ser acessada com a tela -x / tela -r após reconectar e um sudo su. (veja "screen" e "tmux"). Muita informação sobre isso.
Mckenzm
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.