Nome
sshd - Demostrar OpenSSH SSH
Sinopse
sshd [- deiqtD46 ] [- b bits ] [- f config_file ] [- g login_grace_time ] [- h ficheiro host_key_ ] [- k key_gen_time ] [- o opción ] [- port p ] [- u len ]
Descrición
sshd (SSH Daemon) é o programa daemon para ssh (1). Xuntos estes programas reemplazan a rlogin e rsh , e proporcionan comunicacións cifradas seguras entre dous servidores non confiables a través dunha rede insegura. Os programas están destinados a ser tan fáciles de instalar e utilizar como sexa posible.
sshd é o demo que escoita as conexións dos clientes. Normalmente é iniciado no arranque desde / etc / rc Esquema un novo daemon para cada conexión entrante. Os demos buracos manexan intercambio de chaves, cifrado, autenticación, execución de comandos e intercambio de datos. Esta implementación de sshd soporta simultaneamente a versión 1 e 2 do protocolo SSH.
Versión 1 do protocolo SSH
Cada servidor ten unha chave RSA específica para o servidor (normalmente 1024 bits) utilizada para identificar o servidor. Ademais, cando o demo comeza, xera unha chave RSA do servidor (normalmente 768 bits). Esta chave normalmente rexérese cada hora se foi usada e nunca se almacena no disco.
Cada vez que un cliente se conecta, o daemon responde coas súas chaves públicas e anfitrión. O cliente compara a chave do servidor RSA contra a súa propia base de datos para verificar que non cambiou. O cliente xera un número aleatorio de 256 bits. Cifra este número aleatorio empregando tanto a clave host como a clave do servidor e envía o número cifrado ao servidor. Ambas partes entón usan este número aleatorio como unha chave de sesión que se usa para cifrar todas as comunicacións posteriores na sesión. O resto da sesión está cifrada usando un cifrado convencional, actualmente Blowfish ou 3DES, sendo utilizada 3DES por defecto. O cliente selecciona o algoritmo de cifrado a usar dos ofrecidos polo servidor.
A continuación, o servidor eo cliente ingresan nun diálogo de autenticación. O cliente intenta autenticarse mediante a autenticación .rhosts, a autenticación .rhosts combinada coa autenticación de host RSA, a autenticación RSA challenge-response ou a autenticación por contrasinal .
A autenticación de Rhosts normalmente está desactivada porque é fundamentalmente insegura, pero pode ser habilitada no ficheiro de configuración do servidor se o desexa. A seguridade do sistema non se mellora a non ser que rshd rlogind e rexecd estean desactivadas (polo tanto, desactivar completamente rlogin e rsh na máquina).
Versión 2 do protocolo SSH
A versión 2 funciona de forma similar: cada servidor ten unha clave específica de host (RSA ou DSA) utilizada para identificar o servidor. Non obstante, cando se inicia o demo, non xera unha chave de servidor. A seguridade fronteira proporciónase mediante un acordo clave Diffie-Hellman. Este acordo clave dá como resultado unha clave de sesión compartida.
O resto da sesión está cifrada usando un cifrado simétrico, actualmente AES de 128 bits, Blowfish, 3DES, CAST128, Arcfour, AES de 192 bits ou AES de 256 bits. O cliente selecciona o algoritmo de cifrado a usar dos ofrecidos polo servidor. Adicionalmente, a integridade da sesión proporciónase mediante un código de autenticación de mensaxes criptográficas (hmac-sha1 ou hmac-md5).
A versión de protocolo 2 fornece un método de autenticación de usuario baseado en clave pública (PubkeyAuthentication) ou servidor de host (HostbasedAuthentication), autenticación de contrasinal convencional e métodos baseados en resposta ao desafío.
Execución de comandos e reenvío de datos
Se o cliente autenticouse correctamente, ingrese un diálogo para preparar a sesión. Neste momento, o cliente pode solicitar cousas como asignar unha pseudo-tty, reenviar conexións X11, reenviar conexións TCP / IP ou reenviar a conexión do axente de autenticación a través da canle segura.
Finalmente, o cliente solicita un shell ou a execución dun comando. Os lados entran no modo sesión. Neste modo, calquera lado pode enviar datos en calquera momento, e estes datos reenvíenos a / desde o shell ou o comando no lado do servidor e o terminal do usuario no lado do cliente.
Cando o programa de usuario finaliza e todas as conexións X11 e outras conexións foron pechadas, o servidor envía o estado de saída do comando ao cliente e ambos os dous lados saen.
sshd pódese configurar usando opcións de liña de comandos ou un ficheiro de configuración. As opcións de liña de comandos anulan os valores especificados no ficheiro de configuración.
sshd lee o seu ficheiro de configuración cando recibe un sinal de suspensión, SIGHUP executándose co nome que se iniciou como, por exemplo, / usr / sbin / sshd
As opcións son as seguintes:
b bits
Especifica o número de bits na clave de servidor da versión 1 do protocolo efémero (por defecto 768).
-d
Modo de depuración. O servidor envía saída de depuración detallada ao rexistro do sistema e non se coloca no fondo. O servidor tamén non funcionará e só procesará unha conexión. Esta opción só ten como obxectivo a depuración do servidor. As opcións de múltiple -d incrementan o nivel de depuración. O máximo é 3.
-e
Cando se especifica esta opción, sshd enviará a saída ao erro estándar no canto do rexistro do sistema.
-f file_configuración
Especifica o nome do ficheiro de configuración. O valor predeterminado é / etc / ssh / sshd_config sshd rexeita comezar se non hai ningún ficheiro de configuración.
-g login_grace_time
Dá tempo de graza para que os clientes se autenticen (por defecto 120 segundos). Se o cliente non pode autenticar o usuario nuns segundos, o servidor desconéctase e sae. Un valor de cero non indica límite.
ficheiro_h host_key_file
Especifica un ficheiro desde o que se le a chave host. Esta opción ten que ser dada se sshd non se executa como root (xa que os ficheiros de chave normal do host normalmente non son lexibles por ninguén, senón root). O valor predeterminado é / etc / ssh / ssh_host_key para a versión de protocolo 1 e / etc / ssh / ssh_host_rsa_key e / etc / ssh / ssh_host_dsa_key para a versión de protocolo 2. É posíbel dispoñer de varios ficheiros de chaves host para as diferentes versións de protocolo e chave de servidor algoritmos.
-i
Especifica que o sshd estase executando desde inetd. sshd normalmente non se executa desde inetd porque necesita xerar a clave do servidor antes de que poida responder ao cliente, e isto pode levar decenas de segundos. Os clientes terían que esperar moito tempo se a chave foi rexenerada cada vez. Non obstante, pode ser factible usar pequenos tamaños de chaves (por exemplo, 512) usando sshd desde inetd.
-k key_gen_time
Especifica a frecuencia coa que se rexenera a clave do servidor de protocolo de protocolo efémero (por defecto 3600 segundos ou unha hora). A motivación para rexenerar a chave con bastante frecuencia é que a chave non se almacena en ningún lado e, despois de aproximadamente unha hora, faise imposible recuperar a chave para descifrar comunicacións interceptadas mesmo se a máquina está fisurada ou fisicamente confiscada. Un valor de cero indica que a chave nunca será rexenerada.
-o opción
Pódese usar para dar opcións no formato empregado no ficheiro de configuración. Isto é útil para especificar opcións para as que non hai unha marca de liña de comandos separada.
porto p
Especifica o porto no que o servidor escoita as conexións (por defecto 22). Permítense varias opcións de porto. Os portos especificados no ficheiro de configuración ignóranse cando se especifica un porto de liña de comandos.
-q
Modo silencioso. Non se envía nada ao rexistro do sistema. Normalmente iniciouse o inicio, a autenticación e a finalización de cada conexión.
-t
Modo proba. Verifique só a validez do ficheiro de configuración e cordura das teclas. Isto é útil para actualizar sshd de forma fiable como as opcións de configuración poden cambiar.
-u len
Esta opción emprégase para especificar o tamaño do campo na estrutura utmp que ten o nome do host remoto. Se o nome do servidor resuelto é máis longo do que se empregará o valor decimal pontificado. Isto permite que os servidores con nomes de servidor moi longos que desborden este campo aínda estean identificados de forma exclusiva. Especificando - u0 indica que só se deben poñer enderezos decimales pontuados no ficheiro utmp. - u0 tamén se usa para evitar que sshd tome as solicitudes DNS a menos que o mecanismo ou a configuración de autenticación o esixe. Os mecanismos de autenticación que poden requirir DNS inclúen RhostsAuthentication RhostsRSAAuthentication HostbasedAuthentication e usan unha opción de = pattern-list en un ficheiro de chaves. As opcións de configuración que requiren DNS inclúen o uso dun patrón USER @ HOST en AllowUsers ou DenyUsers
-D
Cando se especifica esta opción sshd non se separará e non se converterá nun demo. Isto permite un fácil seguimento de sshd
-4
Forzas sshd para usar enderezos IPv4 só.
-6
Forzas sshd para usar enderezos IPv6 só.
Ficheiro de configuración
sshd le os datos de configuración de / etc / ssh / sshd_config (ou o ficheiro especificado con - f na liña de comando). O formato do ficheiro e as opcións de configuración descríbense en sshd_config5.
Proceso de inicio de sesión
Cando un usuario accede correctamente, sshd fai o seguinte:
- Se o inicio de sesión está nun tty, e non se especificou ningún comando, imprime o último tempo de inicio de sesión e / etc / motd (a menos que se prevexa no ficheiro de configuración ou en $ HOME / .hushlogin vexa a sección SX FILES).
- Se o inicio de sesión está nun tty, rexistra o tempo de inicio de sesión.
- Comproba / etc / nologin se existe, imprime os contidos e sae (a menos que se active).
- Cambios a executar con privilexios de usuario normais.
- Estabelece o ambiente básico.
- Lee $ HOME / .ssh / environment se existe e os usuarios poden cambiar o seu ambiente. Vexa a opción PermitUserEnvironment en sshd_config5.
- Cambios no directorio persoal do usuario.
- Se existe $ HOME / .ssh / rc, executa-lo; outra cousa se / etc / ssh / sshrc existe, execútea; polo contrario execútase xauth. Os ficheiros `` rc '' reciben o protocolo de autenticación X11 e as cookies na entrada estándar.
- Executa o shell ou o comando do usuario.
Formato de ficheiro Autorizado_Key
$ HOME / .ssh / authorized_keys é o ficheiro predeterminado que enumera as claves públicas permitidas para a autenticación RSA na versión de protocolo 1 e para a autenticación de clave pública (PubkeyAuthentication) na versión de protocolo 2. AutorizedKeysFile pode usarse para especificar un ficheiro alternativo.
Cada liña do ficheiro contén unha chave (as liñas e liñas baleiras que comezan por un '#' son ignoradas como comentarios). Cada clave pública de RSA consta dos seguintes campos, separados por espazos: opcións, bit, exponente, módulo, comentario. Cada clave pública de protocolo 2 consta de: opcións, keytype, clave base64 codificada, comentario. O campo de opcións é opcional; a súa presenza determínase se a liña comeza cun número ou non (o campo de opcións nunca comeza cun número). Os campos de bits, exponente, módulo e comentario dan a clave RSA para a versión de protocolo 1; o campo de comentarios non se usa para nada (pero pode ser conveniente para que o usuario identifique a clave). Para a versión de protocolo 2 o teclado é `` ssh-dss '' ou `` ssh-rsa ''
Lembre que as liñas neste ficheiro son xeralmente de varios centos de bytes de lonxitude (debido ao tamaño da codificación de clave pública). Non quere escribilos nel; en vez, copie o identity.pub id_dsa.pub ou o ficheiro id_rsa.pub e edítelo.
sshd cumpre un tamaño de módulo de chave RSA mínimo para o protocolo 1 e as claves de protocolo de 768 bits.
As opcións (se están presentes) consisten en especificacións de opcións separadas por comas. Non se permiten espazos, excepto dentro de comiñas dobres. Especificacións das seguintes opcións son compatibles (note que as palabras clave de opción non son sensibles a maiúsculas):
de = lista de patróns
Especifica que ademais da autenticación de clave pública, o nome canónico do servidor remoto debe estar presente na lista de patróns separados por comas (`* 'e`?' Como comodín). A lista tamén pode conter patróns negados prefixándolos con `! ' ; se o nome do servidor canónico coincide cun patrón negado, non se acepta a chave. O obxectivo desta opción é incrementar opcionalmente a seguridade: autenticación de chave pública por si mesma non confía nos servidores de rede ou de nome nin nada (pero a clave); Con todo, se alguén rouba dalgunha forma a chave, a clave permite que un intruso acceda desde calquera parte do mundo. Esta opción adicional fai que o uso dunha chave roubada sexa máis difícil (os servidores de nomes e / ou enrutadores terían que ser comprometidos ademais de só a chave).
comando = comando
Especifica que o comando se executa sempre que se usa esta clave para a autenticación. O comando fornecido polo usuario (se hai) é ignorado. O comando execútase nun pty se o cliente solicita un pty; se non, é executado sen un tty. Se se require unha canle limpa de 8 bits, non se debe solicitar un pty ou se debe especificar non-pty Pode incluír unha cita no comando citándoa cunha barra invertida. Esta opción pode ser útil para restrinxir certas chaves públicas para que realice só unha operación específica. Un exemplo pode ser unha chave que permite copias de seguridade remotas pero nada máis. Teña en conta que o cliente pode especificar o reenvío TCP / IP e / ou X11 a menos que estean explicitamente prohibidos. Ten en conta que esta opción aplícase á execución de shell, command ou subsystem.
ambiente = NAME = valor
Especifica que a cadea se engadirá ao medio ao iniciar sesión usando esta tecla. As variables de ambiente establecidas deste xeito anularán outros valores de ambiente por defecto. Múltiples opcións deste tipo están permitidas. O procesamento do ambiente está desactivado de xeito predeterminado e é controlado a través da opción PermitUserEnvironment . Esta opción desactívase automaticamente se UseLogin está activado.
non-port-forwarding
Proporciona o reenvío de TCP / IP cando se usa esta chave para a autenticación. Calquera petición de reenvío do porto polo cliente devolverá un erro. Isto pódese empregar, por exemplo, en conexión coa opción de comando .
non-X11-reenvío
Elimina o reenvío X11 cando se usa esta chave para a autenticación. Calquera X11 solicitudes a futuro polo cliente devolverá un erro.
reenvío de axentes
Elimina o reenvío de axentes de autenticación cando se usa esta clave para a autenticación.
sen pty
Evita a asignación de tty (unha solicitude para asignar un pty fallará).
permitopen = host: port
Limite o reenvío local do `` ssh -L '' de xeito que só se conecte ao servidor e ao porto especificados. As direccións IPv6 pódense especificar cunha sintaxe alternativa: servidor / porto Pódense aplicar múltiples opcións de permisos separadas por comas. Non se realiza ningunha coincidencia de patrón nos nomes de host especificados, deben ser dominios ou enderezos literales.
Exemplos
1024 33 12121 ... 312314325 ylo@foo.bar
from = "*. niksula.hut.fi,! pc.niksula.hut.fi" 1024 35 23 ... 2334 ylo @ niksula
comando = "dump / home", no-pty, non-port-forwarding 1024 33 23 ... 2323 backup.hut.fi
permitopen = "10.2.1.55:80", permitopen = "10.2.1.56:25" 1024 33 23 ... 2323
Formato de ficheiro Ssh_Known_Hosts
Os arquivos / etc / ssh / ssh_known_hosts e $ HOME / .ssh / known_hosts conteñen claves públicas para todos os hosts coñecidos. O administrador debe preparar o ficheiro global (opcional) e o ficheiro por usuario mantense automaticamente: sempre que o usuario se conecte desde un servidor descoñecido a súa clave engádese ao ficheiro por usuario.
Cada liña destes ficheiros contén os seguintes campos: nomes de host, bit, exponente, módulo, comentario. Os campos están separados por espazos.
Os nomes dos servidores son unha lista separada por vírgulas dos patróns ('*' e '?' Actúan como comodíns); cada patrón, á súa vez, coincide co nome de servidor canónico (cando se autentica un cliente) ou contra o nome proporcionado polo usuario (cando se autentica un servidor). Un patrón tamén pode estar precedido por `! ' para indicar a negación: se o nome do servidor coincide cun patrón negado, non se acepta (por esa liña) aínda que coincida con outro estándar na liña.
Os bits, exponente e módulo tómanse directamente da clave do servidor RSA; pódense obter, por exemplo, desde /etc/ssh/ssh_host_key.pub O campo de comentario opcional continúa ata o final da liña e non se usa.
As liñas que comezan con `# 'e as liñas baleiras son ignoradas como comentarios.
Ao realizar a autenticación do servidor, a autenticación é aceptada se algunha liña coincidente ten a chave correcta. Polo tanto, é admisible (pero non se recomenda) ter varias liñas ou teclas host diferentes para os mesmos nomes. Isto inevitablemente ocorrerá cando as formas curtas de nomes de servidor de diferentes dominios se coloquen no ficheiro. É posible que os ficheiros conteñen información confidencial; A autenticación é aceptada se se pode atopar información válida a partir do ficheiro.
Teña en conta que as liñas destes ficheiros son normalmente centos de caracteres e definitivamente non quere teclear as teclas host con man. Polo contrario, xéralas por un script ou facendo /etc/ssh/ssh_host_key.pub e engadindo os nomes de host na fronte.
Exemplos
closenet, ..., 130.233.208.41 1024 37 159 ... 93 closenet.hut.fi cvs.openbsd.org, 199.185.137.3 ssh-rsa AAAA1234 ..... =Ver tamén
scp (1), sftp (1), ssh (1), ssh-add1, ssh-agent1, ssh-keygen1, login.conf5, módulos (5), sshd_config5, sftp-server8
T. Ylonen T. Kivinen M. Saarinen T. Rinne S. Lehtinen "Arquitectura de protocolo SSH" draft-ietf-secsh-architecture-12.txt Xaneiro 2002 traballo en progreso material
M. Friedl N. Provos WA Simpson "Intercambio de grupo Diffie-Hellman para o protocolo de capa de transporte SSH" draft-ietf-secsh-dh-group-exchange-02.txt xaneiro 2002 traballo en progreso material
Importante: use o comando man ( % home ) para ver como se usa un comando na súa computadora particular.