Networking Tips: linux

Mostrando entradas con la etiqueta linux. Mostrar todas las entradas

jueves, 4 de julio de 2019

Por fin, RRL en BIND por defecto - con ejemplo

Historia

Al parecer este es un post que tuve que haber hecho hace mucho, sin embargo hoy recién es que lo veo funcionando correctamente

Introducción

Si el lector se parece un poco a mí, quizás sea de esas personas que tiene MUCHOS años esperando el soporte de Response Rate Limiting en Bind9. Buenas noticias!, ya existe !.

¿Qué es RRL en DNS?

RRL se refiere a Response Rate Limit. De una manera resumida es una técnica para minimizar ataques de amplificación que son muy comunes en el mundo de DNS. Hoy en día es muy recomendado en servidores autoritativos pero puede servir en recursivos.

Situación

Deseo instalar Bind9 vía apt (apt-get) y tener soporte de RRL (Response Rate Limiting). Algo que me extraña es que en teoría debería tener soporte por defecto luego del 9.10, sin embargo verán que este ejemplo está en 9.9.5)

Pasos:

El día de hoy, con Ubuntu 14.04 (si, bastante viejo) hice un upgrade de Bind9, probé RRL y todo anduvo perfecto.

1) Actualizar bind9
apt-get –only-upgrade install bind9

2) Chequeo la versión:
root@my:~/SCRIPTS# apt-cache policy bind9
bind9:
Installed: 1:9.9.5.dfsg-3ubuntu0.19

3) Configurar RRL en bind9. Un sencillo ejemplo:

rate-limit {
responses-per-second 1;
};

(favor notar que puse "1".., solo para probar que el feature realmente sirva)

4) Reiniciar bind vía rndc o el servicio (service bin9 restart)

#service bind9 restart

Comprobar

Debido a que dejamos una sola consulta por segundo, es tan sencillo como ir a otro equipo, tener varios terminales abiertos y hacer muchos dig simultáneamente de algún dominio/zona autorizada. Si todo sale bien, en el log verás algo como:

Jul 4 11:47:55 my named[8317]: limit responses to 10.112.225.0/24 for exp.example.com IN A (fff7f64c)

Jul 4 11:47:55 my named[8317]: client 10.112.225.51#11257 (exp.example.com): rate limit slip response to 10.112.225.0/24 for exp.example.com IN A (fff7f64c)

Jul 4 11:47:56 my named[8317]: client 10.112.225.51#7921 (exp.example.com): rate limit drop response to 10.112.225.0/24 for exp.example.com IN A (fff7f64c)

Mas info:
https://kb.isc.org/docs/aa-00994
https://whatis.techtarget.com/definition/DNS-amplification-attack

martes, 30 de abril de 2019

Como verificar si un sitio Web se encuentra bloqueado

Hola,
Si en google por ejemplo buscamos "como revisar si un sitio web esta bloqueado" será difícil conseguir información de como revisar nosotros mismos, los resultados serán principalmente sitios Web que pueden abrir la página Web por tí, mostrarte desde otros sitio si puede conectarse, algún plugin que puedas instalar. En estás páginas se puede revisar si un sitio está arriba o no: https://www.blocked.org.uk/check y https://downforeveryoneorjustme.com/

NOTA: Este post es básicamente como podemos revisar nosotros mismos un bloqueo. Estamos hablando de bloqueos por parte de un ISP/país, no de bloqueos en el firewall en una empresa o compañía. Se aceptan sugerencias y quejas.., comentarios están abiertos al final del documento

Introducción:
Como algunos de ustedes saben, existen muchas manera de bloquear sitios Web, principalmente los bloqueos ocurren de 4 maneras:
1) DNS
2) Routing
3) Capa 4 (bloqueo de puertos TCP/UDP a ciertos destinos)
4) Capa 7 (bloqueo de por ejemplo la URL/dominio)

Ahora bien, antes de continuar quiero dejar claro mi posición en cuanto a los bloqueos en Internet: ME PARECEN MUY MALA IDEA y no trae nada bueno al país/ISP..., y en el supuesto que traíga una cosa buena, trae 10 cosas malas. Tengo algunas cosas plasmadas en este post: https://blog.acostasite.com/2014/10/la-mala-idea-de-bloquear-internet.html

Pasos para revisar un bloqueo de un sitio Web:
Ahora bien, en el supuesto que queramos saber si algún sitio se encuentra bloqueado, podemos seguir estos pasos (preferiblemente Linux y/o MAC):

1) Revisar si el bloqueo es por DNS. ¿Cómo lo hacemos?
Podemos usar dos herramientas de resolución DNS. Para este ejemplo utilizaremos dig y/o nslookup.

.- Utilizando dig

MacBook-Pro-2:tmp$ dig +short www.example.com

172.XX.YY.39

.- Utilizando nslookup

MacBook-Pro-2:tmp$ nslookup www.example.com

Server: 8.8.8.8

Address: 8.8.8.8#53

Non-authoritative answer:

Name: www.example.com

Address: 172.XX.YY.39

¿Qué hay que revisar de la salida?
Básicamente con el comando, le pedimos a dig que muestre de manera resumida, que direcciones IP resuelve www.example.com. En este sentido 172.XX.YY.39 será el IP al cual nuestra computadora se va a conectar. Lo importante aquí es identificar si 172.XX.YY.39 corresponde al IP destino que nos queremos conectar (si, ciertamente pueden resolver direcciones diferentes y eso, pero si sabes eso no necesitas leer este documento :) !! ) Muchas veces algunos ISPs cambian la resolución de un dominio y no verías el IP correcto sino otra al cual es imposible conectarse (por ejemplo, 127.0.0.1)

2) Routing

Para revisar routing principalmente utilizaremos traceroute (tracert en Windows)

La idea es en lineas generales ver si podemos alcanzar el destino desde nuestra computadora:

Utilizando traceroute:

MacBook-Pro-2:tmp$ traceroute -n 8.8.8.8 (sustituye 8.8.8.8 por el dominio o el IP obtenido en el paso previo)

traceroute to 8.8.8.8 (8.8.8.8), 64 hops max, 52 byte packets

1 192.168.1.1 1.724 ms 1.030 ms 1.376 ms

2 190.XX.XX.1 28.969 ms * 35.939 ms

3 172.YY.13.33 27.988 ms 27.379 ms 29.267 ms

4 * * *

5 10.XX.1.105 29.229 ms 28.628 ms 28.303 ms

6 10.XX.1.1 38.332 ms 26.855 ms 28.605 ms

7 200.XX.XX.177 61.560 ms 62.466 ms 68.661 ms

8 72.NN.NN.84 62.411 ms 62.523 ms 62.188 ms

9 108.170.253.17 62.537 ms 63.011 ms 63.182 ms

10 108.170.226.13 63.588 ms 65.335 ms 62.301 ms

11 8.8.8.8 62.329 ms 63.023 ms 62.176 ms

¿Qué hay que revisar de la salida?

Como se puede ver en el traceroute de arriba, se llegó satisfactoriamente al destino.
En el caso de ver algún "!" seguido por una letra, es mala noticia. Por ejemplo ver esto en el traceroute significa que hay algo mal, quizás el ISP bloqueó las direcciones IP destino de alguna manera.

Errores comunes (tomados de la página del manual de traceroute):

!H, !N, or !P (host, network or protocol unreachable)

!S (source route failed)
!U or !W (destination network/host unknown)
!I (source host is isolated)
!A (communication with destination network administratively prohibited)
!Z (communication with destination host administratively prohibited)
!Q (for this ToS the destination network is unreachable),
!T (for this ToS the destination host is unreachable),
!X (communication administratively prohibited),
!V (host precedence violation),
!C (precedence cutoff in effect), or
! (ICMP unreachable code ).

Extra:
Otra herramienta que recomiendo para revisar este punto es MTR (My traceroute) ; https://es.wikipedia.org/wiki/MTR_(software).., es una combinación de ping y trace. MUY buena.

3) Capa 4 (bloqueo de puertos a ciertos destinos)
Para revisar bloqueos de capa 4, principalmente la idea es revisar conectividad a nivel de puertos (TCP) desde tu computadora al destino.
La herramienta más sencilla para revisar esto es telnet, la intención al ejecutarlo es chequear que efectivamente "se conectó" nuestra computadora al destino.

Utilizando telnet:
Ejemplo 1: (conecta¡ándose al puerto http)

MacBook-Pro-2:tmp$ telnet www.example.com 80 -- 80 quiere decir el puerto destino

Trying 199.NN.NN.100...

Connected to www.example.com. --- esto es lo que hay que revisar

Escape character is '^]'.

Ejemplo 1: (conectándose al puerto https)

MacBook-Pro-2:tmp$ telnet www.example.com 443 -- 443 quiere decir el puerto destino

Trying 199.NN.NN.100...

Connected to www.example.com. --- esto es lo que hay que revisar

Escape character is '^]'.

Cuando el destino se encuentra bloqueado a nivel de 4 veríamos algo así:

MacBook-Pro-2:tmp$ telnet www.example.com 80

Trying 199.XX.XX.100...

telnet: connect to address 199.XX.NN.100: Operation timed out

telnet: Unable to connect to remote host

Depende el tipo de bloqueo, el telnet puede ser rechazado muy rápido (reject *), quizás el telnet solo dure mucho hasta que haga timeout.

* tu computadora recibe un icmp error desde el dispositivo que se encuentra bloqueando

4) Capa 7 (bloqueo de por ejemplo la URL/dominio)

Revisar capa 7 viene a ser cuando el ISP es capaz de identificar el contenido de paquetes HTTP y chequear por el texto del dominio bloqueado dentro de él, es decir: el ISP quiere bloquear www.example.com, algunos dispositivos dentro del ISP son capaces de revisar a nivel de capa de aplicación (capa 7) el fqdn www.example.com, y allí tomar la decisión: bloquear o no.

Para lo anterior, recomiendo utilizar curl o wget. Dejaré solo el ejemplo con curl:

Utilizando curl (en hacia un destino bloqueado)

MacBook-Pro-2:tmp$ curl -v https://www.example.com

* Rebuilt URL to: https://www. example.com/

* Trying 172.NN.NN.39...

* TCP_NODELAY set

* Connected to www.example.com (172.NN.NN.39) port 443 (#0)

* ALPN, offering h2

* ALPN, offering http/1.1

* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH

* successfully set certificate verify locations:

* CAfile: /etc/ssl/cert.pem

CApath: none

* TLSv1.2 (OUT), TLS handshake, Client hello (1):

* LibreSSL SSL_connect: SSL_ERROR_SYSCALL in connection to www.example.com:443

* stopped the pause stream!

* Closing connection 0

curl: (35) LibreSSL SSL_connect: SSL_ERROR_SYSCALL in connection to www.example.com:443

¿Qué hay que revisar de la salida?

No hay que asustarse con la salida, aquí hay revisar que la negociación SSL/TLS no pudo completarse, esto lo podemos apreciar al conseguir que el texto *ERROR* se ve en la salida.

Nota: Cuando la salida es satisfactoria, veremos código html

Conclusión:
Existen MUCHAS manera de bloquear acceso a sitios en Internet, incluso en algunas oportunidades puede usarse una combinación de varias maneras para lograr un bloqueo.

Se que el post puede ser mucho más amplio y faltaron cosas por cubrir, sin embargo a su vez espero que él mismo sea visto como una introducción.

El bloqueo de sitios Web en Internet no trae beneficios.

martes, 2 de octubre de 2018

Aportando un grano de arena en la seguridad de la red, un caso de éxito

Introducción

Seguramente algunos de ustedes conocen el proyecto IPv6 DNS Open Resolvers [1] que lleva adelante LACNIC, un trabajo conjunto de WARP [2] y de I+D donde identificamos servidores abiertos DNS con direccionamiento IPv6.
Tradicionalmente no ofrecemos soporte de ningún tipo para la infraestructura de nuestros asociados, esto quiere decir que LACNIC “no toca” los equipos (servidores, dispositivos de red). Sin embargo siempre hemos extendido una mano de apoyo para colaborar en todo lo que podamos.

Contexto

Luego de haber identificado una dirección IPv6 donde se encuentra una servidor DNS recursivo abierto, envíamos un correo automatizado a la organización dueña de la dirección IP alertando la situación. En él explicamos las posibles consecuencias y recomendamos una serie de configuraciones para los servidores más usados. Dicho correo tiene un formato similar a:

===
DATE DD-MM-AAAA


Dear ORG-ID NAME. (OR-ID-LACNIC):

You appear to be running a DNS - open recursive resolver at IP address 280X:XXXX:X:XXXX:XXXX:XXXX:XXXX:XXXX.

It may have undesirable consequences on the Internet because it may participate in an attack against a selected target, causing a Denial of Service (DOS) attack. It generates large UDP responses to spoofed queries, with those responses becoming fragmented because of their size.

We strongly recommend to reconfiguring your resolver. Here are some ways that may help you:


- To only serve your customers and not respond to outside IP addresses (in BIND, this is done by defining a limited set of hosts in "allow-query";)

options {

 allow-query {
  192.168.196.0/24;
  2001:db8::/32;
  localhost;
 } // end of allow-query
} // end of options


- To only serve domains that it is authoritative for (in BIND, this is done by defining a limited set of hosts in "allow-query" for the server overall but setting "allow-query" to "any" for each zone)

zone "example.com"{
 type master;
 file "example.com.db";
 allow-query {
  192.168.196.0/24;
  2001:db8::/32;
  localhost;
 } // end of allow-query
} // end of zone example.com


In unbound you can achieve the same behavior with the access-control statement in the unbound.conf file. Would be something like:

server:
 access-control: 2001:db8::/32 allow


If you are an ISP, please also look at your network configuration and make sure that you do not allow spoofed traffic (that pretends to be from external IP addresses) to leave the network. Hosts that allow spoofed traffic make possible this type of attack.

References:
More information on this type of attack and what each party can do to mitigate it can be found here: http://www.us-cert.gov/ncas/alerts/TA13-088A


Best regards,

LACNIC's WARP Team

=======

Caso de éxito

Queremos presentarles este caso de éxito que comenzó cuando una organización recibió el correo indicado anteriormente y se contactó con WARP buscando recibir apoyo para aplicar las recomendaciones de seguridad en sus equipos. Por ser un proyecto nuevo no nos había ocurrido esta situación anteriormente pero analizamos el caso decidimos proseguir por dos razones:
⋅⋅1. La persona que nos contactó se mostró realmente interesada
⋅⋅2. El OS y el servidor DNS se encontraba en el grupo de los cuales tenemos experiencia

Comenzamos por identificar dónde estaban los archivos de configuración del servidor y los ACLs que él mismo utilizaba. Luego le guiamos para implementar en la configuración existente, las recomendaciones de seguridad genéricas que enviamos en el correo inicial.

La buena noticia fue que el miembro de LACNIC, siempre se mostró muy dado a recibir nuestra ayuda y la comunicación fue muy fluida en todo momento. Al cabo de menos de dos semanas, con aproximadamente 8 correos intercambiados, el servidor que era una potencial amenaza se encontraba configurado de tal manera que solo permitía consultas DNS desde sus propios prefijos.
Pero esto no fue todo, la alerta que enviamos y por la cual fuimos contactados, refería solo a uno de los servidores administrados por esta organización. Para completar nuestra tarea, nuestro miembro identificó que otro servidor de su red se encontraba en las mismas condiciones que el anterior, por lo que también colaboramos en la aplicación de las correcciones necesarias.

El caso lo consideramos muy exitoso por ser servidores que tienen direcciones IPv6 estáticas las cuales eventualmente podrían ser descubiertas por algunos atacantes y traer consigo eventuales tareas maliciosas sobre la red.

Lo anterior no quiere decir que sea el único caso de éxito ocurrido, muy posiblemente otros operadores han tomado acciones sobre sus servidores sin conocimiento alguno de LACNIC. Prontamente estaremos trabajando en identificar estos casos y publicaremos algunos resultados.

Referencias

[1] (https://labs.lacnic.net/Identificando-servidores-DNS-IPv6-Open-Resolvers/)
[2] (https://warp.lacnic.net/)

Por:

Darío Gómez

Security Analyst at LACNIC WARP

@daro_ua

Alejandro Acosta

@ITandNetworking

lunes, 27 de agosto de 2018

Utilizando Netstat en Linux con IPv6

viernes, 13 de julio de 2018

Como colocar a Flask a escuchar en IPv4 e IPv6 (dualstack)

Respuesta:

app.run(host='::',port=5005)

miércoles, 23 de mayo de 2018

Script in Python3 que chequea fecha de vencimiento de certificados SSL y envia correos

Intro:
Abajo les dejo un script realizado en Python3 que chequea fecha de vencimiento de certificados SSL (https) y realiza el envio de correos.

Importante:
Que corra en OS modernos (Ubuntu 16.04 o mayor por ejemplo).., la razón es el soporte de librerías actualizadas SSL

El Script:
$ more check_ssl_certificates.py

#!/usr/bin/python3

#El objetivo de este script es revisar los hostnames en la lista hostnames

#revisar cuantos dias faltan para que expire el certificado SSL

#y se expira pronto (definido por la variable umbral) enviar un correo

#con dicha notificacion

import OpenSSL

import ssl, socket

import argparse

from OpenSSL import SSL

from datetime import datetime

# Please add every FQDN you wish to be checked

hostnames = ["www.sitio1.com","www.sitio2.com","www.sitio3.com"]

umbral = 10 #threshold - number of days left in order to send the notification

notify_to= "you@yourserver.com, youyou@yourserver.com" #list of email addresses to send email separated by ,

def cert_expiration_date(hostname):

# get SSL Cert info

try:

cert = ssl.get_server_certificate((hostname, 443))

x509 = OpenSSL.crypto.load_certificate(OpenSSL.crypto.FILETYPE_PEM, cert)

x509info = x509.get_notAfter()

exp_day = x509info[6:8].decode('utf-8')

exp_month = x509info[4:6].decode('utf-8')

exp_year = x509info[:4].decode('utf-8')

exp_date = str(exp_day) + ' ' + str(exp_month) + ' ' + str(exp_year)

expire_date = datetime.strptime(exp_date, "%d %m %Y")

except Exception:

MSG='el host ' + str(hostname) + ' no pudo ser chequeado '

sendnotification(hostname, 0, MSG)

return #will enter here if could not connect to the website port 443

#print('SSL Certificate for hostname', hostname, 'will be expired on (DD-MM-YYYY)', exp_date)

#print('SSL Certificate for hostname', hostname, 'will be expired on (DD-MM-YYYY)', expire_date)

expire_in = expire_date - datetime.now()

expire_in = str(expire_in).split(' ')[0]

if int(expire_in) < umbral :

MSG='el cert ssl de ' + str(hostname) + ' expira en ' + str(expire_in) + ' dias'

sendnotification(hostname, str(expire_in), MSG)

#print ('Expira en: ', expire_in)

def sendnotification(hostname, expire_in, MSG):

from smtplib import SMTP_SSL as SMTP

import logging

import logging.handlers

import sys

from email.mime.text import MIMEText

#MSG = 'el cert ssl de ' + str(hostname) + ' expira en ' + str(expire_in) + ' dias'

#text = MSG

msg = MIMEText(MSG, 'plain')

msg['Subject'] = MSG

me = 'your@email.com'

recipients = notify_to

msg['To'] = notify_to

try:

conn = SMTP('yourmailserver.com')

conn.set_debuglevel(True)

conn.login('authusr', 'yourpassword')

try:

conn.sendmail(me,recipients.split(',') , msg.as_string())

finally:

conn.close()

except Exception as exc:

logger.error("ERROR!!!")

logger.critical(exc)

sys.exit("Mail failed: {}".format(exc))

if __name__ == "__main__":

for hostname in hostnames:

cert_expiration_date(hostname)

miércoles, 16 de mayo de 2018

Solucion: "mtr: Failure to start mtr-packet: Invalid argument"

Hola,

  Al ejecutar mtr en MAC (en mi caso Sierra) obtienes:

mtr: Failure to start mtr-packet: Invalid argument

  El problema es que "mtr-packet" no está en tu PATH, debes ubicar donde se encuentra -generalmente en /usr/local/sbin-. Puedes buscarlo con:

#find / -name mtr-packet 

  Luego tienes que agregar el directorio que lo contiene al tu PATH. Para hacerlo:

Solución 1:

  En un terminal:

  PATH="$PATH:/usr/local/sbin"

Solución 2:

  Agregar una linea "/usr/local/sbin" /etc/paths, por ejemplo:

  echo "/usr/local/sbin" >> /etc/paths

  Espero te sirva,

miércoles, 9 de mayo de 2018

IPv4 e IPv6 en una sola VPN utilizando OpenVPN

Introducción
Recientemente conversando con un amigo (@TarantinDigital) me indicaba que le gustaría tener una VPN que soportara IPv4 e IPv6, que le parece una solución muy interesante para IoT.
Igualmente entre otras cosas ofrece la comodidad de tener direccionamiento IPv6 persistente (siempre el mismo bloque IPv6)

Importante
No voy a indicar los pasos para instalar o configurar OpenVPN.
Asumo tienes un servidor OpenVPN corriendo y en el servidor tienes direccionamiento IPv4 e IPv6
Nos enfocaremos en algunas entonaciones en el servidor y en el archivo server.conf
Este excelente video (en Ingles) ofrece paso a paso como instalar y configurar OpenVPN: https://www.youtube.com/watch?v=XcsQdtsCS1U

Pasos para agregar IPv6 a un servidor OpenVPN que actualmente ofrece solo IPv4

1) Tu interfaz tun (o TAP) tiene que tener direccionamiento IPv6, OpenVPN tiene algunas restricciones en cuando a la longitud de prefijo (*máscara*) que puede utilizar en IPv6, para este ejemplo estaré utilizando un /64

ifconfig tun0 add 2001:db8::1/64

2) Es necesario (para nuestro ejemplo, si utilizas un /64 global de IPv4 o direccionamiento IPv4 público no sería necesario) realizar NAT44 y NAT66:

NAT44

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -j SNAT --to xx.xx.xx.xx

NAT66

ip6tables -t nat -A POSTROUTING -o eth0 -s 2001:db8::/32 -j MASQUERADE #noten que en eth0 hay un IPv6 global

3) Hay que agregar algunas directivas de IPv6 en el archivo /etc/openvpn/server.conf. Las mismas son las siguientes:

proto udp6 #hará que el server maneje sockets v4 y v6

server-ipv6 2001:db8::1/64 #dirección IP colocada a la interfaz tun en el server openvpn

tun-ipv6 #tipo de interfaz tunnel con IPv6

push tun-ipv6 #se le pide al cliente crear interfaces tun para el tunel (la VPN)

ifconfig-ipv6 2001:db8::1 2001:db8::2

push "route-ipv6 2000::/3" #inyecta esta ruta en el cliente

4) Finalmente es necesario convertir el servidor VPN en un router IPv6. Para ellos editamos el archivo /etc/sysctl.conf y la linea net.ipv6.conf.all.forwarding=1 le quitamos el #

Del lado del cliente veras una interfaz similar a:

utun1: flags=8051 mtu 1500

inet 10.8.0.6 --> 10.8.0.5 netmask 0xffffffff

inet6 fe80::aebc:32ff:fe96:822b%utun1 prefixlen 64 scopeid 0xd

inet6 2001:db8::1001 prefixlen 64

Note que recibió una dirección IPv6 del mismo /64 de la interfaz tun del servidor.

Espero sea de tu utilidad

Referencias
https://www.youtube.com/watch?v=XcsQdtsCS1U
http://blog.acostasite.com/2014/07/nat66-en-linux.html

lunes, 7 de mayo de 2018

Solucion a errores: OpenVPN daemon() failed or unsupported: Resource temporarily unavailable (errno=11)

Introducción:
Tengo estos errores en syslog luego de intentar levantar openvpn:

May 7 12:59:47 server ovpn-server[764]: library versions: OpenSSL 1.0.2g 1 Mar 2016, LZO 2.08
May 7 12:59:47 server ovpn-server[764]: daemon() failed or unsupported: Resource temporarily unavailable (errno=11)
May 7 12:59:47 server ovpn-server[764]: Exiting due to fatal error

Solución:
En el archivo:

/lib/systemd/system/openvpn@.service

Ubicar la linea:
LimitNPROC=10
y comentarla, quedaría así:

#LimitNPROC=10

Reiniciar el servidor y listo.

Espero te ayude.

lunes, 1 de enero de 2018

Solucion de errores: SSH "Permission denied (publickey)". Luego de upgrade. Facil y rapido

En caso de que estes recibiendo el siguiente error al hacer un ssh:

"Permission denied (publickey)."

pero extrañamente venía funcionando todo quizás fue por un upgrade de openssh o del sistema operativo.

Lo primero que te recomiendo es realizar un ssh y con algo de debug (por ejemplo con el -v)

Quedarías así:

$ ssh -v -l alejandro miserver.com

Verás algo así:

$ ssh -v -l alejandro miserver.com

OpenSSH_7.6p1, LibreSSL 2.6.2

debug1: Reading configuration data /Users/alejandroacosta/.ssh/config

debug1: /Users/alejandroacosta/.ssh/config line 1: Applying options for *

debug1: Reading configuration data /etc/ssh/ssh_config

debug1: /etc/ssh/ssh_config line 49: Applying options for *

debug1: Connecting to miserver port 22.

debug1: Connection established.