Conéctese a un servidor virtual a través de SSH y SFTP. Conexión al servidor mediante SSH y SFTP Conexión mediante ssh mediante PuTTY
¿Qué es SSH y por qué lo necesita?
Secure Shell (SSH) es un protocolo de red que proporciona funciones de shell a una máquina remota a través de un canal seguro. SSH viene con varias mejoras de seguridad, incluyendo autenticación de usuario/host, cifrado de datos e integridad de datos, lo que hace imposibles ataques populares como escuchas ilegales, suplantación de DNS/IP, falsificación de datos y secuestro de conexiones, etc. Los usuarios de ftp, telnet o rlogin que utilizan un Se recomienda encarecidamente un protocolo que transfiera datos en texto claro para cambiar a SSH.
OpenSSH es una implementación de código abierto del protocolo SSH que le permite cifrar su conexión de red a través de un conjunto de programas. Si desea tener SSH en Linux, puede instalar OpenSSH, que consta de un servidor OpenSSH y paquetes de cliente.
Los paquetes de servidor/cliente OpenSSH vienen con las siguientes utilidades:
- Servidor OpenSSH: sshd (demonio SSH)
- Cliente OpenSSH: scp (copia remota segura), sftp (transferencia segura de archivos), slogin/ssh (inicio de sesión remoto seguro), ssh-add (completación de clave privada), ssh-agent (agente de autenticación), ssh-keygen (administración de claves de autenticación) ).
Si desea instalar el servidor/cliente OpenSSH y configurar el servidor OpenSSH para que se inicie automáticamente, siga las siguientes instrucciones, que varían según la distribución.
Debian, Ubuntu o Linux Mint
$ sudo apt-get install openssh-server openssh-client
En los sistemas basados en Debian, una vez instalado, OpenSSH se iniciará automáticamente al arrancar. Si por alguna razón el servidor OpenSSH no se inicia automáticamente al iniciar el sistema, puede ejecutar el siguiente comando para agregar ssh explícitamente al inicio al iniciar el sistema.
$ sudo update-rc.d valores predeterminados de ssh
Fedora o CentOS/RHEL 7$ sudo yum -y install openssh-server openssh-clients $ sudo systemctl start sshd service $ sudo systemctl enable sshd.service
CentOS/RHEL 6$ sudo yum -y install openssh-server openssh-clients $ sudo service sshd start $ sudo chkconfig sshd on
Arco Linux$ sudo pacman -Sy openssh $ sudo systemctl iniciar servicio sshd $ sudo systemctl habilitar sshd.service
Configurar un servidor OpenSSHSi desea configurar el servidor OpenSSH, puede editar el archivo de configuración de todo el sistema ubicado en /etc/ssh/sshd_config.
Hay un par de opciones de OpenSSH que pueden resultar de interés:
De forma predeterminada, sshd escucha en el puerto 22 y escucha las conexiones ssh entrantes. Al cambiar el puerto predeterminado para ssh, puede evitar varios ataques de piratas informáticos automatizados.
Si su máquina tiene más de una interfaz de red física, es posible que desee verificar cuál está asociada con sshd, para esto puede usar la opción ListenAddress. Esta opción ayuda a mejorar la seguridad al limitar el SSH entrante solo a una interfaz específica.
Clave de host /etc/ssh/ssh_host_key
La opción HostKey determina dónde se encuentra la clave de host personal.
PermitRootLogin no
Opción PermitRootLogin: si el root puede iniciar sesión en el sistema a través de ssh.
AllowUsers alice bob
Con la opción AllowUsers, puede desactivar selectivamente el servicio ssh para ciertos usuarios de Linux. Puede especificar varios usuarios, separados por espacios.
Después de cambiar /etc/ssh/sshd_config, asegúrese de reiniciar el servicio ssh.
Para reiniciar OpenSSH en Debian, Ubuntu o Linux Mint:
$ sudo /etc/init.d/ssh reiniciar
Para reiniciar OpenSSH en Fedora, CentOS/RHEL 7 o Arch Linux:$ sudo systemctl reiniciar sshd.service
Para reiniciar OpenSSH en CentOS/RHEL 6:$ sudo servicio sshd reiniciar
Cómo conectarse a SSHConexión a SSH desde Linux
Los usuarios de Linux no necesitan instalar programas adicionales.
Conexión a SSH desde Windows
Oculto de los invitados
.Cygwin es más que un simple cliente SSH. Es un potente combinador que admite muchos comandos de Linux. Por ejemplo, Cygwin facilita la creación de certificados SSL (como Linux). En Windows, para crear certificados autofirmados es necesario bailar con una pandereta. Cygwin es muy conveniente para usar cURL (no es necesario instalar nada por separado), etc. Aquellos que carecen de una línea de comando y programas de Linux en Windows encontrarán una salida en Cygwin.
Instalar Cygwin es fácil. Vamos a
Oculto de los invitados
y descargar
Oculto de los invitados
Oculto de los invitados
Se descargará un pequeño archivo: este es el instalador. Instalador gráfico. Aunque contiene una gran cantidad de opciones, todas son bastante simples y muchas de ellas resultan familiares por otros instaladores gráficos. Si algo no queda claro, simplemente haga clic en "Siguiente". Quizás sólo la siguiente ventana pueda dar lugar a confusión:
Todos los elementos disponibles para la instalación se presentan aquí. No necesitamos entenderlos ahora. Porque los más populares ya están marcados para su instalación. Y si falta algo en el futuro, podrás instalar fácilmente lo que necesites.
Conexión SSH (común a Linux y Windows)
Los usuarios de Linux abren la consola, los usuarios de Windows escriben Cygwin.
SSH necesita la siguiente información para conectarse:
- IP o nombre de host
- número de puerto
- Nombre de usuario
- contraseña de usuario
Ssh 192.168.1.36
veo lo siguiente
Alex@MiAl-PC ~ $ ssh 192.168.1.36 No se puede establecer la autenticidad del host "192.168.1.36 (192.168.1.36)". La huella digital de la clave ECDSA es SHA256:sIxZeSuiivoEQ00RXAQHxylxuEA8SC5r/YPhL8wfp8s. ¿Está seguro de que desea continuar conectándose ( sí No)?
Como me conecto al host por primera vez, es un host desconocido. Me preguntan si quiero continuar. estoy marcando Sí:
Advertencia: Se agregó permanentemente "192.168.1.36" (ECDSA) a la lista de hosts conocidos. [correo electrónico protegido]"contraseña:
Bien, el host 192.168.1.36 se ha agregado a la lista de hosts familiares. Me solicitan una contraseña para el usuario Alex. Como no existe tal usuario en el servidor con SSH, pero hago clic en Ctrl+C(para romper) e ingrese el comando junto con el nombre de usuario del sistema remoto. El usuario se ingresa antes de la dirección de la máquina remota y está separado de la dirección por el símbolo @. El símbolo @ en inglés se lee como at y puede traducirse como “in”. Aquellos. registro [correo electrónico protegido] puede interpretarse como "usuario mial en la máquina 192.168.1.36".
ssh [correo electrónico protegido]
La invitación Alex@MiAl-PC fue reemplazada por la invitación mial@mint. Esto significa que ya estamos en la máquina remota, es decir, ya hemos realizado una conexión. Si necesita especificar un puerto (si difiere del estándar), entonces el puerto debe especificarse después del modificador -p. Por ejemplo así:
ssh [correo electrónico protegido]-p 10456
Después de conectarnos, nos saluda algo como esto:
Linux mint 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt11-1 (2015-05-24) x86_64 Los programas incluidos con el sistema Debian GNU/Linux son software libre; Los términos de distribución exactos para cada programa se describen en los archivos individuales en /usr/share/doc/*/copyright. Debian GNU/Linux no incluye ABSOLUTAMENTE NINGUNA GARANTÍA, en la medida permitida por la ley aplicable. Último inicio de sesión: martes 16 de junio 15:32:25 2015 desde 192.168.1.35
De ello se deduce que la máquina remota es Linux Mint, con kernel 3.16, versión de 64 bits. También es información importante la hora del último inicio de sesión y la dirección IP desde la que se originó la conexión. Si no conoce la hora ni la IP y es el único usuario, entonces su sistema está comprometido y debe tomar las medidas adecuadas.
Escribamos algunos comandos para asegurarnos de dónde estamos y quiénes somos: contraseña, [B]uname -a etc.:
Para finalizar la sesión (cerrar sesión), marque
O haga clic Ctrl+D.
Inicie sesión en SSH sin ingresar una contraseña
En primer lugar, es más conveniente. En segundo lugar, es más seguro.
Primero, necesitamos crear claves rsa. Si eres un usuario de Linux, entonces estás bien. Si eres usuario de Windows, pero no escuchaste mis consejos y elegiste PuTTY, entonces tienes un problema y piensa por ti mismo cómo solucionarlo. Si tienes Cygwin, entonces todo también está en orden.
Si logró iniciar sesión en el sistema remoto, cierre la sesión. Después de eso, marque
Ssh-keygen -t rsa
Se nos solicita un nombre de archivo, no necesitamos ingresar nada, se usará el nombre predeterminado. También pide una contraseña. No ingreso la contraseña.
Ahora en la máquina remota necesitamos crear un directorio .ssh. La ejecución del comando en una máquina remota se analizará a continuación. Por ahora, simplemente copie el comando, sin olvidar cambiar la dirección IP y el nombre de usuario por los suyos:
ssh [correo electrónico protegido] mkdir.ssh
Ahora necesitamos copiar el contenido del archivo id_rsa.pub a la máquina remota. Esto es muy fácil de hacer (no olvides cambiar los datos por los tuyos):
Gato .ssh/id_rsa.pub | ssh [correo electrónico protegido]"gato >> .ssh/claves_autorizadas"
Ahora simplemente iniciamos sesión y ya no nos piden ninguna contraseña. Y siempre será así ahora.
Ejecutar comandos en un servidor remoto sin crear una sesión de shell
Además de abrir una sesión de shell en un sistema remoto, ssh también le permite ejecutar comandos individuales en el sistema remoto. Por ejemplo, para ejecutar el comando de árbol en un host remoto llamado remote-sys y mostrar los resultados en el sistema local, haría lo siguiente:
Árbol de sistema remoto Ssh
Mi verdadero ejemplo:
ssh [correo electrónico protegido]árbol
Con esta técnica puedes hacer cosas interesantes, como ejecutar un comando ls en un sistema remoto y redirigir la salida a un archivo en el sistema local:
Ssh sistema remoto "ls *" > dirlist.txt
Ejemplo real:
ssh [correo electrónico protegido]"ls *" > listadir.txt cat listadir.txt
Tenga en cuenta las comillas simples en el comando anterior. Esto se debe a que no queremos que la expansión de la ruta se realice en la máquina local; porque necesitamos esta ejecución en un sistema remoto. Además, si queremos redirigir la salida estándar a un archivo en la máquina remota, podemos poner la declaración de redirección y el nombre del archivo entre comillas simples:
Ssh sistema remoto "ls * > dirlist.txt"
Transferir salida estándar de la máquina local a la máquina remota a través de sshUna opción igualmente interesante para ejecutar comandos se ofrece un poco más arriba:
Gato .ssh/id_rsa.pub | ssh [correo electrónico protegido]"gato >> .ssh/claves_autorizadas"
- El comando cat lee línea por línea y muestra el contenido del archivo .ssh/id_rsa.pub ubicado en la máquina local.
- | (tubería) pasa lo que aparecería en la salida estándar a otro comando.
- En lugar de un comando que procesaría las cadenas que se le pasan, se realiza una conexión al sistema remoto (ssh [correo electrónico protegido]).
- El sistema remoto recibe líneas para las que se proporciona el comando cat >> .ssh/authorized_keys. Aquellos. el contenido de la salida estándar se escribe línea por línea en el archivo .ssh/authorized_keys ubicado en la máquina remota.
El siguiente truco requiere dos computadoras con Linux. Desafortunadamente, ni siquiera Cygwin puede manejar este truco. Además, ambos sistemas Linux deben tener una interfaz gráfica de usuario.
Túnel con SSH
Entre otras cosas que sucede cuando se establece una conexión con un host remoto a través de SSH está la creación de un túnel cifrado que se forma entre los sistemas local y remoto. Normalmente, este túnel se utiliza para garantizar que los comandos escritos en la máquina local se transmitan de forma segura a una máquina remota y que el resultado también se envíe de vuelta de forma segura.
Además de esta funcionalidad básica, el protocolo SSH permite enviar la mayoría de los tipos de tráfico a través de un túnel cifrado, creando una especie de VPN (red privada virtual) entre los sistemas local y remoto.
Quizás la más comúnmente utilizada de estas características es la capacidad de transmitir el tráfico de los sistemas X Window. En un sistema que ejecuta un servidor X (estas son máquinas que tienen una interfaz gráfica de usuario), es posible ejecutar un programa cliente X (una aplicación gráfica) en un sistema remoto y ver los resultados de su funcionamiento en el sistema local. Es facil de hacer. Por ejemplo, quiero conectarme al host remoto remote-sys y en él quiero ejecutar el programa xload. Al mismo tiempo, podré ver la salida gráfica de este programa en la computadora local. Esto se hace así:
Ssh -X xload del sistema remoto
Ejemplo real:
Ssh -X [correo electrónico protegido] gedit
Aquellos. SSH comienza con el modificador -X. Y luego el programa simplemente comienza. Mira la captura de pantalla.
Estoy en Kali Linux. Inicié sesión exitosamente en una computadora remota a través de SSH. Después de eso ejecuté el programa gedit. Puede que este programa ni siquiera esté en Kali Linux, pero definitivamente está en Linux Mint, que es a lo que me conecté. Puedo ver el resultado de este programa en la pantalla como si el programa se estuviera ejecutando localmente. Pero nuevamente, quiero que entiendas esto: no hay ningún programa gedit ejecutándose en la computadora local. Si quiero guardar el resultado de gedit (o cualquier otro programa abierto de esta manera), resulta que funciona en el entorno de la computadora remota, ve su sistema de archivos, etc. Esto es conveniente cuando desea configurar el computadora remota mediante una interfaz gráfica.
Aprenderá cómo transferir una imagen desde todo el escritorio en el mismo artículo más adelante, en la sección “Cómo configurar VNC a través de SSH”.
En algunos sistemas, este truco requiere usar la opción -Y en lugar de la opción -X.
Copiar desde/hacia una computadora remota (scp y sftp)
scp
El paquete OpenSSH también incluye dos programas que utilizan un túnel SSH cifrado para copiar archivos a través de la red. Primer programa - scp(“copia segura”): se usa con más frecuencia, como el programa cp similar para copiar archivos. La diferencia más notable es que la fuente del archivo puede ser el host remoto seguido de dos puntos y la ubicación del archivo. Por ejemplo, si quisiéramos copiar un documento llamado document.txt desde nuestro directorio de inicio a sistema remoto en el directorio de trabajo actual de nuestro sistema local, podríamos hacer esto:
Scp sistema remoto:document.txt. documento.txt 100% 177 0.2KB/s 00:00
Ejemplo real:
# eliminar el archivo en la máquina local si existe rm dirlist.txt # crear un archivo en la máquina remota ssh [correo electrónico protegido]"ls * > dirlist.txt" # comprueba su presencia ssh [correo electrónico protegido]"ls -l" # copiarlo a la máquina local scp [correo electrónico protegido]: lista de direcciones.txt. # comprueba su contenido cat dirlist.txt
ftpPara copiar un archivo de B a A cuando inicia sesión en B:
scp /ruta/al/archivo nombre de usuario@a:/ruta/al/destino
Copiar un archivo de B a A cuando se inicia sesión en A:
scp nombre de usuario@b:/ruta/al/archivo /ruta/al/destino
El segundo programa para copiar archivos a través de SSH es ftp. Como sugiere su nombre, es un reemplazo seguro del programa ftp. sftp funciona como el programa ftp original. Sin embargo, en lugar de enviar texto sin cifrar, utiliza un túnel SSH cifrado. Una ventaja importante de sftp sobre ftp es que no requiere un servidor FTP en ejecución en un host remoto. Sólo requiere un servidor SSH. Esto significa que cualquier máquina remota que esté conectada a través de un cliente SSH también puede usarse como un servidor tipo FTP. Aquí hay una sesión de ejemplo:
Alex@MiAl-PC ~$sftp [correo electrónico protegido] Conectado a 192.168.1.36. sftp> ls dirlist.txt newfile.txt nfile.txt temp Vídeos Documentos Descargas Imágenes Música Plantillas de escritorio público sftp> lls dirlist.txt nfile.txt sftp> ls temp temp/TakeMeHome sftp> cd temp/ sftp> get TakeMeHome Fetching /home / mial/temp/TakeMeHome a TakeMeHome sftp>adiós
El protocolo SFTP es compatible con muchos administradores de archivos gráficos que se pueden encontrar en las distribuciones de Linux. Usando tanto Nautilus (GNOME) como Konqueror (KDE), podemos ingresar URI (enlaces) que comiencen con sftp:// en la barra de salto y trabajar con archivos ubicados en un sistema remoto que ejecuta un servidor SSH.
¡Hola! Me interesa la pregunta: cómo conectarse vía SSH a la computadora de su hogar a través de Internet. Tengo un servidor FreeSSHd instalado en casa. Según tengo entendido, ¿necesito abrir de alguna manera el puerto 22 en la IP externa? Alex
Sí, a menudo surge la necesidad. Hablé de muchas cosas en ese artículo, pero aquí hablaremos exclusivamente de SSH, ya que Alex amablemente nos brindó esta oportunidad. Además, yo mismo estoy increíblemente interesado en SSH, y aquí también está en Windows... mmm.
¿Qué es SSH y por qué es necesario?
El punto es que SSH es S seguro SH ana. Protocolo para acceso seguro al shell de control. Por lo tanto, proporciona acceso específicamente a la línea de comando, porque Shell se traduce como caparazón y aquí en el significado shell de control de texto. Pero en general, este protocolo destaca por permitir que cualquier otro tráfico pase dentro de él, y de forma cifrada. Por lo tanto, el protocolo de conexión seguro del sistema de archivos se llama SFTP y se ejecuta sobre SSH. Pero puede tunelizar absolutamente cualquier otra conexión, ya sea HTTP o incluso RDP. De hecho, resulta ser una “VPN de rodillas”.
Aquí Alex ya ha hecho la mitad del trabajo: instaló y ejecutó FreeSSHd en la computadora de su casa. Esto le permite conectarse a Windows a través de SSH. En este caso “permite” se dice con mucha fuerza. Porque esta solución funciona de alguna manera en Windows. En primer lugar, no tiene una interfaz de texto decente: una línea de comando para control.
Al menos el habitual, cmd, le permite hacer poco con la máquina remota. También existe Powershell: es una solución más moderna y potente. Freesshd te permite cambiar la consola a powershell, pero no pude conectarme. Me conecté a CMD, pero es completamente inutilizable:
En segundo lugar, en el caso de FreeSSHd, no pude conectarme a una computadora con Windows ni siquiera a través de una red local, sin mencionar la conexión a través de Internet. O mejor dicho, es posible conectarse, pero el servicio se congela y falla; no podrá administrar el host de Windows de esta manera.
Por lo tanto, supongo que Alex necesitaba un servidor ssh en Windows para conectarse al sistema de archivos o usarlo como VPN, enviando algo a través de SSH. Aunque dudo que FreeSSHd lo permita. Porque en tercer lugar: ni siquiera guarda la configuración, cuando reinicias el servicio todo sale mal. En general, realmente espero que Alex nos diga en los comentarios por qué necesitaba esto.
¿De qué otra manera puedes ejecutar SSH en Windows?
Existe una solución más viable: Powershelserver. Aunque también tiene fallos, al menos no falla. Por lo tanto, recomendaría usarlo para conectarse vía SSH a servidores Windows.
En primer lugar, funciona de forma estable y sin fallos. Y a través de él realmente puedes controlar Windows a través de PowerShell.
Todas las configuraciones se guardan normalmente. Están disponibles las mismas funciones que en FreeSSHd y aún más: puede usar SCP, que consiste en copiar archivos a través de SSH.
¡Pero lo más chic es la consola! ¡Funciona, señores!
Me conecté fácilmente, sin problemas para agregar usuarios (esto debe hacerse en freesshd). Y ese simple comando para ver la tabla de enrutamiento funcionó perfectamente y proporcionó la información necesaria. Frisssh “se enamoró” precisamente cuando intenté ver netstat -rn
Aquí se puede ver realmente que no se muestran los caracteres rusos. Así que es fácil de configurar con nosotros, simplemente configuro la codificación que necesito en powershellserver, reinicio, vuelvo a conectar...
Configuración de codificación en Powershellserver
Ahora tenemos SSH completo y podemos administrar Windows completamente a través de la consola.
Microsoft creará su propia solución SSH
Por cierto, Microsoft anunció el pasado verano que iba a desarrollar nativo Soporte SSH para Powershell en nuevas versiones de Windows. Hay anuncios de noticias en Habré y en pcweek (y más). Por lo tanto, sólo podemos esperar con interés este acontecimiento histórico, ya que será verdaderamente un gran avance para el trabajo en redes heterogéneas.
No verifiqué las otras funciones: sftp y scp, pero por alguna razón estoy seguro de que también funcionarán muy bien.
¿Cómo abrir un puerto SSH desde fuera?
Entonces, hemos llegado al secreto por el cual se inició este artículo en primer lugar. Responderé a la pregunta del lector.
Reenvío de puertos en un enrutador o módem
Para conectarse a una computadora desde el exterior, realmente necesita hacer NAT o, en un caso particular, . La forma de hacerlo depende del dispositivo que se utilice como puerta de enlace. Podría ser un módem ADSL o . En la mayoría de los casos, las instrucciones detalladas para su dispositivo se pueden encontrar fácilmente mediante consultas como "reenvío de puerto modelo_dispositivo" o "reenvío de puertos modelo_dispositivo»
Así es como se ve en mi enrutador doméstico Zyxel Keenetic Lite:
Y así se ve en un módem ADSL con la funcionalidad del router Linksys WAG200G que nos ocupa:
Además, con algunos proveedores esto puede no ser técnicamente posible porque no ofrecen "blanco".
Reenviar un puerto a un servidor remoto mediante un túnel SSH
En este caso, la única forma disponible para conectarnos vía SSH es desde una máquina Windows local (la misma a la que queremos conectarnos vía SSH) a un servidor remoto. En este caso, debes tener acceso SSH a algún servidor en Internet.
Configurar un túnel SSH "inverso"
Dicho reenvío se puede realizar fácilmente utilizando un simple cliente SSH Putty (también existe). Luego puede conectarse a este servidor muy remoto a través del puerto reenviado.
Bueno, si necesita compartir el puerto SSH de Windows con el mundo, basta con especificar ip_server:3322 como destino en la configuración del túnel inverso. Podrá conectarse a Windows a través de SSH desde cualquier lugar donde haya acceso a este mismo servidor.
¿Cómo comprobar si el puerto se reenvía correctamente?
Muy simple. Necesitas comprobar si está abierto. En el caso de SSH, el puerto abierto responderá con un mensaje sobre su versión. La forma más sencilla de comprobar un puerto es la utilidad telnet.
Simplemente escriba en la línea de comando, separado por espacios:
dominio telnet_o_puerto IP
Si el puerto está disponible, verá algo como esto:
Respuesta SSH si el puerto está disponible
Si el puerto no está disponible por algún motivo, verá "conexión rechazada" o "tiempo de espera de conexión". En el primer caso será instantáneo, y significa que el puerto queda cerrado por un firewall.
En el segundo caso, parecerá un "bloqueo" y puede durar varios minutos: el cliente Telnet intentará establecer una conexión. Esto también puede implicar el bloqueo mediante un firewall, pero de otro tipo. O simplemente que el host especificado no está disponible o que el puerto está cerrado.
Si pudo conectarse a través de telnet, presione la combinación de teclas Ctrl+] e ingrese abandonar, luego Entrar. De lo contrario, no podrás interrumpir la sesión y tendrás que abrir una nueva ventana de la consola si aún la necesitas.
Este artículo está marcado como inacabado. Ver nota al final del artículo.
Este artículo está dedicado al cliente y servidor de un terminal seguro (shell seguro) en Ubuntu, su configuración y uso. SSH es un protocolo de red especial que le permite obtener acceso remoto a una computadora con un alto grado de seguridad de conexión. Puede leer más sobre el protocolo ssh.
Descripción de los principios de funcionamiento y aplicaciones utilizadas.
Básicamente, SSH se implementa en forma de dos aplicaciones: un servidor SSH y un cliente SSH. Ubuntu utiliza una implementación gratuita de un cliente y un servidor SSH: OpenSSH. Al conectarse, el cliente se somete a un procedimiento de autorización con el servidor y se establece una conexión cifrada entre ellos. El servidor OpenSSH puede funcionar con los protocolos ssh1 y ssh2. Actualmente, el protocolo ssh1 se considera inseguro y se desaconseja su uso. Omito deliberadamente varios detalles técnicos del protocolo, ya que el objetivo principal de esta guía es describir su configuración y uso. Hay muchos artículos en Internet sobre el protocolo en sí, los principios de su funcionamiento, algoritmos de cifrado, etc., por ejemplo, puedes leer sobre él en detalle.
Instalación
Instalar AbiertoSSH Puedes usar el comando desde la terminal:
sudo apt-get instalar sshEl metapaquete ssh contiene un cliente y un servidor, pero lo más probable es que solo instale el servidor, ya que el cliente ya está incluido en Ubuntu de forma predeterminada.
Ajuste del servidor
Al instalar, el servidor SSH se agrega automáticamente al inicio. Puedes controlar su inicio, parada o reinicio usando los comandos:
parada de ssh del servicio sudo| inicio| ReanudarEl archivo de configuración principal para un servidor SSH es el archivo /etc/ssh/sshd_config, que solo puede ser leído o editado por el superusuario. Después de cada cambio en este archivo, debe reiniciar el servidor ssh para aplicar dichos cambios.
Ejemplo de configuración del servidor SSH predeterminado en Ubuntu:
# Un ejemplo de una configuración de servidor open-ssh con # # comentarios en ruso...2010. # # # # # # Convenciones: # # Por "predeterminado" nos referimos al comportamiento de sshd cuando # # la directiva no se especifica explícitamente. Vale la pena señalar que en Ubuntu # # el archivo sshd_config ya contiene una serie de configuraciones que # # son las configuraciones predeterminadas específicamente para Ubuntu. # # Estas configuraciones se especifican en este archivo. # # # ############################################### ############# ################ Configuración de dirección/puerto, etc. ########### ####################################### # ###################### # # ## Puerto ###################### ### ############################# # # # Puerto utilizado. Puede especificar varios, por ejemplo: # # Puerto 22 # # Puerto 23 # # Puerto 24 # # Se recomienda utilizar un puerto no estándar, porque # # estándar es a menudo escaneado por robots en busca de # # agujeros potenciales. Se puede omitir si se especifica # # mediante una dirección. Consulte también el parámetro ListenAddress. # # # Puerto 22 # # ## Dirección de escucha ######################################## ### # # # Dirección de red en la que escucha el servidor. La dirección se puede # # escribir así: # # ListenAddress host|IPv4_addr|IPv6_addr # # ListenAddress host|IPv4_addr:port # # ListenAddress:port # # Si no se especifica ningún puerto, sshd escuchará en esta dirección y # # en la puerto especificado en la opción Puerto. Si # # utiliza ListenAddress sin especificar un puerto, entonces la opción # # Port debe preceder a la opción ListenAddress. Si no # # se especifica, de forma predeterminada escucha en todas las # # direcciones locales. Puede especificar varias direcciones. # # # ## DirecciónFamilia ############################################ # # # Especifica qué familia de direcciones IP debe # # utilizar sshd. Opciones posibles: # # “cualquiera” - cualquiera # # “inet” (solo IPv4) # # “inet6” (solo IPv6) # # Predeterminado: “cualquiera”. # DirecciónFamilia inet # # ## UsarDNS ########################################## # ######## # # # Especifica si sshd debe verificar el nombre de host y # # usar ese nombre de host para verificar la dirección IP enviada por el cliente con # # la recibida de DNS. # # El valor predeterminado es “sí”. # # # ############################################### ############# ############# Configuración de acceso de usuario ############## ####### ################################################## ### # # # Permitir/no permitir a un usuario está determinado por las directivas # # DenyUsers, AllowUsers, DenyGroups y AllowGroups. # # en este caso, la verificación va de arriba a abajo a lo largo de la cadena: # # ## DenyUsers ## # # || # # ## Permitir usuarios ## # # || # # ## Denegar grupos ## # # || # # ## AllowGroups ## # # Solo se aceptan nombres de usuarios y grupos, # # identificadores numéricos (UserID) no se reconocen. Corregir # # grabación de varios usuarios/grupos por turno, separados por # # espacios. Si se escribe en el formato usuario@host, entonces # # el usuario y el host se verifican por separado, esto permite # # limitar el acceso a ciertos usuarios desde # # ciertos hosts. Vale la pena recordar que las directivas # # DenyUsers y AllowUsers toman el # # nombre del usuario como parámetro, mientras que DenyGroups y AllowGroups toman el # # nombre del grupo. Consulte PATRONES en man ssh_config para # # obtener más información sobre los formularios para registrar nombres de usuarios y grupos. # # # ## Denegar usuarios ############################################ ### # # # Lista de USUARIOS que NO PUEDEN usar sshd. # # Predeterminado: no especificado = nadie está prohibido. Aquellos. si # # se especifica un usuario aquí, se le negará el acceso # # al servidor ssh. # # # ## Permitir usuarios ############################################ ## # # # Lista de USUARIOS que PUEDEN usar sshd, # # Por defecto - no especificado = permitido para todos. Aquellos. si # # se especifica al menos un usuario, el acceso ssh al servidor # # solo está disponible para ese usuario. # # # ## Denegar grupos ############################################ ## # # # Lista de GRUPOS que NO deben ser utilizados por sshd. # # Predeterminado: no especificado = ningún grupo está prohibido. # # Eso es si se especifica al menos un grupo, a los usuarios # # incluidos en este grupo se les negará el acceso al servidor ssh # #. # # # ## Permitir grupos ############################################ # # # # Lista de GRUPOS que sshd PUEDE usar. # # Predeterminado: no especificado = permitido para todos. Aquellos. si # # se especifica al menos un grupo, entonces solo aquellos usuarios# # incluidos en él tendrán acceso al servidor ssh.# # # ################### # ################################################# ### Opciones que determinan el estado de la conexión ############# ############################# ####### ######################### # # ## TCPKeepAlive ############## ######### ######################### # # # Indica si el sistema necesita enviar mensajes TCP al cliente # # para mantener la conexión. Si envía estos paquetes, # # podrá determinar si la conexión está interrumpida. Sin embargo, esto también # # significa que la conexión puede interrumpirse en caso de una # # interrupción momentánea del enrutamiento y # # esto es muy molesto para algunos. Por otro lado, si # # dichos mensajes no se envían, las sesiones en el servidor pueden # # durar indefinidamente, creando usuarios “fantasmas” # # y devorando recursos del servidor. El valor predeterminado es “sí”, # # es decir. enviar tales mensajes. Para desactivar el envío de # # mensajes de este tipo, establezca el valor en "no". Anteriormente esta # # opción se llamaba KeepAlive. Vale la pena señalar que # # existen formas más seguras de verificar el estado de # # una conexión (ver más abajo). # # # TCPKeepAlive sí # # ## ClientAliveCountMax ####################################### # # # Establece el número de mensajes a los clientes que sshd # # envía seguidos sin recibir ninguna respuesta del # # cliente. Si se alcanza el umbral y # # el cliente no responde, sshd desconectará al cliente, finalizando la # # sesión ssh. Vale la pena señalar que el uso de dichos # # mensajes es completamente diferente de la directiva TCPKeepAlive. # # Los mensajes hacia/desde clientes se envían a través de un # # canal cifrado y, por lo tanto, no son susceptibles de suplantación de identidad. Los mensajes # # TCPKeepAlive son susceptibles de suplantación de identidad. El mecanismo de cliente activo # # es especialmente valioso en los casos en los que el servidor y el cliente necesitan # # saber cuándo la conexión se ha vuelto inactiva. El valor # # predeterminado es 3. En caso de que ClientAliveInterval # # se establezca en 15 y ClientAliveCountMax se deje en el # # valor predeterminado, los clientes que no respondan se desconectarán después de aproximadamente # # 45 segundos. Esta directiva sólo funciona para # # el protocolo ssh2. # # # ## ClientAliveInterval ######################################## # # # Conjuntos el intervalo de tiempo en segundos. Si no hay comunicación con el cliente durante # # este intervalo, sshd # # envía un mensaje a través de un canal cifrado solicitando una # # respuesta del cliente. El valor predeterminado es 0, es decir # # no envíes este tipo de mensajes. Esta directiva funciona # # sólo para el protocolo ssh2. # # # ############################################### ############# ################ Opciones generales de autenticación ################ ## ################################################## ######## # # ## Archivo de claves autorizadas ##################################### # # # # Especifica un archivo que contiene claves públicas # # utilizadas para autenticar usuarios. La # # directiva puede contener tokens del formato %M, que se insertan durante el # # proceso de establecimiento de la conexión. # # Se definen los siguientes tokens: # # %% - reemplazado con el literal "%" # # %h - reemplazado con el directorio de inicio # # del usuario autenticado # # %u - reemplazado con el nombre del usuario autenticado # # Por lo tanto, el archivo de clave se puede especificar como # # de forma absoluta (es decir, un archivo compartido con claves) y # # dinámicamente, dependiendo del usuario (es decir, un # # archivo para cada usuario). # # El valor predeterminado es “.ssh/authorized_keys”. # # Ejemplo de un archivo de clave en la carpeta de inicio del usuario: # # AuthorizedKeysFile %h/.ssh/authorized_key # # Ejemplo de un archivo compartido: # # AuthorizedKeysFile /etc/ssh/authorized_keys # # Consulte la descripción del archivo de claves_autorizadas para más información. # # # ## ChallengeResponseAuthentication ############################ # # # Especifica si se permite la autenticación de desafío-respuesta # # ). Se admiten todos # # tipos de autenticación desde login.conf. El valor predeterminado es "sí", # # es decir. permitir. # # En Ubuntu: deshabilitado por razones de seguridad. # # # ChallengeResponseAuthentication no # # ## HostbasedUsesNameFromPacketOnly ######################### # # # Especifica cómo el servidor debe obtener el nombre de host del cliente # # cuando un esquema de autenticación basado en la verificación del host. # # Si se establece en "yes", sshd # # usará el nombre de host proporcionado por el cliente al verificar una coincidencia en los archivos # # ~/.shosts, ~/.rhosts o /etc/hosts.equiv. # # (realizando resolución DNS inversa) Si se establece en "no"# # - sshd resolverá el nombre desde la propia conexión TCP. # # El valor predeterminado es "no". # # # ## IgnorarRhosts ############################################ # # # Impide el uso de archivos .rhosts y .shosts # # en la autenticación basada en host. # # (RhostsRSAAuthentication o HostbasedAuthentication). # # Los archivos /etc/hosts.equiv y /etc/ssh/shosts.equiv todavía están # # en uso. # # El valor predeterminado es “sí”. # # # IgnorarRhosts sí # # ## IgnorarUserKnownHosts ##################################### # # # Indica si sshd debe ignorar el archivo de usuario # # "hosts conocidos" ~/.ssh/known_hosts durante # # el proceso de autenticación basado en host # # (RhostsRSAAuthentication o HostbasedAuthentication). # # El valor predeterminado es "no". # # # ## PermitBlacklistedKeys ################################### # # # Indica si se debe aceptar sshd claves en la lista negra # # como comprometidas (claves # # comprometidas conocidas (consulte ssh-vulnkey)). Si se establece en "sí", # # los intentos de autenticación con dichas claves se registrarán # # y se aceptarán; si se establece en "no", # # los intentos de autenticación se rechazarán. # # El valor predeterminado es "no". # # # ## PermitirContraseñasEmpty ######################################## # # # En En caso de autenticación permitida con el uso de una contraseña, # # indica si es posible iniciar sesión con una contraseña en blanco. # # El valor predeterminado es "no". # # # PermitEmptyPasswords no # # ## PermitRootLogin ######################################## # # # # Indica si es posible iniciar sesión ssh como superusuario # # (root). Puede tomar los siguientes valores: # # “sí”: el superusuario puede iniciar sesión. Se aplica el # # esquema de autenticación global actual. # # # # “sin contraseña”: el superusuario puede iniciar sesión. # # La autenticación de contraseña se desactivará. # # # # “solo comandos forzados”: el superusuario podrá iniciar sesión usando # # autenticación basada en una clave pública y # # solo si pasa el comando requerido para ser ejecutado. # # Esto es útil para realizar copias de seguridad, # # incluso cuando es normal (es decir, no a través de ssh) # # el inicio de sesión de superusuario está deshabilitado. Se bloquearán todos los demás # # métodos de autenticación para el superusuario. # # # # “no”: el superusuario no puede utilizar ssh para # # iniciar sesión. # # # # El valor predeterminado es “sí”. # # # PermitRootLogin sí # # ## Protocolo ######################################## ######## # # # Especifica qué protocolo debe utilizar sshd. # # Los valores posibles de '1' y '2' son ssh1 y ssh2 # # respectivamente. Es posible la escritura simultánea, en cuyo caso # # los valores deben estar separados por comas. # # El valor predeterminado es “2.1”. # # Vale la pena señalar que el orden de los protocolos en las # # entradas no determina la prioridad, porque el cliente elige cuál # # de varios protocolos propuestos por el servidor # # utilizar. La entrada "2,1" es absolutamente idéntica # # a la entrada "1,2". # # # Protocolo 2 # # ## Usar PAM ######################################## ########## # # # Habilita la interfaz PAM (Módulo de autenticación conectable # # interfaz). Si se establece en "sí", todos los tipos de autenticación # # además del procesamiento del módulo de sesión y cuenta # # La autenticación PAM será utilizado en base a # # desafío-respuesta (ChallengeResponseAuthentication y # # PasswordAuthentication) porque # # La autenticación de desafío-respuesta en PAM generalmente cumple la misma función # # que la autenticación de contraseña, debe desactivar # # ya sea PasswordAuthentication o # # ChallengeResponseAuthentication. Vale la pena señalar que # # si la directiva UsePAM está habilitada, no podrá ejecutar # # sshd como usuario que no sea root. # # El valor predeterminado es no". # # # UsePAM sí # # ## Autenticación de contraseña ################################### # # # Indica si habilitado si la autenticación usa # # contraseña. # # El valor predeterminado es “sí”. # # # ## Clave de host ############################################ ##### # # # Especifica el archivo que contiene la clave de host privada # # utilizada por SSH. El valor predeterminado es /etc/ssh/ssh_host_key # # para el protocolo ssh1 y /etc/ssh/ssh_host_rsa_key y # # /etc/ssh/ssh_host_dsa_key para el protocolo ssh2. # # Vale la pena señalar que sshd no utilizará un archivo # # al que pueda acceder nadie que no sea el usuario. Puede # # usar varios archivos con claves, las claves son “rsa1” - # # para el protocolo ssh1 y “dsa”/“rsa” para el protocolo ssh2. # # # Clave de host /etc/ssh/ssh_host_rsa_key Clave de host /etc/ssh/ssh_host_dsa_key # # # ############################### ### ############################# ########## Opciones del protocolo SSH versión 1 (ssh1) ### ########## ##################################### ### #################### # No se recomienda ENCARECIDAMENTE utilizar el protocolo ssh1.# # El protocolo ssh2 es mucho más seguro que ssh1 # ### ######## ########################################## ####### # # ## Intervalo de regeneración clave ################################# # # # Para el Protocolo ssh1: una vez en un momento determinado # # se genera automáticamente una nueva # # clave de servidor temporal (si se ha utilizado alguna). Esto se hace para # # evitar que las sesiones interceptadas sean descifradas para # # posteriormente iniciar sesión en la máquina con los parámetros de estas sesiones y # # robar las claves. Dicha clave no se almacena en ningún lugar (se almacena en # # RAM). Esta directiva especifica la # # vida útil de la clave en segundos, después de lo cual # # se generará nuevamente. Si el valor se establece en 0 - # # la clave no se generará nuevamente. # # El valor predeterminado es 3600 (segundos). # # # KeyRegeneraciónIntervalo 3600 # # ## RhostsRSAAuthentication ################################## # # # Indica si la autenticación basado en archivos # # rhosts o /etc/hosts.equiv junto con # # autenticación de host exitosa a través de RSA. # # Solo relevante para el protocolo ssh1. # # El valor predeterminado es "no". # # # RhostsRSAAuthentication no # # ## RSAAuthentication ######################################## ## # # # Indica si se permite la autenticación RSA "pura". # # Solo relevante para el protocolo ssh1. # # El valor predeterminado es “sí”. # # # Autenticación RSAA sí # # ## ServerKeyBits ######################################### ### # # # Define el número de bits en la clave temporal del servidor para # # el protocolo ssh1. El valor mínimo es 512. # # El valor predeterminado es 1024. # ServerKeyBits 768 # # # ################################## # ############################ ########### Opciones del protocolo SSH versión 2 (ssh2) ## ## ######## ######################################## ### ################### # # ## Cifrados ####################### ## ###################### # # # Indica los algoritmos de cifrado permitidos para # # el protocolo ssh2. Varios algoritmos deben estar # # separados por comas. Algoritmos admitidos: # # “3des-cbc”, “aes128-cbc”, “aes192-cbc”, “aes256-cbc”, # # “aes128-ctr”, “aes192-ctr”, “aes256-ctr”, “ arcfour128”, # # “arcfour256”, “arcfour”, “blowfish-cbc”, “cast128-cbc”. # # Por defecto: # # aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128, # # arcfour256,arcfour,aes192-cbc,aes256-cbc,aes128-ctr, # # aes192-ctr, aes256 -ctr # # # ## Autenticación basada en host ################################### # # # Indica si la autenticación es habilitado, basado en # # verificación del host. rhosts o /etc/hosts.equiv están marcados, # # y, si tiene éxito, combinado con una verificación exitosa # # de la clave pública, se permite el acceso. Esta directiva # # es la misma que la directiva RhostsRSAAuthentication y # # solo es adecuada para el protocolo ssh2. # # El valor predeterminado es "no". # # # Autenticación basada en host no # # ## MAC ######################################## ############ # # # Indica un algoritmo MAC válido (mensaje # # código de autenticación). El protocolo ssh2 utiliza # # el algoritmo MAC para proteger la integridad de los datos. Varios # # algoritmos deben estar separados por comas. # # Predeterminado: # # hmac-md5,hmac-sha1, [correo electrónico protegido] ,hmac-ripemd160, # # hmac-sha1-96,hmac-md5-96 # # # ## PubkeyAuthentication ########################## ########## # # # Indica si se permite la autenticación basada en # # clave pública. Sólo relevante para el protocolo ssh2. # # El valor predeterminado es “sí”. # # # PubkeyAuthentication sí ############################################# # ################ #################### Opciones GSSAPI ########### ## ############# ################################### ## ######################### # # ############ Aplicable sólo para el protocolo ssh2 #### #### ### # # ## Autenticación GSSAPI ###################################### ## # # # Indica si la autenticación de usuario # # está basada o no en GSSAPI. El valor predeterminado es "no", es decir prohibido. # # # ## GSSAPIKeyExchange ######################################### # # # Indica si se permite el intercambio de claves basado en # # GSSAPI. El intercambio de claves mediante GSSAPI no depende de # # claves ssh para verificar la identidad del host. # # El valor predeterminado es "no", es decir. El intercambio está prohibido. # # # ## GSSAPICleanupCredentials ################################ # # # Especifica si se destruye automáticamente # # caché de usuario de credenciales de autenticación cuando # # finaliza la sesión. # # El valor predeterminado es "sí", es decir necesita ser destruido. # # # ## GSSAPIStrictAcceptorCheck ################################ # # # Especifica qué tan estricto debe ser el control de identidad # # cliente al autenticarse mediante GSSAPI. # # Un valor de "sí" hace que el cliente se autentique en el # # servicio de host receptor en el host actual. El valor "no" # # permite al cliente autenticarse utilizando cualquier # # clave de servicio. # # El valor predeterminado es "sí". # # Vale la pena señalar que establecer esto en "no" puede # # funcionar solo con bibliotecas Kerberos GSSAPI raras. # # # ############################################### ############# ################### Opciones de Kerberos ################ ########## ######################################## ### ################### # # ## Autenticación Kerberos ####################### ### ######## # # # Indica si la contraseña # # proporcionada por el usuario para la autenticación # # (PasswordAuthentication) requiere validación en el KDC de Kerberos. # # Para utilizar esta opción, el servidor debe # # verificar que el KDC sea verdadero. (El servidor necesita una # # servtab Kerberos que permita la verificación de la identidad del # # KDC) # # El valor predeterminado es “no”. # # # ## KerberosGetAFSToken ######################################### # # # Si AFS está activo y el usuario ha recibido un TGT Kerberos 5, # # si se debe intentar obtener un token AFS antes de que el usuario # # pueda acceder a su carpeta de inicio. # # El valor predeterminado es "no". # # # ## KerberosOrLocalPasswd ################################### # # # Indica qué hacer en caso de si falla la autenticación # # mediante Kerberos. Si # # valor = "sí", la contraseña se verificará utilizando # # cualquier mecanismo de autorización local adicional, # # por ejemplo /etc/passwd. # # El valor predeterminado es “sí”. # # # ## KerberosTicketCleanup ################################### # # # Indica si se debe eliminar automáticamente el archivo con # # caché de tickets de usuario al final de la sesión. # # El valor predeterminado es “sí”. # # # ############################################### ############# ################# Opciones de redireccionamiento ################## # ## ############################################### ## ############# # # ## AllowAgentForwarding ############################## #### ### # # # Indica si se permite o deshabilita la redirección # # ssh-agent. El valor predeterminado es "sí", es decir, permitir. # # Vale la pena señalar que deshabilitar la redirección no # # aumentará la seguridad hasta que los usuarios también # # se les negará el acceso al shell, ya que siempre pueden instalar # # sus propios agentes análogos # # # ## AllowTcpForwarding ####################### # ############### # # # Indica si habilitar o deshabilitar la redirección TCP. # # El valor predeterminado es “sí”, es decir permitir. Vale la pena señalar que # # que ambos en el En el caso de AllowAgentForwarding, deshabilitar # # la redirección no aumentará la seguridad siempre que # # los usuarios tengan acceso a la consola, porque pueden # # instalar sus homólogos. # # # # # ## GatewayPorts ######### ## ################################# # # # Especifica si se permite el acceso de hosts remotos a # # puertos reenviados. De forma predeterminada, sshd escucha # # conexiones a puertos reenviados solo en la # # interfaz loopback local. Esto evita que otros # # hosts remotos se conecten a los puertos reenviados. Puede # # utilizar GatewayPorts para permitir que sshd # # haga esto. La directiva puede tomar 3 valores: # # "no" - solo bucle invertido. # # "sí" - cualquier dirección. # # "clienteespecificado": direcciones especificadas por el cliente. # # # ## PermisoOpen ############################################ ## # # # Indica dónde se permite el reenvío de puertos TCP. # # La especificación de una redirección debe adoptar una de las # # siguientes formas: # # PermitOpen host:port # # PermitOpen IPv4_addr:port # # PermitOpen:port # # Se pueden especificar varias entradas separándolas con espacios. # # El argumento "cualquiera" se puede utilizar para eliminar todas las # # restricciones sobre el reenvío de puertos. De forma predeterminada, se permite cualquier # # redirección. # # # ## PermisoTúnel ############################################ # # # Indica si se permite la redirección de dispositivos tun. # # Puede tomar valores: # # “sí” # # “punto a punto” (3.ª capa de red) # # “ethernet” (2.ª capa de red) # # “no” # # El valor “sí” permite ambos “punto -a punto” # # y “ethernet” al mismo tiempo. El valor predeterminado es "no". # # # ############################################### ############# ################## Opciones de registro ################# ### ############################################### ## ############# # # ## SyslogFacility ############################## ## ########## # # # Establece el código de objeto de registro para escribir mensajes en # # syslog desde sshd. Valores posibles: # # DAEMON # # USER # # AUTH # # LOCAL0 # # LOCAL1 # # LOCAL2 # # LOCAL3 # # LOCAL4 # # LOCAL5 # # LOCAL6 # # LOCAL7 # # El valor predeterminado es AUTH. # # # SyslogFacility AUTH # # ## LogLevel ######################################### ######## # # # Establece el nivel de detalle del registro sshd. # # Opciones posibles: # # SILENCIO # # SILENCIO # # FATAL # # ERROR # # INFO # # VERBOSE # # DEBUG # # DEBUG1 # # DEBUG2 # # DEBUG3 # # El valor predeterminado es INFO. # # DEBUG y DEBUG1 son equivalentes entre sí. # # DEBUG2 y DEBUG3 establecen los niveles más altos de # # salida de depuración. El inicio de sesión en el nivel DEBUG amenaza # # la privacidad del usuario y no se recomienda. # # # INFORMACIÓN de nivel de registro # # ########################################### ################# ################### Redirección X11 ############ ######## ########################################## # ################### # # ## Reenvío X11 ######################### ### ################ # # # Indica si el subsistema de gráficos X11 # # la redirección está habilitada. Puede tomar los valores “sí” o “no”. # # El valor predeterminado es "no". # # Atención: habilitar la redirección X11 simple es # # un gran riesgo tanto para el servidor como para los clientes, porque En # # dicha redirección, la pantalla del proxy sshd # # acepta conexiones desde cualquier dirección. Utilice # # la directiva X11UseLocalhost para restringir el acceso al servidor de redireccionamiento # # X. Vale la pena señalar que # # deshabilitar la redirección no garantizará que # # usuarios no puedan redirigir X11, porque al tener # # acceso a la consola, siempre instalan su propio # # redirector. La redirección X11 # # se deshabilitará automáticamente si la directiva UseLogin # # está habilitada. # # # X11Reenvío sí # # ## X11UseLocalhost ######################################## # # # # Indica si sshd debe limitar el alcance del # # reenvío X11 a una dirección de loopback local, o # # debe permitir cualquier dirección. De forma predeterminada, sshd # # configura el servidor de redireccionamiento X11 en una dirección local # # y establece la parte del nombre de host de la variable de entorno DISPLAY # # en "localhost". Vale la pena señalar que # # algunos clientes X11 antiguos pueden no funcionar con estas # # configuraciones. El valor predeterminado es "sí", es decir la redirección # # está limitada por el host local, el valor - "no" - deshabilita las # # restricciones. # # # ## XAuthLocation ############################################ # # # Especifica la ruta completa al programa xauth. # # El valor predeterminado es /usr/bin/X11/xauth. # # # ## X11DisplayOffset ######################################### # # # Indica el número de la primera pantalla disponible para sshd como redirección # # X11. Esto se hace para # # que las X redirigidas no se superpongan con las # # reales. El valor predeterminado es 10. # # # X11DisplayOffset 10 # # ####################################### ## ###################### ################### Varias opciones ##### ## ################### ############################# ##### ############################ # # ## Iniciar sesiónGraceTime ############ ####### ######################### # # # Tiempo después del cual el servidor desconecta # # el usuario si no pudo iniciar sesión # # satisfactoriamente. Valor 0: permite al usuario # # iniciar sesión indefinidamente. El valor predeterminado es 120 (segundos). # # # LoginGraceTime 120 # # ## MaxAuthTries ######################################## ### #### # # # Indica el número máximo de intentos de autenticación # # permitidos por conexión. # # Una vez que el número de intentos fallidos exceda la mitad del # # valor especificado, todos los intentos posteriores # # se registrarán. El valor predeterminado es 6. # # # ## MaxSessions ###################################### ####### # # # Especifica el número máximo de conexiones simultáneas # # para cada conexión de red. El valor predeterminado es 10. # # # ## MaxStartups ######################################## ###### # # # Especifica el número máximo de # # conexiones no autorizadas simultáneas a sshd. Si # # el número de conexiones excede el límite, todas las # # conexiones adicionales se descartarán hasta que las # # conexiones actuales se completen con una autorización exitosa # # o el período de tiempo especificado en la directiva # # LoginGraceTime haya expirado. El valor predeterminado es 10. # # Opcionalmente, puede configurar las conexiones para que se restablezcan antes # # especificando tres valores como parámetro, separados # # por dos puntos “start:rate:full” (por ejemplo: "10:30 :60"). # # sshd rechazará un intento de conexión con una probabilidad igual a # # “tasa/100” (es decir. en nuestro ejemplo, 30%) si ya hay # # “inicio” (10) conexiones no autorizadas. # # La probabilidad aumenta linealmente y cualquier # # intento de conexión será rechazado si el número de # # conexiones no autorizadas llega al “completo” (60). # # # ## Compresión ############################################ # # # # Indica si la compresión de datos está habilitada. Puede ser # # "sí": la compresión está habilitada. # # "retrasada": la compresión se retrasa hasta # # que el usuario se autentica correctamente. # # "no": la compresión está deshabilitada. # # El valor predeterminado es "retrasado". # # # ## UsarIniciar sesión ############################################ #### # # # Indica si el inicio de sesión debe usarse para una # # sesión interactiva. El valor predeterminado es no". # # Vale la pena señalar que el inicio de sesión nunca se ha utilizado para # # ejecutar comandos remotos. También tenga en cuenta que # # usar login hará imposible # # usar la directiva X11Forwarding, porque login no sabe qué # # hacer con xauth. Si la directiva # # UsePrivilegeSeparation está habilitada, se deshabilitará después de # # autorización. # # # ## UsePrivilegeSeparation ###################################### # # # Especifica si sshd Deben separarse los privilegios. En caso afirmativo # #, primero se creará un proceso secundario # # sin privilegios para el tráfico de red entrante. Después de # # autorización exitosa, se creará otro proceso con los privilegios # # del usuario que inició sesión. El objetivo principal de la # # separación de privilegios es evitar el abuso de los derechos de acceso. # # El valor predeterminado es “sí”. # # # UsePrivilegeSeparation sí # # ## Modos estrictos ######################################## ### ##### # # # Indica si sshd debe verificar el acceso y # # modos de propiedad de las carpetas y archivos del usuario antes # # de permitir que el usuario inicie sesión. Esto suele deberse a que # # los novatos suelen hacer que sus archivos sean # # editables por todos. El valor predeterminado es "sí". # # # StrictModes sí # # ## AcceptEnv ######################################## ####### # # # Especifica qué variables de entorno pasadas # # por el cliente serán aceptadas. Vea la opción SendEnv en el cliente. # # Vale la pena señalar que pasar variables solo es posible # # para el protocolo ssh2. Las variables se especifican por nombre, # # se pueden usar máscaras ('*' y '?'). Puede especificar # # múltiples variables separadas por espacios o dividir AcceptEnv en # # múltiples líneas. Tenga cuidado: algunas # # variables de entorno se pueden utilizar para evitar # # entornos de usuario prohibidos. Utilice esta # # directiva con cuidado. De forma predeterminada, no se aceptan # # variables de entorno de usuario. # # # AcceptEnv LANG LC_* # # ## PermitUserEnvironment ################################### # # # Especifica si sshd debe aceptar # # ~/.ssh/environment y la opción Environment= en # # ~/.ssh/authorized_keys. El valor predeterminado es "no". # # Vale la pena señalar que habilitar el procesamiento del entorno puede brindar a # # usuarios la capacidad de eludir las restricciones en algunas # # configuraciones que utilizan mecanismos como # # LD_PRELOAD. # # # # # ## PidFile ########################################## # ####### # # # Especifica un archivo que contiene el ID de proceso # # (ID de proceso, PID) del demonio SSH. # # Predeterminado - /var/run/sshd.pid # # # # # ## PrintLastLog ############################## # ############## # # # Especifica si sshd debe mostrar la fecha y hora # # de la última sesión cuando el usuario inicia sesión interactivamente. # # El valor predeterminado es “sí”. # # # PrintLastLog sí # # ## PrintMotd ######################################## ####### # # # Especifica si sshd debe mostrar /etc/motd # # cuando un usuario inicia sesión interactivamente. En algunos # # sistemas (por ejemplo Ubuntu), esta información también # # se muestra en el shell. # # El valor predeterminado es “sí”. # # # PrintMotd no # # ## Banner ######################################## ########## # # # Indica qué archivo contiene un banner de texto que # # se mostrará al usuario ANTES del # # procedimiento de autenticación. La opción sólo está disponible para el protocolo ssh2.# # De forma predeterminada, no muestra nada. # # En Ubuntu, el archivo issues.net contiene la frase Ubuntu (versión), # # por ejemplo, para karmic es "Ubuntu 9.10". ¿Se puede # # utilizar para desorientar a posibles atacantes, # # escribiendo allí, por ejemplo, "Mi enrutador de Internet D-Link" =) # # # Banner /etc/issue.net # # ## ChrootDirectory ###### ##### ############################### # # # Si se especifica, proporciona la ruta para # # ser chroot después de la autenticación. La ruta y todo su # # contenido deben corresponder a carpetas # # propiedad del superusuario y no # # pueden ser escritas por otros usuarios. # # La ruta puede contener etiquetas que se sustituyen durante el # # proceso de autenticación: # # %% - reemplazada por el literal "%" # # %h - reemplazada por el directorio de inicio # # del usuario autenticado # # %u - reemplazado con el nombre del usuario autenticado # # chroot: la carpeta debe contener todos los archivos y # # carpetas necesarios para la sesión del usuario. Una # # sesión interactiva requiere como mínimo: # # un shell, generalmente sh # # dispositivos básicos en /dev como: # # null, zero, stdin, stdout, stderr, arandom y tty # # para una sesión de transferencia de datos usando sftp no # # se necesitan configuraciones adicionales si se utiliza el proceso interno # # del servidor sftp. Consulte Subsistema para # # obtener más información. De forma predeterminada, no se realiza chroot. # # # ## ForceCommand ############################################ # # # Hace que se ejecute el comando especificado. Ignora # # cualquier comando enviado por el cliente o escrito en # # ~/.ssh/rc. El comando se llama desde el # # shell del usuario con la opción -c. Adecuado para iniciar un shell, # # comando o subsistema. Más útil dentro de un bloque # # Match. El comando emitido originalmente por el cliente se almacena # # en la variable de entorno SSH_ORIGINAL_COMMAND. Si # # especifica el comando "internal-sftp", se iniciará el # # servidor sftp interno, que no necesita los # # archivos y carpetas adicionales descritos en la directiva ChrootDirectory. # # # ## Subsistema ############################################ ### # # # Define y configura un subsistema externo (por ejemplo # # demonio de transferencia de archivos). # # Los argumentos son el nombre y el comando (con posibles # # argumentos) que se ejecutará al solicitar # # subsistemas. El comando sftp-server inicia el subsistema de transferencia de archivos “sftp” - # #. Además, puede especificar # # “internal-sftp” como subsistema, que iniciará # # el servidor sftp interno. Esto puede simplificar enormemente # # la configuración cuando se utiliza la directiva # # ChrootDirectory. De forma predeterminada, no se llama a ningún subsistema # #. Sólo relevante para el protocolo ssh2. # # # Subsistema sftp /usr/lib/openssh/sftp-server # # ################################# ############################ ##################### Fósforo Bloquear ############################ ##################### ## ##################################### # # # Lo moví especialmente al final de el archivo para que sea más conveniente # # escribir reglas de coincidencia. ##MadKox. # # # # La directiva Match representa el inicio de un # # bloque condicional. Si se cumplen todos los criterios especificados en la línea # # Match, se ejecutan las directivas en las líneas posteriores del bloque, # # permitiendo que los valores de las directivas globales en el archivo # # sshd_config se omitan en el caso de que criterios para la directiva # # Match. Se considera bloque todas las líneas que vienen después de la línea # # con el criterio (Coincidencia - líneas) hasta la siguiente línea coincidente # # o hasta el final del archivo. El argumento de la directiva Match es uno o # # múltiples pares de entradas de criterios. Posibles tipos de entradas: # # Usuario # # Grupo # # Host # # Dirección # # Las entradas pueden contener valores únicos # # (por ejemplo Usuario=usuario) o múltiples valores # # separados por comas (Usuario=usuario1 ,usuario2). También se pueden utilizar las expresiones regulares descritas en la sección # # PATRONES del archivo ssh_config # #. Las entradas en los criterios # # Dirección pueden contener direcciones en notación CIDR # # (Dirección/Longitud de máscara, por ejemplo, “192.0.2.0/24” o # # “3ffe:ffff::/32”). Vale la pena señalar que la # # longitud de la máscara proporcionada debe coincidir con la dirección, y demasiado # # larga/corta para la dirección no funcionará. # # Match solo puede usar # # un conjunto específico de directivas como directivas: # # AllowTcpForwarding # # Banner # # ChrootDirectory # # ForceCommand # # GatewayPorts # # GSSAPIAuthentication # # HostbasedAuthentication # # KbdInteractiveAuthentication # # KerberosAuthentication # # MaxAuthTries # # MaxSessions # # PasswordAuthentication # # PermitOpen # # PermitRootLogin # # RhostsRSAAuthentication # # RSAAuthentication # # X11DisplayOffset # # X11Forwarding # # X11UseLocalHost #
Puede copiar el texto anterior en su propio sshd_config y usarlo más tarde para la configuración.
En sí mismo, un servidor SSH configurado incorrectamente es una gran vulnerabilidad en la seguridad del sistema, ya que un posible atacante tiene la oportunidad de obtener acceso casi ilimitado al sistema. Además, sshd tiene muchas opciones útiles adicionales que es recomendable habilitar para mejorar la usabilidad y la seguridad.
Puerto, dirección de escucha y familia de direcciones
Estos tres parámetros determinan en qué puertos y direcciones su servidor escuchará las conexiones entrantes. En primer lugar, tiene sentido, si es posible, limitar la familia de direcciones que se procesan a aquellas que realmente se utilizan, es decir, si sólo utiliza IPv4, desactive IPv6 y viceversa. Esto se puede hacer usando el parámetro AddressFamily, por ejemplo (para permitir IPv4 y denegar IPv6):
DirecciónFamilia inet
En segundo lugar, es recomendable cambiar el puerto estándar (22) en el que escucha sshd. Esto se debe al hecho de que numerosos escáneres de red intentan constantemente conectarse al puerto 22 y al menos obtener acceso mediante la fuerza bruta de inicios de sesión/contraseñas desde su base de datos. Incluso si tiene la autenticación de contraseña deshabilitada, estos intentos obstruyen en gran medida los registros y (en grandes cantidades) pueden afectar negativamente la velocidad del servidor ssh. Si por alguna razón no desea cambiar el puerto estándar, puede utilizar varias utilidades externas para combatir las fuerzas brutas, por ejemplo, fail2ban, e integradas, como MaxStartups.
Puede configurar el puerto como un valor absoluto para todas las interfaces usando la directiva Port o como un valor específico para cada interfaz usando la directiva ListenAddress. Por ejemplo:
Puerto 2002
Dirección de escucha 192.168.0.1:2003 Dirección de escucha 192.168.1.1:2004
Denegar el acceso remoto al superusuario
De forma predeterminada, el acceso de root está prohibido mediante contraseña (es posible mediante clave); la opción PermitRootLogin está configurada en without-password. Pero, dado que de forma predeterminada en Ubuntu el usuario agregado durante la instalación del sistema tiene la capacidad de resolver todas las tareas administrativas a través de sudo, crear la capacidad de acceso root al sistema a través de ssh parece irrazonable (incluso con autenticación de clave). Se recomienda apagarlo por completo. esta opción, o úsela solo en modo de solo comandos forzados. Puede desactivar el acceso root de esta manera:
PermitRootLogin no
Autenticación de contraseña
La autenticación de contraseña, que está permitida de forma predeterminada, es prácticamente el método de autorización más primitivo en sshd. Por un lado, esto simplifica la configuración y conexión de nuevos usuarios (el usuario sólo necesita saber su nombre de usuario/contraseña del sistema); por otro lado, la contraseña siempre se puede adivinar y los usuarios a menudo se olvidan de crear contraseñas complejas y largas. . Los robots especiales escanean constantemente los servidores ssh accesibles desde Internet e intentan iniciar sesión en ellos mediante la fuerza bruta de inicios de sesión/contraseñas desde su base de datos. Se recomienda encarecidamente no utilizar la autenticación de contraseña. Puedes desactivarlo así:
ContraseñaAutenticación no
Si por alguna razón aún desea utilizar la autenticación de contraseña, asegúrese de que nadie pueda iniciar sesión con una contraseña en blanco. Para hacer esto, configure la directiva PermitEmptyPasswords:
Permitir contraseñas vacías no
Protocolos SSH1 y SSH2
Como ya se mencionó, sshd puede funcionar con los protocolos SSH1 y SSH2. Sin embargo, se desaconseja el uso de SSH1 inseguro. Puede forzar que sshd funcione solo con el protocolo SSH2 de esta manera:
Autenticación basada en claves SSH2 RSA
El método de autorización más preferido es la autenticación basada en claves SSH2 RSA. Con este método, el usuario genera un par de claves de su lado, de las cuales una clave es secreta y la otra es pública. La clave pública se copia en el servidor y se utiliza para verificar la identidad del usuario. Para obtener más información sobre cómo crear un par de claves y cómo colocarlas en el servidor, consulte la descripción del cliente SSH. Puede habilitar la autenticación de clave pública de esta manera:
Autenticación Pubkey sí
El servidor debe saber dónde buscar la clave pública del usuario. Para ello se utiliza un archivo especial autorizado_keys. Su sintaxis podría ser la siguiente:
# Los comentarios se escriben solo en una nueva línea # apariencia general de las entradas en el archivo de claves_autorizadas # [opciones] tipo_clave (ssh-rsa o ssh-dss) cadena_muy_larga_incomprensible para el hombre común [login@host] ssh-rsa AAAAB3Nza...LiPk == [correo electrónico protegido] from="*.ventas.ejemplo.net,!pc.ventas.ejemplo.net" ssh-rsa AAAAB2...19Q== [correo electrónico protegido] comando="dump /home",no-pty,no-port-forwarding ssh-dss AAAAC3...51R== ejemplo.net permitopen="192.0.2.1:80",permitopen="192.0.2.2:25" ssh -dss AAAAB5...21S== túnel="0",command="sh /etc/netstart tun0" ssh-rsa AAAA...== [correo electrónico protegido]
Puede especificar un archivo compartido con claves o un archivo para cada usuario. El último método es más conveniente y seguro porque, en primer lugar, puede especificar diferentes combinaciones de claves para cada usuario y, en segundo lugar, limitar el acceso a la clave pública del usuario. Puede especificar un archivo con claves utilizando la directiva AuthorizedKeysFile:
Archivo de claves autorizadas %h/.ssh/my_keys
para el usuario del esquema - archivo
o
Archivo de claves autorizadas /etc/ssh/claves_autorizadas
para un esquema con un archivo compartido. De forma predeterminada, el cliente SSH busca claves en el archivo ~/.ssh/authorized_keys.
Más sobre seguridad
Ajustes adicionales
Usuarios y grupos.
Si tiene muchos usuarios "viviendo" en su servidor y desea permitir el acceso a través de ssh sólo a algunos de ellos, puede utilizar las directivas DenyUsers, AllowUsers, DenyGroups y AllowGroups. Para obtener más información sobre estas directivas, consulte los comentarios en el ejemplo sshd_config.
Opciones de estado de conexión
De forma predeterminada, entre los métodos para determinar el estado de la conexión, solo está habilitado el método de verificación de la conexión TCP: TCPKeepAlive; sin embargo, sshd puede determinar los estados de la conexión de maneras más convenientes y seguras. Consulte la sección correspondiente en el ejemplo sshd_config para obtener más detalles.
Actuación. MaxStartups
Reenvío de puertos
Redirección X11
En el servidor, en el archivo /etc/ssh/sshd_config, establezca el parámetro (habilitado de forma predeterminada):
AdelanteX11 si
En el cliente, configure los parámetros en el archivo /etc/ssh/ssh_config (deshabilitado de forma predeterminada):
ForwardAgent sí ForwardX11 sí
Puede ejecutarlo en el cliente de esta manera: ssh yurauname@serverip firefox. O primero vaya a ssh yurauname@serverip y luego ejecute, por ejemplo, sudo synaptic.
SFTP
sshd tiene un servidor SFTP integrado de forma predeterminada. SFTP (Protocolo de transferencia de archivos SSH): protocolo SSH para transferir archivos. Está diseñado para copiar y realizar otras operaciones de archivos a través de una conexión confiable y segura. Como protocolo base para la conexión se utiliza normalmente el protocolo SSH2. Para habilitar la compatibilidad con SFTP, agregue la línea a sshd_config
Subsistema sftp /usr/lib/openssh/sftp-server
De forma predeterminada, la compatibilidad con SFTP está habilitada.
Usando criterios. directiva de partido
Configurar un cliente SSH
Iniciar sesión con una clave se considera lo más seguro y, en la mayoría de los casos, esta función está habilitada en el lado del servidor, por lo que no se requieren derechos de superusuario para usarla. En la máquina cliente generamos una clave:
ssh-keygen -t rsaSe nos solicita que ingresemos una contraseña para proteger el archivo clave (resulta útil si el archivo cae en las manos equivocadas). Si vamos a ejecutar scripts vía SSH, entonces lo dejamos vacío. Transferimos la clave pública al servidor con el comando
Ssh-copy-id -i ~/ .ssh/ id_rsa.pub usuario@ servidor
Eso es todo, puedes entrar.
Cuando ssh se ejecuta en un puerto no estándar:
Ssh-copy-id -i ~/ .ssh/ id_rsa.pub "-p puerto usuario@servidor"
Si se produce un error: Puerto incorrecto "umask 077; test -d .ssh || mkdir .ssh ; cat >> .ssh/authorized_keys"
intenta poner los parámetros entre comillas:
id-copia-ssh "-i /home/user/.ssh/id_rsa.pub "-p puerto usuario@servidor""
Es conveniente utilizar la utilidad de pantalla cuando se conecta a un sistema remoto.
Configurar un directorio ssh remoto en Nautilus
Montar un directorio remoto usando sshfs
Montar un directorio remoto en un directorio local
usuario sshfs@ hostingserver.ru:/ home/ userdir ~/ sshfsdirDesmontaje
Montaje del fusor -u ~/ sshsfdir
Alias SSH
Cuando se utilizan varios servidores con diferentes parámetros de acceso (puerto no estándar, nombre de host largo, inicio de sesión distinto del local, etc.), a veces resulta tedioso volver a introducir todas las configuraciones de conexión cada vez. Para facilitar esto, puede utilizar alias.
Las configuraciones se almacenan en ~/.ssh/config para un solo usuario y en /etc/ssh/ssh_config globalmente para todos los usuarios.
Configuración de ejemplo. Se pueden describir varios servidores. Más detalles en hombre ssh_config(no confundir con sshd_config)
Host AliasName # Nombre de host arbitrario HostName 1.2.3.4 # Puede especificar tanto IP como nombre de host (si se está ejecutando DNS) Usuario YourUserName # Si el usuario no coincide con el usuario local Puerto YourSSHPort # Si es un puerto no estándar
Después de esto puedes conectarte al servidor con el comando
ssh Nombre de aliasagente ssh
Diagnóstico de problemas de conexión
Análisis del registro de conexión:
Análisis de archivos de configuración de clientes y servidores.
La ubicación de los archivos de configuración se puede encontrar en
hombre ssh hombre sshd
Usando tarjetas inteligentes
1. La creación de un certificado y la exportación de una clave pública, así como la parte del cliente en Windows + Putty SC, se describen en el sitio web: http://habrahabr.ru/post/88540/ El complemento Key Manager descrito allí es disponible sólo en versiones anteriores de Firefox. Probado en la versión 3.5 para Windows. Enlace directo al complemento: https://addons.mozilla.org/ru/firefox/addon/key-manager/
2. Preparando el servidor. Debe asegurarse de que su configuración sshd permita la autenticación mediante claves públicas. Para hacer esto, debe especificar el valor del parámetro "PubkeyAuthentication" en "sí" en el archivo "sshd_config". Luego agregamos nuestra clave pública obtenida anteriormente (en una línea) al archivo “~/.ssh/authorized_keys”. Tenga en cuenta que el archivo ".ssh/authorized_keys" se encuentra en el directorio de inicio del usuario que luego iniciará sesión utilizando la clave pública.
3. Parte del cliente en Linux. Deberá reconstruir el paquete OpenSSH sin parámetros. Solo se recomienda especificar prefijos de directorio, por ejemplo –prefix=/usr. También debes tener en cuenta que los archivos de configuración estarán en /usr/etc. Antes de comenzar, necesita los siguientes paquetes: opensc-lite-devel, zlib-devel, openssl-devel. Instale el controlador de la tarjeta inteligente. Para mayor comodidad, en la configuración ssh_config (que no debe confundirse con sshd_config), especifique la ruta a la biblioteca pkcs: PKCS11Provider=<путь к библиотеке>
4. En el cliente, ejecute ssh user@host. Si la tarjeta inteligente (token) está conectada, se le solicitará una contraseña y se iniciará sesión en la sesión SSH.
Posibles problemas durante el uso.
La combinación de teclas habitual Ctrl + S, utilizada en muchos editores para guardar correcciones, cuando se trabaja en una terminal con un servidor ssh, conducirá a la ejecución del comando XOFF, que superficialmente se parece a una congelación de sesión. Sin embargo, no lo es. El servidor continúa aceptando caracteres y comandos de entrada, pero no los muestra en la pantalla. Para salir de esta situación, simplemente use la combinación Ctrl + Q, volviendo así a activar el modo XON.
Enlaces
Es decir, el usuario1 puede registrarse tanto para él mismo (en el archivo /home/user1/.ssh/keys) como para otro usuario, lo que le permitirá iniciar sesión desde su computadora tanto "bajo él mismo" como bajo "otro".
SSH (Secure Shell) es un protocolo de red diseñado para la administración remota de servidores y la transferencia de datos a través de conexiones cifradas TCP. La mayoría de los servicios de hosting, incluso los virtuales, hoy en día brindan acceso tanto a través de FTP como de SSH. En mi opinión, esto es genial, SSH es mucho más conveniente y seguro de usar.
Configurando SSH
La configuración se realizará para un servidor dedicado, VDS, VPS en Debian, Ubuntu. El archivo de configuración se encuentra aquí: /etc/ssh/sshd_config.
Si tienes hosting habitual, todo debe estar configurado como debe, ve a la sección.
De forma predeterminada, el demonio SSHD (que es en lo que estamos realizando cambios) no necesita ninguna configuración y funciona bien. Sólo haremos un par de pequeños cambios para limitar el acceso de personas no deseadas al servidor.
Como resultado de realizar cambios incorrectos en el archivo de configuración, es posible que pierda el acceso al servidor a través de ssh, así que asegúrese de tener opciones alternativas para acceder a él, por ejemplo, utilizando el panel de control de ISPManager.
Cómo restringir el acceso SSH
Todos los cambios se realizan en /etc/ssh/sshd_config
Para que los cambios surtan efecto, debes
Cambiar puerto
Puerto 9724Ahora, al realizar la autorización, debe especificar 9724 en lugar del puerto 22 estándar.
El método es muy simple y eficaz contra la mayoría de los robots piratas informáticos simples que atacan puertos estándar. Lo principal aquí es no crear conflictos con otros servicios y elegir un número que obviamente no se utiliza.
Deshabilitar la comunicación usando el protocolo antiguo.
Aquí definimos que la comunicación solo es posible usando el protocolo v2
Si no has iniciado sesión raíz, antes de todos los comandos de la consola necesitas agregar sudo - significa Usuario sustituto y DO- reemplazar al usuario y hacerlo (debajo de él). Por ejemplo, te permite ejecutar comandos como superusuario. raíz.
Reducir el número de intentos de autorización.
MaxAuthIntenta 2Número de intentos de contraseña. El valor predeterminado es 6. Si la búsqueda falla, la sesión de comunicación finaliza.
Reducir el tiempo de espera de autorización
Iniciar sesiónGraceTime 30sDe forma predeterminada, una sesión de autorización puede durar 120 segundos. Pasado este tiempo finaliza. 2 minutos para la autorización es excesivo; todo este tiempo el servidor mantiene la conexión abierta, lo cual es muy irracional. Medio minuto es suficiente.
Cerrar acceso IP
Antes de configurar restricciones de IP, asegúrese de que en caso de un error en la configuración y la posterior prohibición de su propia IP, tendrá una forma alternativa de recuperar el acceso al servidor.
Si solo necesitas acceso, la forma más sencilla y confiable es bloquear el acceso desde cualquier lugar excepto tu IP o, si es dinámica, entonces el rango de IP.
- Abra /etc/hosts.allow y agregue SSHD allí: 192.168.1.1
donde 192.168.1.1 es su IP. Si tienes una IP dinámica, define una IP con una máscara de subred y escribe tu subred en lugar de la IP, por ejemplo:
SSHD: 192.168.0.0/16
- Abra /etc/hosts.deny y agregue allí: SSHD: TODOS
Otra forma de restringir el acceso vía IP
Puede utilizar la siguiente directiva:
PermitirUsuarios = *@1.2.3.4
Aquí solo permitimos el acceso para IP 1.2.3.4
Autorización SSH por claves
Será mucho más seguro, conveniente y correcto configurar la autorización ssh sin contraseña. Para ello se utilizará la autorización de clave.
Así que aquí están las instrucciones.
Compraste tu primer VPS, o tal vez incluso un servidor de inmediato. Seguramente tienes un panel web para administrarlo. Pero los administradores duros siempre pasan por la consola 😉 Por lo tanto, debemos aprender a hacer esto. En esta lección, instalaremos el programa PuTTY, nos conectaremos al servidor mediante el protocolo SSH y aprenderemos cómo determinar el espacio ocupado y libre en el servidor.
Programa Putty para conectarse a un servidor mediante protocolo SSH
Descargue Putty del sitio putty.org. Para mí, descargué la versión "Para Windows en Intel x86 - PuTTY: putty.exe"
Desempaquete el archivo y ejecute el programa.
Así es como se ve la ventana del programa después del inicio. Ya ingresé la dirección IP de mi servidor en el campo "Nombre de host (o dirección IP)":
Ingrese el dominio o dirección IP de su servidor y haga clic en el botón "Abrir". Se abre una ventana del símbolo del sistema. Nos pide un usuario y contraseña. Primero, ingrese su nombre de usuario, luego su contraseña. Atención, al ingresar la contraseña, los caracteres no se imprimen en la pantalla, incluso los asteriscos *** no se imprimen. Por lo tanto, ingresamos la contraseña como a ciegas. Ingrese y presione Entrar. Si la contraseña se ingresó correctamente, iniciará sesión en la consola de administración del servidor. Se muestra una línea con la hora del último inicio de sesión e información sobre el sistema operativo.
Comandos en la consola
persona con discapacidad
df
El comando df muestra la cantidad de espacio libre y utilizado en el servidor, en todos los sistemas de archivos montados.
du
El comando du muestra cuánto espacio ocupa una carpeta o archivo.
Comando de ejemplo:
Du -h /casa/
Este comando mostrará cuánto espacio ocupa el directorio /home/.
Eso es todo. Se acabó el primer contacto con la conexión a un servidor a través de SSH y el programa PuTTY. Con esta información, puede ir al servidor y ver cuánto espacio ocupan los datos en él.
