Hace 6 años | Por A.Guzman a sysadmit.com
Publicado hace 6 años por A.Guzman a sysadmit.com

Cuando realizamos una conexión SSH (Secure SHell), en ocasiones podemos encontrarnos con que el proceso de login es lento. Concretamente, experimentamos lentitud hasta que se nos pide el password. En el artículo se explican dos posibles causas y soluciones.

Comentarios

A

#7 #6 Creo que el compañero se refiere montar un servidor DNS con una zona inversa configurada y allí los registros de las IPs de los clientes que se conectan por SSH. En la tarjeta de red del servidor SSH, configurar como DNS primario ese servidor DNS con la zona inversa.

Shotokax

#8 ¿no sería más lógico arreglar los problemas de lentitud con el servidor DNS que crear otro servidor local?

A

#9 Sí, pero puede ser problemas de lentitud en el DNS o bien que igual la IP desde la que te conectas al servidor SSH no tiene registro inverso configurado.

Una opción seria configurarlo, pero si no hay DNS o no puedes configurarlo, otra opción es deshabilitar la verificación del registro inverso en el servidor SSH tal y como indica en el post.

Shotokax

#10 bueno, para ese caso concreto sí, pero no es muy habitual yo creo.

D

Con perdón pero me parece acojonante que esta noticia llegue a portada.
Hay básicamente 2 causas de la lentitud del login por ssh:
La resolución inversa de nombres y el gssapi no soportado.
Se sabe hace la puñeta de años y suele pasar siempre con gente que tiene dominios dinámicos sin resolución inversa (PTR).
Y con clientes que no soportan la versión o el protocolo de GSSApi. Se soluciona actualizando el cliente o deshabilitando el GSSApi.
Ya está. ¿Dan estas dos lineas para una portada?
Si el artículo estuviese escrito a todo el ancho de pantalla y con el tamaño de tipografía de meneame no abultaría nada más que un párrafo.

Ojo que no digo que no sea útil. Pero de ahí a que con tan poca chicha se haga una portada...

D

#12 Se sabe hace la puñeta de años

Ya pero piensa que este es el año de GNU/Linux en el escritorio.

A

#12 Según dices, el tema es sencillo, fácil de entender y puede resultar útil. ¿Qué problema hay que llegue a portada?

D

#21 No es noticia por antiguedad.
No tiene ninguna profundidad porque no puede tenerla ya que se pueden explicar en un solo párrafo sintomas, causas y solución.
Y no es siguiera de lejos un artículo reseñable por su calidad.
Si esto es suficiente para llegar a portada, entonces todos los artículos de emezeta (y muchos) sobre linux deberían estar en portada siempre.

A

#22 Respeto tu opinión, de verdad, pero si a la gente le ha parecido de utilidad y por tanto ha meneado el artículo de forma natural, sinceramente, no le veo el problema.

Es cierto que no es una novedad, pero hay muchos otros artículos que no lo son y están en portada.

De hecho el artículo, hasta que no ha llegado a portada, no ha recibido ningún voto negativo, ha sido llegar a portada y recibirlos de gente que piensa como tu, totalmente respetable, pero me cuesta de entenderlo.

D

#23 Yo no he votado negativo.
Es cierto que no es una novedad, pero hay muchos otros artículos que no lo son y están en portada.
¿Si se menease artículos de mierda con asiduidad, eso haría mejor este tipo de artículos no novedosos y practicamente sin contenido?

Si la gente pasado mañana menease un artículo que es literalmente una mierda pinchada en un palo, ¿estaría bien por que la gente lo ha meneado?
¿A eso se reduce todo?
Imagina esto mismo en la literatura, música, cine. ¿El que a todo el mundo le guste algo automaticamente lo hace bueno?
Eso no es más que un argumento ad populum.

¿Si mañana todo el planeta menease un goatse eso lo hace automaticamente algo digno de menearse o le añade algún tipo de calidad?
No. Pues esto es lo mismo.
Si la justificación para que esté algo en portada es que ya está en portada, entonces podemos menear canibalismo, pedofilia, etc... y listo ¿no?

A

#24 Te resumo mi argumento:

Es un artículo técnico que explica como resolver un problema y a la gente le ha resultado útil a nivel técnico (ya que es un artículo técnico), por tanto han meneado el artículo.

A ti no te gusta, OK, pero según mi punto de vista, es mas útil e interesante que muchos artículos que han llegado a portada.

D

#25 Entonces un artículo "técnico" que explicase como defragmentar un disco duro y porqué si a la gente le parece útil ¿merece portada?
No es que no me guste el artículo. Es que es con perdón creo que es una nimiedad. Han salido en Mmn mil veces artículos mucho más técnicos.
No has contestado lo que te preguntaba.

A

#26 Te contesto:

Pienso que no es comparable que la gente menee un artículo técnico a que la gente menee noticias que promuevan el canibalismo, etc... pienso que el argumento es demagogia.

Es evidente que no todo lo que la gente hace está bien, pero te repito que el articulo es un how-to técnico, no es ninguna noticia viral, ni da la opinión de nada, por lo tanto lo has de tratar como lo que es, un artículo técnico.

¿Hay artículos técnicos mas interesantes que este? Seguramente sí o no, depende del lector, ¿Más útiles?, Seguramente sí o no, depende del lector.

Si tu ya sabias la información que explica, pues no te ha resultado útil, está claro. Si no tocas SSH, pues tampoco.

Eso sí, respeta a la gente que sí le ha resultado útil y por tanto ha meneado el artículo.

D

#27 Dime como no estoy respetando a la gente que ha meneado el artículo.
Volvemos al respeto mal entendido. Al respeto que se resume en "no quiero oir una opinión contraria a la mia".

La comparación no la pongo por que sea de igual a igual, la pongo para mostrar donde está el problema y poner en tela de juicio el argumento de solo por que la gente menee algo automaticamente es un articulo de buena calidad o merece portada.

A

#28 Como respuesta, solo te diría que leas tu primer comentario. Allí queda explicado al detalle.

Nada mas, recibe un abrazo 👍 👍

S

#12 esto es menéame, qué esperabas
Por cierto bien explicado.

A

#31 No toda la gente de menéame actúa igual, pero si que es cierto que al llegar a portada se juntan unos cuantos y tiran abajo el artículo, me imagino que es por el hecho de ser un "how-to técnico" y no una noticia como tal.

Pienso que si es algo útil de un medio minoritario y si la gente lo ha ido meneando de forma natural, deberían dejarlo que siga en portada sin tirarlo abajo con votos negativos de irrelevante, etc...

Magankie

En vez de puentear, también es posible crear una rDNS para la ip, que sería lo suyo realmente...

A

#2 Sí, es otra posibilidad.

Shotokax

#2 el artículo no habla de puentear creo, de hecho habla de que la lentitud puede deberse precisamente a la resolución DNS inversa (entre otras posibilidades).

Magankie

#5 Habla de deshabilitar la comprobación de DNS, y eso sería puentearlo.

Shotokax

#6 vale, creo lo había entendido mal. ¿Te referías a crear el registro DNS inverso localmente?

Pepitorl

que hace esto en portada

D

Yo que algunos conocimientos informáticos tengo, incluso tengo una raspberry a la que me conecto vía ssh muchas veces para configurar cosas y tal, y es meterme en estos meneos y leer lo comentarios y sentirme que no tengo ni idea de informática, no sé ya lo que pensará el usuario medio, supongo que el titular solo ya les acojona

alexwing

#13 nada, no te preocupes, los de sistemas viven en otro mundo, se creen los master del universo por ejecutar comandos desde un bash y un par de scripts sh.

A

#13 Ahora si te conectas por SSH y va lento el login, igual el artículo te ayuda. Eso que dices de que sientes que no tienes ni idea, pasa a todos, incluso a los mas experimentados, poco a poco y si te gusta, es echarle horas investigando, leyendo, probando...

D

#30, desde el móvil me tarda de 2 a 4 segundos en dejarme meter el login, y una vez metido menos de un segundo en aceptarlo y dejarme meter comandos, no sé si eso será lento, pero puedo vivir con ello

Graffin

Este es el año del login SSH lento en el escritorio.

D

ahá... interesantísimo, contadme más.

zeehio

En mi caso me encuentro que el sistema se queda sin memoria RAM, hace swap, intento conectarme vía ssh para parar el proceso culpable y tarda mucho por todo el swapping. Sabéis si es posible reservarme un poco de RAM para estos casos (que el artículo no menciona)? (Pensé en limitar la memoria de los otros procesos, pero 4 procesos no tan grandes de 4 usuarios distintos me podrían fastidiar también supongo)

z

#15 usa servicios en contenedores y tema resuelto.

Forma fácil, docker.
Forma complicada: suerte con la configuración de los cgroups.