Archivado con la Etiqueta: Linux

Acceder por SSH a un servidor o equipo remoto sin introducir ni usuario ni contraseña

Cuando nos conectamos a un servidor para poder administrarlo lo solemos hacer por SSH (espero que no uses telnet u otros métodos no seguros ;) ). Tras instalarlo, para acceder usamos un usuario y una contraseña y empezamos a administrarlo.

Una de las implementaciones más habituales es OpenSSH (OpenBSD Secure Shell), un proyecto que nació en el año 1999 y cuya finalidad, tal y como indican en su web es:

OpenSSH is a FREE version of the SSH connectivity tools that technical users of the Internet rely on. Users of telnet, rlogin, and ftp may not realize that their password is transmitted across the Internet unencrypted, but it is. OpenSSH encrypts all traffic (including passwords) to effectively eliminate eavesdropping, connection hijacking, and other attacks. Additionally, OpenSSH provides secure tunneling capabilities and several authentication methods, and supports all SSH protocol versions.

Esta implementación está presente, tanto la parte de cliente como la de servidor, en la mayoría de máquinas no Windows: BSD (OpenBSD, FreeBSD, NetBSD,…), Cygwin, Mac OS X a partir de la versión 10.1, IBM AIX, Sun Solaris, máquinas Cisco, Novell NetWare, máquinas Dell, HP-UX, máquinas Juniper y todos los Linux.

La suite OpenSSH reemplaza rlogin y telnet con ssh, rcp con scp y ftp con sftp. También incluye la implementación del servidor, sshd, y otras utilidades, tales como ssh-add, ssh-agent, ssh-keysign, ssh-keyscan, ssh-keygen y sftp-server.

Como podemos ver es una suite de comunicaciones segura, muy completa y de uso muy extendido.

En este artículo explico como configurar un equipo con alguno de los sistemas operativos en los que podemos instalar OpenSSH y con el cuál queremos acceder desde una consola a un servidor mediante SSH sin tener que introducir contraseñas.

Para esto utilizaremos autentificación de clave pública; es decir, tenemos una clave pública y otra privada que usaremos para autentificarnos ante otros sistemas, como en este caso ante un servidor remoto.

Lo primero que hacemos en el equipo local es generar el conjunto de claves pública y privada. Para ello usamos el comando ssh-keygen, que permite la creación de claves de autentificación. Nos pedirá la ruta y el nombre del archivo que le vamos a dar a la clave privada (a la pública le añade la extensión .pub) y una contraseña de acceso para cuando queramos acceder a la clave privada. Si estáis en un equipo local controlado por vosotros podéis dejarla vacía.

ssh-keygen

Generating public/private rsa key pair.
Enter file in which to save the key (/home/usuario/.ssh/id_rsa): /home/usuario/.ssh/usuario_local
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/usuario/.ssh/usuario_local.
Your public key has been saved in /home/usuario/.ssh/usuario_local.pub.
The key fingerprint is:
7f:6d:24:8b:d5:9c:8e:03:13:6c:dc:09:f2:c7:f2:ec usuario@equipo
The key’s randomart image is:
+–[ RSA 2048]—-+
| ..oo . |
| =..o |
| = o |
| * o . |
| o S . = . |
| + + + + |
| E + o o |
| . . . |
| |
+—————–+

Acabamos de generar 2 claves de tipo RSA de 2048 bits:

  • /home/usuario/.ssh/usuario_local. Es la clave privada, que debemos de mantener segura en nuestro equipo.
  • /home/usuario/.ssh/usuario_local.pub. Es la clave pública, que llevaremos al servidor.

Copiamos la clave pública al servidor. Para ello ejecutamos en nuestro equipo el comando scp, mediante el cual copiamos la clave pública al servidor remoto.

scp -P 22 ~/.ssh/usuario_local.pub usuario_remoto@miequiporemoto.com:/home/usuario_remoto/.ssh/usuario_local.pub

The authenticity of host ‘[miequiporemoto.com]:22 ([11.22.33.44]:22)’ can’t be established.
ECDSA key fingerprint is 75:c5:23:ad:5a:f1:22:3b:f1:ef:a2:5e:f8:8a:2d:ab.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added ‘[miequiporemoto.com]:22,[11.22.33.44]:22′ (ECDSA) to the list of known hosts.
usuario_remoto@miequiporemoto.com’s password:
usuario_local.pub 100% 398 0.4KB/s 00:00

En el equipo remoto añadimos la clave pública al archivo “authorized_keys” del usuario remoto. Para ello ejecutamos en el equipo remoto

echo ‘cat ~/.ssh/usuario_local.pub >> ~/.ssh/authorized_keys

Solo nos queda crear un shortcode en el archivo del equipo local ~/.ssh/config para poder acceder de una forma rápida al servidor. Para ello anadimos en este archivo las siguientes líneas:

Host miservidor
Hostname miequiporemoto.com
Port 22
User usuario_remoto
IdentityFile ~/.ssh/usuario_local

Y para acceder al equipo remoto desde el equipo local solo tenemos que ejecutar

ssh miservidor

Más información:

:wq

SSH. Evitar cortes continuos en una conexión SSH

A veces cuando estoy trabajando por consola a través de SSH en un equipo remoto, tras un tiempo de inactividad, la conexión se corta.

Para solucionar este problema sin tener que ser root en el equipo que realiza la conexión, simplemente hay que editar el archivo ~/.ssh/config e introducir la siguiente configuración

Host *
ServerAliveInterval 60
ServerAliveCountMax 3

Con esta configuración estamos configurando todas las conexiones SSH para que:

  • ServerAliveInterval 60: envíe un paquete vacío al servidor cada 60 segundos para mantener la conexión viva.
  • ServerAliveCountMax 3: número de mensajes vacíos que se enviarán al servidor sin que tengamos que recibir respuesta del servidor. Si se alcanza este tope sin recibir respuesta del servidor se corta la conexión.

Más info:

Taller de introducción a Git

En la sección de documentación os dejo la presentación y el guion creados para el taller sobre Git, titulado “Taller de introducción a Git” que di el 09/10/2014 en las XIII Xornadas Libres organizadas por el Grupo de Programadores y Usuarios de Linux de la Facultad de Informática de la Universidad de A Coruña. Espero que os sea útil.

Recordar que tenéis disponibles los libros “Git. Fundamentos” y “Git. Servidores privados” de forma gratuita.

SSH. Ver los intentos de acceso o accesos correctos en Debian

Cuando configuramos un acceso por SSH a un servidor lo primero que deberíamos de hacer, además de bloquear el acceso al usuario root, es permitir el acceso solo por pares de claves (pública/privada).

De todas formas podemos ver los intentos de acceso o accesos correctos que hemos tenido.

Para ver los intentos incorrectos usaremos el siguiente comando:

sudo cat /var/log/auth.log | grep ‘sshd.*Invalid’

Para ver los intentos correctos usaremos el siguiente comando:

cat /var/log/auth.log | grep ‘sshd.*opened’

Y si lo queremos ver en tiempo real, para depurar, para ver un ataque en tiempo real,… añadimos a esto el comando tail:

sudo tail -f /var/log/auth.log | grep ‘sshd.*Invalid’

o

sudo tail -f /var/log/auth.log | grep ‘sshd.*opened’

Linux y sus distribuciones a lo largo del tiempo

Uno de los mayores problemas que se le achacan a Linux es la gran cantidad de distribuciones existentes; para otros esto es una fortaleza, ya que fruto de la disponibilidad del código, si algo no te gusta o necesitas algo muy específico, siempre puedes hacer un fork y crear tu propia distribución (si sables, claro, que no es tan sencillo).

Sea como fuere, para ilustrar la diversidad de Linux, la gente del blog Futurism mantiene un gráfico, con 480 distros, en el que a día de hoy aparecen 3 ramas base principales:

  • Debian, la más usada, con mucho. Dentro de esta resulta curioso el número de distros creadas a partir de Knoppix y de Ubuntu.
  • Slackware.
  • Red Hat. Aquí destaca Fedora Core por el número de distros creadas desde ella.

El gráfico está disponible en: