Ao se conectar a uma caixa unix, como você sabe que tem a configuração SSH em sua área de trabalho?

Question

Quando você usa algo como massa para se conectar a uma caixa Linux, e você configura suas chaves SSH, etc.

Ao conectar, como ele informa ao servidor que você deseja se conectar usando suas chaves SSH?

O SSH está sendo executado como um serviço em uma porta específica ou simplesmente passa sua chave privada e, em seguida, o serviço de login vê isso e tenta se conectar usando-o?

Apenas procurando por um entendimento de alto nível (com talvez alguns detalhes, se você quiser ...)

    

Answer 1

O lado do servidor está configurado para os tipos de autenticação permitidos. E então o cliente reage de acordo. Da minha caixa de Linux, eu corri uma sessão ssh para um dos meus hosts com saída de depuração para mostrar o que faz:

OpenSSH_5.3p1, OpenSSL 1.0.0-fips-beta4 10 Nov 2009
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to blahblahblah [ip_address] port 22.
debug1: Connection established.
debug1: identity file /home/username/.ssh/identity type -1
debug1: identity file /home/username/.ssh/id_rsa type 1
debug1: identity file /home/username/.ssh/id_dsa type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_4.7
debug1: match: OpenSSH_4.7 pat OpenSSH_4*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.3
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'hostname' is known and matches the RSA host key.
debug1: Found key in /home/username/.ssh/known_hosts:13
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
debug1: Next authentication method: gssapi-with-mic
debug1: Unspecified GSS failure.  Minor code may provide more information
Credentials cache file '/tmp/krb5cc_500' not found

debug1: Unspecified GSS failure.  Minor code may provide more information
Credentials cache file '/tmp/krb5cc_500' not found

debug1: Unspecified GSS failure.  Minor code may provide more information


debug1: Next authentication method: publickey
debug1: Offering public key: /home/username/.ssh/id_rsa
debug1: Server accepts key: pkalg ssh-rsa blen 277
debug1: Authentication succeeded (publickey).
debug1: channel 0: new [client-session]
debug1: Entering interactive session.
debug1: Sending environment.
debug1: Sending env XMODIFIERS = @im=none
debug1: Sending env LANG = en_US.UTF-8

Para que você possa ver, ele negociou um protocolo e começou a oferecer tipos de autenticação. Quando atingiu a autenticação de chave pública, encontrou uma chave, enviou uma chave e, em seguida, a chave foi aceita pelo servidor, que então teve êxito na autenticação e não prosseguiu com mais nenhum mecanismo de autenticação. Se ele não tivesse conseguido manipular a chave, eu teria recebido a solicitação de senha, porque esse seria o único método a ser tentado.

    

Answer 2

O melhor dos protocolos de internet é que a maioria deles possui documentos de engenharia detalhados para os quais você pode ir. Nesse caso, RFC 4251 , que faz referência a vários outros RFCs relacionados a SSH. O que você está procurando é RFC 4252 , Protocolo de Autenticação do Secure Shell (SSH) . Da seção do Framework:

The server drives the authentication by telling the client which authentication methods can be used to continue the exchange at any given time. The client has the freedom to try the methods listed by the server in any order. This gives the server complete control over the authentication process if desired, but also gives enough flexibility for the client to use the methods it supports or that are most convenient for the user, when multiple methods are offered by the server.

Nesse ponto, seu cliente (PuTTY) verificará se ele tem alguma chave para usar (via Pageant). Se encontrar uma chave privada aplicável a esse host, ela será usada. Se encontrar uma chave privada criptografada, o Pageant solicitará uma senha e armazenará em cache as coisas para você. Em seguida, putty informa ao servidor "publickey" e o processo passa pela RFC 4252 Seção 7. O servidor SSH PODE retroceder à autenticação de senha se configurado para fazer isso (normalmente via PAM).

    

Answer 3

Com o putty, é necessário especificar a chave na configuração ou executar o agente putty (pageant.exe) e ter as chaves carregadas. O servidor realmente não sabe de nada que seu cliente não diz, e o que o cliente comunica depende muito da sua configuração.

Putty docs:

• Capítulo 4.20: O painel Auth
• Capítulo 9: Usando o Pageant para autenticação

Answer 4

Não envia sua chave privada, essa é a beleza dos keypings privados / públicos.

Em suma, há um par de chaves, uma privada que é totalmente secreta, nunca envia para ninguém; e a chave pública, que você pode enviar para os ventos, ou postar na web, qualquer que seja.

A propriedade interessante é que, mesmo que você conheça uma chave pública, é astronomicamente difícil descobrir a chave privada correspondente. Ao mesmo tempo, qualquer mensagem criptografada com uma chave só pode ser descriptografada com a outra.

o handshake usado por ssh é mais ou menos assim:

• o servidor sshd está escutando em uma porta TCP, geralmente a porta 22.
• o cliente ssh se conecta ao servidor sshd .
• existem várias opções de autenticação, o cliente as tenta em ordem até que o servidor concorde com uma. Entre eles, um envolve 'oferecer' a chave pública, enviando-a na conexão.
• o servidor compara a chave pública oferecida com uma das chaves públicas que conhece. se estiver registrado, o servidor aceita a chave e começa a verificá-la. Lembre-se que a chave pública é pública, qualquer um pode ter, oferecendo não é garantia de que você é quem você diz que é.
• o cliente pega a chave privada (que nobody deve ter) e a usa para criptografar um valor. é um valor diferente a cada vez, eu acho que é gerado e enviado pelo servidor.
• o cliente envia o valor criptografado para o servidor, que usa a chave pública para descriptografá-lo. se o valor corresponder ao original, é a prova de que o cliente tinha a chave privada que emparelha com a chave pública oferecida.

Answer 5

Eu não estou perto do PuTTY agora, mas sob Auth ou Login você pode escolher quais teclas usar para cada sessão salva. Não há serviço (s) em execução.

    

Answer 6

Basicamente, o handshake SSH compara os métodos que o cliente e o servidor suportam para autenticação, criptografia de dados, etc. até encontrar aqueles com os quais concordam ou desistir. A porta padrão é tcp / 22, mas algumas pessoas mudam para reduzir as tentativas de invasão.

Meu explicador favorito de como os keypairs trabalham é Simon Tatham: Autenticação de chave pública - uma introdução