subject:"SSH"

Re: Ayuda Borre ssh de etc

2024-05-27 Por tema Camaleón

El 2024-05-27 a las 11:49 -0300, Jorge Abel Secreto escribió:

> Hola
> 
> El lun, 27 may 2024 a la(s) 11:33 a.m., Kadir Alexis Valdés Izquierdo
> (kadir.va...@uic.cu) escribió:
> >
> > como crear nuevamente directorio ssh? en debian 12 borre y quisiera 
> > restaurar

(ahora me ha llegado este mensaje :-o)

>  Probaste reinstalar ssh?

Si lo que busca es «recrear» la estructura del paquete original, 
también puede decargar el paquete DEB¹ y «examinarlo» (explorarlo, es 
como un ZIP comprimido) sin necesidad de instalarlo.

¹http://ftp.de.debian.org/debian/pool/main/o/openssh/openssh-server_9.2p1-2+deb12u2_amd64.deb

Saludos,

-- 
Camaleón

Re: Ayuda Borre ssh de etc

2024-05-27 Por tema Jorge Abel Secreto

Hola

El lun, 27 may 2024 a la(s) 11:33 a.m., Kadir Alexis Valdés Izquierdo
(kadir.va...@uic.cu) escribió:
>
> como crear nuevamente directorio ssh? en debian 12 borre y quisiera restaurar

 Probaste reinstalar ssh?


-- 
Jorge A Secreto
Analista de Sistemas
MP 361

Ayuda Borre ssh de etc

2024-05-27 Por tema Kadir Alexis Valdés Izquierdo

como crear nuevamente directorio ssh? en debian 12 borre y quisiera restaurar

Re: Bullseye upgrade - Mate desktop - Caja - por ssh no previsualiza jpg ni png.

2023-07-18 Por tema jacsenred

Hola a tod@s!

Pues nada... como no daba con la solucion del asunto, hice esto:

# nano /etc/apt/sources.list

Agrego los repositorios de Bookworm...
Comento los de Bullseye (#)...

# apt-get update
# apt-get install --reinstall caja

Me dice que tengo que actualizar todos estos paquetes:
binutils binutils-common binutils-x86-64-linux-gnu caja caja-common 
gnome-keyring gvfs gvfs-backends gvfs-common gvfs-daemons gvfs-libs libbinutils 
libc-bin libc-dev-bin libc-l10n libc6 libc6-dev libcaja-extension1 
libctf-nobfd0 libctf0 libgcrypt20 libgdata22 libglib2.0-0 libglib2.0-bin 
libjansson4 libnghttp2-14 libzstd1 locales

Le digo que actualice... finaliza, y todo correcto.

Posteriormente, hago esto:

# nano /etc/apt/sources.list

Elimino los repositorios de Bookworm.
Descomento los de Bullseye...

# apt-get update
# apt-get upgrade

Parece que vuelvo a estar en odlstable y que todo va bien.

Compruebo si se previsualizan las imagenes... ""Y ahora lo hace correctamente"".

Pero empiezo a ver como por los costados de la pantalla, al portatil le 
empiezan a salir un par de tornillos bastante, bastante gordos... X-)
Ahora tengo un Frankenstein rulando... Y me apetece matarlo y revertir todo a 
oldstable (Bullseye).

# apt-get install --reinstall binutils binutils-common 
binutils-x86-64-linux-gnu caja caja-common gnome-keyring gvfs gvfs-backends 
gvfs-common gvfs-daemons gvfs-libs libbinutils libc-bin libc-dev-bin libc-l10n 
libc6 libc6-dev libcaja-extension1 libctf-nobfd0 libctf0 libgcrypt20 libgdata22 
libglib2.0-0 libglib2.0-bin libjansson4 libnghttp2-14 libzstd1 locales

Y alguna libreria me impide downgradear...
Lo hice el Viernes pasado y despues del fin de semana ya no recuerdo cual o 
cuales son exactamente... Casi seguro que libc6 es una de ellas... pero no lo 
se!

Hoy intento reinstalar caja y me dice que naranjas hay en la china!

# apt-get install --reinstall caja

No es posible reinstalar el paquete caja, no se pudo descargar... Zasca! 8-(

Pues na... Que se va a quedar asi hasta que me apetezca o pueda reinstalar el 
sistema desde cero.

Por cierto, no quiero upgradear a bookworm... en una live con mate que probe al 
poco tiempo de lanzarse me dio la sensacion como que venia instalado Wayland 
como servidor grafico por defeto y mate tenia algun problema...
O como si algunas aplicaciones (entre ellas caja) se hubiesen reemplazado por 
las de gnome... que por cierto, no me gustan nada, nada!

Venga, gracias, que no os doy mas la chapa ya!

Happy hacking y un saludo de nuevo a tod@s!

Ah! que se me pasaba, antes de subir a stable (Bookworm) intente bajar a 
Buster, pero los repos de Buster ya no disponen de soporte para caja...

X-)

--- Original Message ---
El jueves, 13 de julio de 2023 a las 18:22, jacsenred 
 escribió:

>> El 2023-07-10 a las 22:57 +, jacsenred escribió:
>
>> Si antes te funcionaba y ahora no, la única diferencia parece el cambio
>> de versiones tras actualizar el sistema. Es raro, sí...
>
> Seguramente sea algo en la configuracion de caja, en $home/.config
> Si encuentro la solucion la posteare.
>
>> Mira ver qué sucede con ssh (esto funcionará siempre y cuando en el
>> servidor tengas un entono gráfico instalado con Mate, si no es así,
>> descártalo).
>>
>> Desde el cliente, lanza una terminal gráfica y ejecuta:
>> ssh -X usuario_remoto@IP
>>
>> Y una vez dentro, ejecuta Caja, a ver si carga las miniaturas.
>
> Si, he probado, pero caja no se abre...
> Sin embargo pluma y/o xclock si lo hacen.
>
>> Y en local supongo que te funciona sin problemas ¿no?
>
> Si, efectivamente, en local no hay problema.
>
>> > Me sucede que al loguearme en un primer momento en el TTY1, 2, 3, etc. no 
>> > me carga el .bashrc.
>> > Pasa tanto como root o como usuario.
>> >
>> > Eso si, si despues de logearme como usuario o como root lanzo una sesion 
>> > embebida... ($su user) entonces ahora si lo carga!
>>
>> Mira a ver si se trata de un intérprete de inicio de sesión o no.
>> Una vez dentro, ejecuta:
>>
>> echo $0
>>
>> Dependiendo del tipo de shell que hayas iniciado, leerá el archivo
>> bashrc o profile en primer lugar.
>
> Esto ya esta solucionado.
> Me habia cepillado los archivo .profile, los he recuperado y ya esta 
> solucionado.
>
> Saludos a tod@s!
> Y muchas gracias de nuevo Camaleon!

Re: Bullseye upgrade - Mate desktop - Caja - por ssh no previsualiza jpg ni png.

2023-07-13 Por tema jacsenred

> El 2023-07-10 a las 22:57 +, jacsenred escribió:

> Si antes te funcionaba y ahora no, la única diferencia parece el cambio
> de versiones tras actualizar el sistema. Es raro, sí...

Seguramente sea algo en la configuracion de caja, en $home/.config
Si encuentro la solucion la posteare.

> Mira ver qué sucede con ssh (esto funcionará siempre y cuando en el
> servidor tengas un entono gráfico instalado con Mate, si no es así,
> descártalo).
>
> Desde el cliente, lanza una terminal gráfica y ejecuta:
> ssh -X usuario_remoto@IP
>
> Y una vez dentro, ejecuta Caja, a ver si carga las miniaturas.

Si, he probado, pero caja no se abre...
Sin embargo pluma y/o xclock si lo hacen.

> Y en local supongo que te funciona sin problemas ¿no?

Si, efectivamente, en local no hay problema.

> > Me sucede que al loguearme en un primer momento en el TTY1, 2, 3, etc. no 
> > me carga el .bashrc.
> > Pasa tanto como root o como usuario.
> >
> > Eso si, si despues de logearme como usuario o como root lanzo una sesion 
> > embebida... ($su user) entonces ahora si lo carga!
>
> Mira a ver si se trata de un intérprete de inicio de sesión o no.
> Una vez dentro, ejecuta:
>
> echo $0
>
> Dependiendo del tipo de shell que hayas iniciado, leerá el archivo
> bashrc o profile en primer lugar.

Esto ya esta solucionado.
Me habia cepillado los archivo .profile, los he recuperado y ya esta 
solucionado.

Saludos a tod@s!
Y muchas gracias de nuevo Camaleon!

Re: Bullseye upgrade - Mate desktop - Caja - por ssh no previsualiza jpg ni png.

2023-07-10 Por tema jacsenred

> Supongo que accederás en remoto mediante sftp://.

Efectivamente es sftp la conexion.

> Mira a ver si te funciona (o no)iniciando desde un usuario normal y/o
desde root, quizá haya alguna dierencia.

Como root directamente no puedo acceder al server.
Como root desde el entorno grafico con el nombre de usuario si puedo acceder, 
pero no se previsualizan las imagenes.
Como usuario desde el entorno grafico igual, no se previsualizan.

Eso si, se previsualizan los pdfs... que no me habia dado cuenta hasta ahora.

> En Thunar (el gestor de archivos de XFCE) hay una opción para
> configurar cuándo quieres que se muestren las previsualizaciones o
> minitaruras (siempre, _sólo en local_, nunca), quizá taengas alguna
> opción similar para configurar que se te haya olvidado activar o se
> haya desconfigurado al actualizar Caja :-?

En mate tambien... de hecho si no lo configuras para que se previsualicen no se 
ven.
Caja -> Editar -> Preferencias -> Vista previa...

Pero lo tengo asi desde Buster... y he probado activando y desactivando... etc. 
en Bullseye.

No se, me resulta muy raro... pdfs si... png, gif y jpg no...

Y esto es otro tema, pero lo mismo esta relacionado:

Me sucede que al loguearme en un primer momento en el TTY1, 2, 3, etc. no me 
carga el .bashrc.
Pasa tanto como root o como usuario.

Eso si, si despues de logearme como usuario o como root lanzo una sesion 
embebida... ($su user) entonces ahora si lo carga!

Vaya un lio que me ha montado el upgradear a Bullseye al estilo rolling 
release...

El caso es que tengo el disco petao, de otro modo casi seguro que habria hecho 
una instalacion limpia, desde cero.

Por cierto, disculpar que utilice ahora esta cuenta y genere un lio con el 
hilo...
Resulta que ahora al loguearme los imbeciles de Gmail me exigen un numero de 
telefono... que se vayan a la mierda!

Un saludo a tod@s!
Y muchas gracias Camaleon por la caña que le das a la lista!

Re: Bullseye upgrade - Mate desktop - Caja - por ssh no previsualiza jpg ni png.

2023-07-10 Por tema Camaleón

El 2023-07-10 a las 12:16 +0200, Jose Ab bA escribió:

> El lun, 10 jul 2023 a las 12:11, Jose Ab bA ()
> escribió:
> 
> > Buenas Debianer@s!
> >
> > Hasta la semana pasada seguia en Buster.
> >
> > Upgradee de Bullseye desde los repositorios oficiales.
> >
> > Todo bien, excepto que ahora cuando accedo por ssh con caja a mi servidor
> > remoto no visualizo las vistas previas de los archivos tipo jpg y png.
> >
> > En Buster los previsualizaba sin problemas...
> >
> Disculpar que se me ha colado el enter y el gmail este ha remitio el correo
> sin querer!
> 
> Al hilo del asunto...
> 
> Creo que me falta un paquete... Sabeis cual es?
> 
> O es algun problema de configuracion?
> He renombrado mi /home/$user y he creado uno nuevo vacio y sigue igual...

Supongo que accederás en remoto mediante sftp://.

Mira a ver si te funciona (o no)iniciando desde un usuario normal y/o 
desde root, quizá haya alguna dierencia.

En Thunar (el gestor de archivos de XFCE) hay una opción para 
configurar cuándo quieres que se muestren las previsualizaciones o 
minitaruras (siempre, _sólo en local_, nunca), quizá taengas alguna 
opción similar para configurar que se te haya olvidado activar o se 
haya desconfigurado al actualizar Caja :-?

Saludos,

-- 
Camaleón

Re: Bullseye upgrade - Mate desktop - Caja - por ssh no previsualiza jpg ni png.

2023-07-10 Por tema Jose Ab bA

Disculpar que se me ha colado el enter y el gmail este ha remitio el correo
sin querer!

Al hilo del asunto...

Creo que me falta un paquete... Sabeis cual es?

O es algun problema de configuracion?
He renombrado mi /home/$user y he creado uno nuevo vacio y sigue igual...

Un saludo!

Jac.


El lun, 10 jul 2023 a las 12:11, Jose Ab bA ()
escribió:

> Buenas Debianer@s!
>
> Hasta la semana pasada seguia en Buster.
>
> Upgradee de Bullseye desde los repositorios oficiales.
>
> Todo bien, excepto que ahora cuando accedo por ssh con caja a mi servidor
> remoto no visualizo las vistas previas de los archivos tipo jpg y png.
>
> En Buster los previsualizaba sin problemas...
>

Bullseye upgrade - Mate desktop - Caja - por ssh no previsualiza jpg ni png.

2023-07-10 Por tema Jose Ab bA

Buenas Debianer@s!

Hasta la semana pasada seguia en Buster.

Upgradee de Bullseye desde los repositorios oficiales.

Todo bien, excepto que ahora cuando accedo por ssh con caja a mi servidor
remoto no visualizo las vistas previas de los archivos tipo jpg y png.

En Buster los previsualizaba sin problemas...

Re: No puede conectarme a ssh (SOLUCIONADO)

2022-05-27 Por tema Adolfo Luque

On 26/05/22, Camaleón wrote:
> El 2022-05-26 a las 05:56 -0400, Adolfo Luque escribió:
> 
> > hola lista
> > 
> > El asunto es que no me puedo conectar por ssh. Al hacer:
> > 
> > $systemctl status ssh me da:
> > 
> > ssh.service - OpenBSD Secure Shell server
> >  Loaded: loaded (/lib/systemd/system/ssh.service; enabled; vendor 
> > preset: enabled)
> > Drop-In: /run/systemd/system/service.d
> >  └─zzz-lxc-service.conf
> >  Active: inactive (dead)
> >   Condition: start condition failed at Thu 2022-05-26 04:04:21 -04; 10min 
> > ago
> >  └─ ConditionPathExists=!/etc/ssh/sshd_not_to_be_run was not met
> >Docs: man:sshd(8)
> >  man:sshd_config(5)
> 
> (...)
> 
> Del primer enlace que devuelve Google al buscar por le mensaje de error:
> 
> Starting SSH client in Debian Linux on a Lenovo Chromebook
> https://serverfault.com/questions/1036712/starting-ssh-client-in-debian-linux-on-a-lenovo-chromebook
> 
> A ver si te sirve.
> 
> Saludos,
> 
> -- 
> Camaleón 
 
Hola lista

Perfecto, funcionó de una vez. Eres genial Camaleon. Gracias 


> 


signature.asc
Description: PGP signature

Re: No puede conectarme a ssh

2022-05-26 Por tema Camaleón

El 2022-05-26 a las 05:56 -0400, Adolfo Luque escribió:

> hola lista
> 
> El asunto es que no me puedo conectar por ssh. Al hacer:
> 
> $systemctl status ssh me da:
> 
> ssh.service - OpenBSD Secure Shell server
>  Loaded: loaded (/lib/systemd/system/ssh.service; enabled; vendor preset: 
> enabled)
> Drop-In: /run/systemd/system/service.d
>  └─zzz-lxc-service.conf
>  Active: inactive (dead)
>   Condition: start condition failed at Thu 2022-05-26 04:04:21 -04; 10min ago
>      └─ ConditionPathExists=!/etc/ssh/sshd_not_to_be_run was not met
>Docs: man:sshd(8)
>  man:sshd_config(5)

(...)

Del primer enlace que devuelve Google al buscar por le mensaje de error:

Starting SSH client in Debian Linux on a Lenovo Chromebook
https://serverfault.com/questions/1036712/starting-ssh-client-in-debian-linux-on-a-lenovo-chromebook

A ver si te sirve.

Saludos,

-- 
Camaleón

No puede conectarme a ssh

2022-05-26 Por tema Adolfo Luque

hola lista

El asunto es que no me puedo conectar por ssh. Al hacer:

$systemctl status ssh me da:

ssh.service - OpenBSD Secure Shell server
 Loaded: loaded (/lib/systemd/system/ssh.service; enabled; vendor preset: 
enabled)
Drop-In: /run/systemd/system/service.d
 └─zzz-lxc-service.conf
 Active: inactive (dead)
  Condition: start condition failed at Thu 2022-05-26 04:04:21 -04; 10min ago
 └─ ConditionPathExists=!/etc/ssh/sshd_not_to_be_run was not met
   Docs: man:sshd(8)
 man:sshd_config(5)
Al hacer

sudo systemctl start ssh

No se inicia 

Al tratar de conectarme al servicio me devuelve:

ssh: connect to host (servicio-remoto) port 22: Connection timed out

La maquina es una Chromebook con procesador arm de Acer desde el Entorno de 
Desarrollo de Linux, que instala un Debian 11 (Bullseye). Entre las notas de 
Seguridad y Permiso dicen que cada aplicación Linux  se ejecuta en un Entorno 
aislado. ¿Tendrá esto algo que ver?

Realmente no se como funciona este Entorno de Desarrollo, sólo se instala 
mediante un botón por lo que no sé que tiene o que no tiene ni como hace lo que 
hace. Por ejemplo, no existe un archivo .xinitrc y si lo creas tampoco funciona.

Utilizo solamente este "Entorno", porque utilizar el Chromebook para alguna 
tarea no me da ninguna gracia, (ni tampoco los servicios de google en general) 
y si la tengo es 
porque en realidad me la regalaron. 


He probado ya toda la información que he visto en internet y nada. 


Bueno, agradezco cualquier ayuda que me puedan prestar al respecto

Gracias
 
Adolfo Luque





signature.asc
Description: PGP signature

Re: ssh no conecta (Bullseye en ambos equipos) * SOLUCIONADO * era por el ufw

2021-05-17 Por tema Walter Omar Dari

Hola gente, quedó SOLUCIONADO, era el ufw, no tenía idea que estaba 
instalado en ese equipo. Pero lo cierto es que comenzó a actuar a partir 
de la actualización a bullseye, con buster no bloqueaba nada. Es muy raro.


Gracias a OddieX por la ayuda y a todos los que respondieron, aprendí 
unas cuantas cosas para chequear que nunca había tenido que usar.


La solución: descubrí que había una interfaz gráfica para el ufw en el 
equipo en cuestión, ni bien la abrí vi que estaba todo denegado, así que 
cambié las opciones y ahora puedo ingresar.


La verdad que no recuerdo haber instalado ese firewall ni haberlo 
configurado nunca. Espero que no sean los años... ;-)


https://help.ubuntu.com/community/UFW

Saludos a todos y gracias nuevamente.



El 17/5/21 a las 15:16, OddieX escribió:

El lun, 17 may 2021 a las 15:04, Walter Omar Dari
() escribió:


Hola...

El 17/5/21 a las 12:51, OddieX escribió:



El lun., 17 de mayo de 2021 12:48, Walter Omar Dari mailto:wlin...@gmail.com>> escribió:

 Hola, lo que me faltaba probar...

 El 16/5/21 a las 03:52, Camaleón escribió:
  > El 2021-05-15 a las 19:56 -0300, Walter Omar Dari escribió:
  >
  > [...]
  >
  >
  > Si tienes otro equipo desde donde probar (p. j., otro sistema
 operativo
  > como Windows con Putty o MacOS), intenta a ver, no vaya a ser que la
  > guerra te la esté dando el cliente desde donde conectas.

 Con Putty tampoco se conecta al equipo en cuestión, a los demás no hay
 problemas.


  >
  > Saludos,
  >

 --




 Fijate en login.Defs q no encuentra iptables pq desde buster en
 adelante cambiaron los env path... Sino whereis iptables y ejecutalo
 con path completo...



Funcionó indicando la ruta completa, aquí va la salida, yo no veo
inconvenientes, pero no estoy muy ducho con estos (disculpas porque es
bastante larga)...


Chain INPUT (policy DROP)
target prot opt source   destination
ufw-before-logging-input  all  --  anywhere anywhere
ufw-before-input  all  --  anywhere anywhere
ufw-after-input  all  --  anywhere anywhere
ufw-after-logging-input  all  --  anywhere anywhere
ufw-reject-input  all  --  anywhere anywhere
ufw-track-input  all  --  anywhere anywhere

Chain FORWARD (policy DROP)
target prot opt source   destination
ufw-before-logging-forward  all  --  anywhere anywhere

ufw-before-forward  all  --  anywhere anywhere
ufw-after-forward  all  --  anywhere anywhere
ufw-after-logging-forward  all  --  anywhere anywhere

ufw-reject-forward  all  --  anywhere anywhere
ufw-track-forward  all  --  anywhere anywhere

Chain OUTPUT (policy ACCEPT)
target prot opt source   destination
ufw-before-logging-output  all  --  anywhere anywhere

ufw-before-output  all  --  anywhere anywhere
ufw-after-output  all  --  anywhere anywhere
ufw-after-logging-output  all  --  anywhere anywhere
ufw-reject-output  all  --  anywhere anywhere
ufw-track-output  all  --  anywhere anywhere

Chain ufw-after-forward (1 references)
target prot opt source   destination

Chain ufw-after-input (1 references)
target prot opt source   destination
ufw-skip-to-policy-input  udp  --  anywhere anywhere
   udp dpt:netbios-ns
ufw-skip-to-policy-input  udp  --  anywhere anywhere
   udp dpt:netbios-dgm
ufw-skip-to-policy-input  tcp  --  anywhere anywhere
   tcp dpt:netbios-ssn
ufw-skip-to-policy-input  tcp  --  anywhere anywhere
   tcp dpt:microsoft-ds
ufw-skip-to-policy-input  udp  --  anywhere anywhere
   udp dpt:bootps
ufw-skip-to-policy-input  udp  --  anywhere anywhere
   udp dpt:bootpc
ufw-skip-to-policy-input  all  --  anywhere anywhere
   ADDRTYPE match dst-type BROADCAST

Chain ufw-after-logging-forward (1 references)
target prot opt source   destination
LOGall  --  anywhere anywhere limit: avg
3/min burst 10 LOG level warning prefix "[UFW BLOCK] "

Chain ufw-after-logging-input (1 references)
target prot opt source   destination

Chain ufw-after-logging-output (1 references)
target prot opt source   destination

Chain ufw-after-output (1 references)
target prot opt source   destination

Chain ufw-before-forward (1 references)
target prot opt source   destination
ACCEPT all  --  anywhere anywhere ctstate
RELATED,ESTABLISHED
ACCEPT icmp --  anywhere anywhere icmp
destination-unreachable
ACCEPT icmp --  anywhere anywhere icmp
time-exceeded
ACCEPT icmp --  anywhere anywhere

Re: ssh no conecta (Bullseye en ambos equipos)

2021-05-17 Por tema Walter Omar Dari

re
reject-with icmp-port-unreachable

Chain ufw-user-limit-accept (0 references)
target prot opt source   destination
ACCEPT all  --  anywhere anywhere

Chain ufw-user-logging-forward (0 references)
target prot opt source   destination

Chain ufw-user-logging-input (0 references)
target prot opt source   destination

Chain ufw-user-logging-output (0 references)
target prot opt source   destination

Chain ufw-user-output (1 references)
target prot opt source   destination




--

Walter O. Dari

http://swcomputacion.com/
http://swcomputacion.com/sistemas/
https://facebook.com/swcomputacion/
https://facebook.com/sistemasSW/

Nuestros horarios:
L a V 8 a 13 hs.
S 11 a 14 hs.

WhatsApp:
2396 577140 (no se atienden llamadas)



Evidentemente tenes el ufw configurado, y tenes todo bloqueado...


Debe haber cambiado con la actualización a bullseye, porque 
inmediatamente antes funcionaba el ssh.
Lo uso muy seguido en los equipos de la red local para hacer las 
actualizaciones desde mi PC y estaba funcionando sin problemas.



Fijate baja el ufw y proba... Tambvien investiga como abrir esos puertos!


Ok, voy a probar, gracias !



Saludos



--

Walter O. Dari

http://swcomputacion.com/
http://swcomputacion.com/sistemas/
https://facebook.com/swcomputacion/
https://facebook.com/sistemasSW/

Nuestros horarios:
L a V 8 a 13 hs.
S 11 a 14 hs.

WhatsApp:
2396 577140 (no se atienden llamadas)

Re: ssh no conecta (Bullseye en ambos equipos)

2021-05-17 Por tema Walter Omar Dari


Hola...

El 17/5/21 a las 15:15, Ramses escribió:

El 17 de mayo de 2021 19:49:11 CEST, Walter Omar Dari  
escribió:



El 17/5/21 a las 13:12, Camaleón escribió:

El 2021-05-17 a las 12:37 -0300, Walter Omar Dari escribió:


El 16/5/21 a las 03:52, Camaleón escribió:

debug2: ssh_connect_direct
debug1: Connecting to 192.168.0.8 [192.168.0.8] port 22.

... después de un rato da un error de timeout.


Un error de timeout apunta a que el anfitrión (el equipo al que
conectas) corta la conexión por algún motivo (directiva de

seguridad,

etc.); si llegas con un ping al equipo, así a bote pronto el

cortafuegos

quedaría descartado.


El ping me responde inmediatamente...

$ ping 192.168.0.8
PING 192.168.0.8 (192.168.0.8) 56(84) bytes of data.
64 bytes from 192.168.0.8: icmp_seq=1 ttl=64 time=0.344 ms
64 bytes from 192.168.0.8: icmp_seq=2 ttl=64 time=0.330 ms
64 bytes from 192.168.0.8: icmp_seq=3 ttl=64 time=0.338 ms
64 bytes from 192.168.0.8: icmp_seq=4 ttl=64 time=0.331 ms
^C


Hum... prueba con una traza, aunque me temo que no proporcionará

mucha más

información:

traceroute -T -O info -p 22 192.168.0.8


Te detallo algunas otras cosas que hice (sugerencias de Zeque), al

final

está la traza...

/home/sw/Uso_compartido/temp/ssh_noconecta2.txt   [BM--]  9 L:[

1+26 27/

56] *(775 /1070b) 0010 0x00A [*][X]
1)  en el equipo que no permite las conexiones (192.168.0.8)...

root@debbns:~# iptables -L
bash: iptables: orden no encontrada

root@debbns:~# dpkg -l | grep iptables
ii  iptables1.8.7-1  amd64administration tools for

packet

filtering and NAT


?

Prueba con:
#su - -c "iptables -L"


hosts.allow y hosts.deny  están vacíos (salvo las lìneas comentadas

al

principio), no hay direcciones IP ni nombres de hosts.

Probé agregando la línea...

ALL : ALL : allow

... en hosts.allow, pero tampoco da resultados.


2) en cualquier equipo que se quiera conectar a 192.168.0.8...

dari@debwal:~$ nc -vvv 192.168.0.8 22
^C sent 0, rcvd 0

root@debwal:/home/dari# traceroute -T -O info -p 22 192.168.0.8
traceroute to 192.168.0.8 (192.168.0.8), 30 hops max, 60 byte

packets

   1  * * *
   2  * * *


(...)

No llega.


Si la conexión fuera entre redes distintas (remotas), pasando el
tráfico por distintos servidores y enrutadores que no están bajo tu
supervisión, podría entenderse el timeout por algún filtro de los

ISP,

el tamaño de los paquetes o cortafuegos, pero teniendo controlado

el

entorno de conexión (red local) el tiemout es todo un misterio :-?

Si tienes otro equipo desde donde probar (p. j., otro sistema

operativo

como Windows con Putty o MacOS), intenta a ver, no vaya a ser que

la

guerra te la esté dando el cliente desde donde conectas.


He probado desde otros equipos con Debian y el resultado es el

mismo.

El tema tiene que estar en el huraño 192.168.0.8 :-)

A ese equipo lo actualicé, no fue una instalación desde cero,

anteriormente

tenía Buster, así que le modifiqué el sources.list reemplazando

buster por

bullseye. La actualización no dio problemas.

Voy a ver si encuentro alguna portátil a la que le haya quedado un

dual boot

con Windows para probar con Putty

Gracias !


Sólo por curiosidad... ¿has probado a intentar conectarte a otro
servicio/puerto que no sea SSH? P. ej., servidor de correo sin

cifrado

(110/25) o cualquier otro que puedas tener configurado en ese equipo.

Lo digo para descartar un problema localizado en ese servicio/
aplicativo/puerto o para confirmar que se trata de un problema
generalizado que afecta a otra combinación de servicios y puertos.



Acabo de instalarle Apache y no responde, solamente funciona de modo
local.

Lo raro que responde al ping...




Saludos,



¿No tendrás duplicada la IP en la red y te está respondiendo otro equipo?

Un tcpdump a ver si está respondiendo ese equipo al Ping y miras si te llega 
tráfico cuando le tiras el SSH desde otro equipo.


No, no está duplicada, ya está comprobado. Gracias !





Saludos

.



--

Walter O. Dari

http://swcomputacion.com/
http://swcomputacion.com/sistemas/
https://facebook.com/swcomputacion/
https://facebook.com/sistemasSW/

Nuestros horarios:
L a V 8 a 13 hs.
S 11 a 14 hs.

WhatsApp:
2396 577140 (no se atienden llamadas)

Re: ssh no conecta (Bullseye en ambos equipos)

2021-05-17 Por tema OddieX

El lun, 17 may 2021 a las 15:04, Walter Omar Dari
() escribió:
>
> Hola...
>
> El 17/5/21 a las 12:51, OddieX escribió:
> >
> >
> > El lun., 17 de mayo de 2021 12:48, Walter Omar Dari  > > escribió:
> >
> > Hola, lo que me faltaba probar...
> >
> > El 16/5/21 a las 03:52, Camaleón escribió:
> >  > El 2021-05-15 a las 19:56 -0300, Walter Omar Dari escribió:
> >  >
> >  > [...]
> >  >
> >  >
> >  > Si tienes otro equipo desde donde probar (p. j., otro sistema
> > operativo
> >  > como Windows con Putty o MacOS), intenta a ver, no vaya a ser que la
> >  > guerra te la esté dando el cliente desde donde conectas.
> >
> > Con Putty tampoco se conecta al equipo en cuestión, a los demás no hay
> > problemas.
> >
> >
> >  >
> >  > Saludos,
> >  >
> >
> > --
> >
> >
> >
> >
> > Fijate en login.Defs q no encuentra iptables pq desde buster en
> > adelante cambiaron los env path... Sino whereis iptables y ejecutalo
> > con path completo...
> >
>
> Funcionó indicando la ruta completa, aquí va la salida, yo no veo
> inconvenientes, pero no estoy muy ducho con estos (disculpas porque es
> bastante larga)...
>
>
> Chain INPUT (policy DROP)
> target prot opt source   destination
> ufw-before-logging-input  all  --  anywhere anywhere
> ufw-before-input  all  --  anywhere anywhere
> ufw-after-input  all  --  anywhere anywhere
> ufw-after-logging-input  all  --  anywhere anywhere
> ufw-reject-input  all  --  anywhere anywhere
> ufw-track-input  all  --  anywhere anywhere
>
> Chain FORWARD (policy DROP)
> target prot opt source   destination
> ufw-before-logging-forward  all  --  anywhere anywhere
>
> ufw-before-forward  all  --  anywhere anywhere
> ufw-after-forward  all  --  anywhere anywhere
> ufw-after-logging-forward  all  --  anywhere anywhere
>
> ufw-reject-forward  all  --  anywhere anywhere
> ufw-track-forward  all  --  anywhere anywhere
>
> Chain OUTPUT (policy ACCEPT)
> target prot opt source   destination
> ufw-before-logging-output  all  --  anywhere anywhere
>
> ufw-before-output  all  --  anywhere anywhere
> ufw-after-output  all  --  anywhere anywhere
> ufw-after-logging-output  all  --  anywhere anywhere
> ufw-reject-output  all  --  anywhere anywhere
> ufw-track-output  all  --  anywhere anywhere
>
> Chain ufw-after-forward (1 references)
> target prot opt source   destination
>
> Chain ufw-after-input (1 references)
> target prot opt source   destination
> ufw-skip-to-policy-input  udp  --  anywhere anywhere
>   udp dpt:netbios-ns
> ufw-skip-to-policy-input  udp  --  anywhere anywhere
>   udp dpt:netbios-dgm
> ufw-skip-to-policy-input  tcp  --  anywhere anywhere
>   tcp dpt:netbios-ssn
> ufw-skip-to-policy-input  tcp  --  anywhere anywhere
>   tcp dpt:microsoft-ds
> ufw-skip-to-policy-input  udp  --  anywhere anywhere
>   udp dpt:bootps
> ufw-skip-to-policy-input  udp  --  anywhere anywhere
>   udp dpt:bootpc
> ufw-skip-to-policy-input  all  --  anywhere anywhere
>   ADDRTYPE match dst-type BROADCAST
>
> Chain ufw-after-logging-forward (1 references)
> target prot opt source   destination
> LOGall  --  anywhere anywhere limit: avg
> 3/min burst 10 LOG level warning prefix "[UFW BLOCK] "
>
> Chain ufw-after-logging-input (1 references)
> target prot opt source   destination
>
> Chain ufw-after-logging-output (1 references)
> target prot opt source   destination
>
> Chain ufw-after-output (1 references)
> target prot opt source   destination
>
> Chain ufw-before-forward (1 references)
> target prot opt source   destination
> ACCEPT all  --  anywhere anywhere ctstate
> RELATED,ESTABLISHED
> ACCEPT icmp --  anywhere anywhere icmp
> destination-unreachable
> ACCEPT icmp --  anywhere anywhere icmp
> time-exceeded
> ACCEPT icmp --  anywhere anywhere icmp
> parameter-problem
> ACCEPT icmp --  anywhere anywhere icmp
> echo-request
> ufw-user-forward  all  --  anywhere anywhere
>
> Chain ufw-before-input (1 references)
> target prot opt source   destination
> ACCEPT all  --  anywhere anywhere
> ACCEPT all  --  anywhere anywhere ctstate
> RELATED,ESTABLISHED
> ufw-logging-deny  all  --  anywhere anywhere
> ctstate INVALID
> DROP   all  --  anywhere anywhere

Re: ssh no conecta (Bullseye en ambos equipos)

2021-05-17 Por tema Ramses

El 17 de mayo de 2021 19:49:11 CEST, Walter Omar Dari  
escribió:
>
>
>El 17/5/21 a las 13:12, Camaleón escribió:
>> El 2021-05-17 a las 12:37 -0300, Walter Omar Dari escribió:
>> 
>>> El 16/5/21 a las 03:52, Camaleón escribió:
>>>>>>> debug2: ssh_connect_direct
>>>>>>> debug1: Connecting to 192.168.0.8 [192.168.0.8] port 22.
>>>>>>>
>>>>>>> ... después de un rato da un error de timeout.
>>>>>>
>>>>>> Un error de timeout apunta a que el anfitrión (el equipo al que
>>>>>> conectas) corta la conexión por algún motivo (directiva de
>seguridad,
>>>>>> etc.); si llegas con un ping al equipo, así a bote pronto el
>cortafuegos
>>>>>> quedaría descartado.
>>>>>
>>>>> El ping me responde inmediatamente...
>>>>>
>>>>> $ ping 192.168.0.8
>>>>> PING 192.168.0.8 (192.168.0.8) 56(84) bytes of data.
>>>>> 64 bytes from 192.168.0.8: icmp_seq=1 ttl=64 time=0.344 ms
>>>>> 64 bytes from 192.168.0.8: icmp_seq=2 ttl=64 time=0.330 ms
>>>>> 64 bytes from 192.168.0.8: icmp_seq=3 ttl=64 time=0.338 ms
>>>>> 64 bytes from 192.168.0.8: icmp_seq=4 ttl=64 time=0.331 ms
>>>>> ^C
>>>>
>>>> Hum... prueba con una traza, aunque me temo que no proporcionará
>mucha más
>>>> información:
>>>>
>>>> traceroute -T -O info -p 22 192.168.0.8
>>>
>>> Te detallo algunas otras cosas que hice (sugerencias de Zeque), al
>final
>>> está la traza...
>>>
>>> /home/sw/Uso_compartido/temp/ssh_noconecta2.txt   [BM--]  9 L:[ 
>1+26 27/
>>> 56] *(775 /1070b) 0010 0x00A [*][X]
>>> 1)  en el equipo que no permite las conexiones (192.168.0.8)...
>>>
>>> root@debbns:~# iptables -L
>>> bash: iptables: orden no encontrada
>>>
>>> root@debbns:~# dpkg -l | grep iptables
>>> ii  iptables1.8.7-1  amd64administration tools for
>packet
>>> filtering and NAT
>> 
>> ?
>> 
>> Prueba con:
>> #su - -c "iptables -L"
>> 
>>> hosts.allow y hosts.deny  están vacíos (salvo las lìneas comentadas
>al
>>> principio), no hay direcciones IP ni nombres de hosts.
>>>
>>> Probé agregando la línea...
>>>
>>> ALL : ALL : allow
>>>
>>> ... en hosts.allow, pero tampoco da resultados.
>>>
>>>
>>> 2) en cualquier equipo que se quiera conectar a 192.168.0.8...
>>>
>>> dari@debwal:~$ nc -vvv 192.168.0.8 22
>>> ^C sent 0, rcvd 0
>>>
>>> root@debwal:/home/dari# traceroute -T -O info -p 22 192.168.0.8
>>> traceroute to 192.168.0.8 (192.168.0.8), 30 hops max, 60 byte
>packets
>>>   1  * * *
>>>   2  * * *
>> 
>> (...)
>> 
>> No llega.
>> 
>>>> Si la conexión fuera entre redes distintas (remotas), pasando el
>>>> tráfico por distintos servidores y enrutadores que no están bajo tu
>>>> supervisión, podría entenderse el timeout por algún filtro de los
>ISP,
>>>> el tamaño de los paquetes o cortafuegos, pero teniendo controlado
>el
>>>> entorno de conexión (red local) el tiemout es todo un misterio :-?
>>>>
>>>> Si tienes otro equipo desde donde probar (p. j., otro sistema
>operativo
>>>> como Windows con Putty o MacOS), intenta a ver, no vaya a ser que
>la
>>>> guerra te la esté dando el cliente desde donde conectas.
>>>
>>> He probado desde otros equipos con Debian y el resultado es el
>mismo.
>>> El tema tiene que estar en el huraño 192.168.0.8 :-)
>>>
>>> A ese equipo lo actualicé, no fue una instalación desde cero,
>anteriormente
>>> tenía Buster, así que le modifiqué el sources.list reemplazando
>buster por
>>> bullseye. La actualización no dio problemas.
>>>
>>> Voy a ver si encuentro alguna portátil a la que le haya quedado un
>dual boot
>>> con Windows para probar con Putty
>>>
>>> Gracias !
>> 
>> Sólo por curiosidad... ¿has probado a intentar conectarte a otro
>> servicio/puerto que no sea SSH? P. ej., servidor de correo sin
>cifrado
>> (110/25) o cualquier otro que puedas tener configurado en ese equipo.
>> 
>> Lo digo para descartar un problema localizado en ese servicio/
>> aplicativo/puerto o para confirmar que se trata de un problema
>> generalizado que afecta a otra combinación de servicios y puertos.
>
>
>Acabo de instalarle Apache y no responde, solamente funciona de modo
>local.
>
>Lo raro que responde al ping...
>
>
>> 
>> Saludos,
>> 

¿No tendrás duplicada la IP en la red y te está respondiendo otro equipo?

Un tcpdump a ver si está respondiendo ese equipo al Ping y miras si te llega 
tráfico cuando le tiras el SSH desde otro equipo.


Saludos

Re: ssh no conecta (Bullseye en ambos equipos)

2021-05-17 Por tema Walter Omar Dari


Hola...

El 17/5/21 a las 12:51, OddieX escribió:



El lun., 17 de mayo de 2021 12:48, Walter Omar Dari > escribió:


Hola, lo que me faltaba probar...

El 16/5/21 a las 03:52, Camaleón escribió:
 > El 2021-05-15 a las 19:56 -0300, Walter Omar Dari escribió:
 >
 > [...]
 >
 >
 > Si tienes otro equipo desde donde probar (p. j., otro sistema
operativo
 > como Windows con Putty o MacOS), intenta a ver, no vaya a ser que la
 > guerra te la esté dando el cliente desde donde conectas.

Con Putty tampoco se conecta al equipo en cuestión, a los demás no hay
problemas.


 >
 > Saludos,
 >

-- 





Fijate en login.Defs q no encuentra iptables pq desde buster en
adelante cambiaron los env path... Sino whereis iptables y ejecutalo
con path completo...



Funcionó indicando la ruta completa, aquí va la salida, yo no veo 
inconvenientes, pero no estoy muy ducho con estos (disculpas porque es 
bastante larga)...



Chain INPUT (policy DROP)
target prot opt source   destination
ufw-before-logging-input  all  --  anywhere anywhere
ufw-before-input  all  --  anywhere anywhere
ufw-after-input  all  --  anywhere anywhere
ufw-after-logging-input  all  --  anywhere anywhere
ufw-reject-input  all  --  anywhere anywhere
ufw-track-input  all  --  anywhere anywhere

Chain FORWARD (policy DROP)
target prot opt source   destination
ufw-before-logging-forward  all  --  anywhere anywhere 


ufw-before-forward  all  --  anywhere anywhere
ufw-after-forward  all  --  anywhere anywhere
ufw-after-logging-forward  all  --  anywhere anywhere 


ufw-reject-forward  all  --  anywhere anywhere
ufw-track-forward  all  --  anywhere anywhere

Chain OUTPUT (policy ACCEPT)
target prot opt source   destination
ufw-before-logging-output  all  --  anywhere anywhere 


ufw-before-output  all  --  anywhere anywhere
ufw-after-output  all  --  anywhere anywhere
ufw-after-logging-output  all  --  anywhere anywhere
ufw-reject-output  all  --  anywhere anywhere
ufw-track-output  all  --  anywhere anywhere

Chain ufw-after-forward (1 references)
target prot opt source   destination

Chain ufw-after-input (1 references)
target prot opt source   destination
ufw-skip-to-policy-input  udp  --  anywhere anywhere 
 udp dpt:netbios-ns
ufw-skip-to-policy-input  udp  --  anywhere anywhere 
 udp dpt:netbios-dgm
ufw-skip-to-policy-input  tcp  --  anywhere anywhere 
 tcp dpt:netbios-ssn
ufw-skip-to-policy-input  tcp  --  anywhere anywhere 
 tcp dpt:microsoft-ds
ufw-skip-to-policy-input  udp  --  anywhere anywhere 
 udp dpt:bootps
ufw-skip-to-policy-input  udp  --  anywhere anywhere 
 udp dpt:bootpc
ufw-skip-to-policy-input  all  --  anywhere anywhere 
 ADDRTYPE match dst-type BROADCAST


Chain ufw-after-logging-forward (1 references)
target prot opt source   destination
LOGall  --  anywhere anywhere limit: avg 
3/min burst 10 LOG level warning prefix "[UFW BLOCK] "


Chain ufw-after-logging-input (1 references)
target prot opt source   destination

Chain ufw-after-logging-output (1 references)
target prot opt source   destination

Chain ufw-after-output (1 references)
target prot opt source   destination

Chain ufw-before-forward (1 references)
target prot opt source   destination
ACCEPT all  --  anywhere anywhere ctstate 
RELATED,ESTABLISHED
ACCEPT icmp --  anywhere anywhere icmp 
destination-unreachable
ACCEPT icmp --  anywhere anywhere icmp 
time-exceeded
ACCEPT icmp --  anywhere anywhere icmp 
parameter-problem
ACCEPT icmp --  anywhere anywhere icmp 
echo-request

ufw-user-forward  all  --  anywhere anywhere

Chain ufw-before-input (1 references)
target prot opt source   destination
ACCEPT all  --  anywhere anywhere
ACCEPT all  --  anywhere anywhere ctstate 
RELATED,ESTABLISHED
ufw-logging-deny  all  --  anywhere anywhere 
ctstate INVALID
DROP   all  --  anywhere anywhere ctstate 
INVALID
ACCEPT icmp --  anywhere anywhere icmp 
destination-unreachable
ACCEPT icmp --  anywhere anywhere icmp 
time-exceeded
ACCEPT icmp --  anywhere anywhere icmp 
parameter-problem
ACCEPT icmp --  anywhere anywhere

Re: ssh no conecta (Bullseye en ambos equipos)

2021-05-17 Por tema Walter Omar Dari





El 17/5/21 a las 13:12, Camaleón escribió:

El 2021-05-17 a las 12:37 -0300, Walter Omar Dari escribió:


El 16/5/21 a las 03:52, Camaleón escribió:

debug2: ssh_connect_direct
debug1: Connecting to 192.168.0.8 [192.168.0.8] port 22.

... después de un rato da un error de timeout.


Un error de timeout apunta a que el anfitrión (el equipo al que
conectas) corta la conexión por algún motivo (directiva de seguridad,
etc.); si llegas con un ping al equipo, así a bote pronto el cortafuegos
quedaría descartado.


El ping me responde inmediatamente...

$ ping 192.168.0.8
PING 192.168.0.8 (192.168.0.8) 56(84) bytes of data.
64 bytes from 192.168.0.8: icmp_seq=1 ttl=64 time=0.344 ms
64 bytes from 192.168.0.8: icmp_seq=2 ttl=64 time=0.330 ms
64 bytes from 192.168.0.8: icmp_seq=3 ttl=64 time=0.338 ms
64 bytes from 192.168.0.8: icmp_seq=4 ttl=64 time=0.331 ms
^C


Hum... prueba con una traza, aunque me temo que no proporcionará mucha más
información:

traceroute -T -O info -p 22 192.168.0.8


Te detallo algunas otras cosas que hice (sugerencias de Zeque), al final
está la traza...

/home/sw/Uso_compartido/temp/ssh_noconecta2.txt   [BM--]  9 L:[  1+26 27/
56] *(775 /1070b) 0010 0x00A [*][X]
1)  en el equipo que no permite las conexiones (192.168.0.8)...

root@debbns:~# iptables -L
bash: iptables: orden no encontrada

root@debbns:~# dpkg -l | grep iptables
ii  iptables1.8.7-1  amd64administration tools for packet
filtering and NAT


?

Prueba con:
#su - -c "iptables -L"


hosts.allow y hosts.deny  están vacíos (salvo las lìneas comentadas al
principio), no hay direcciones IP ni nombres de hosts.

Probé agregando la línea...

ALL : ALL : allow

... en hosts.allow, pero tampoco da resultados.


2) en cualquier equipo que se quiera conectar a 192.168.0.8...

dari@debwal:~$ nc -vvv 192.168.0.8 22
^C sent 0, rcvd 0

root@debwal:/home/dari# traceroute -T -O info -p 22 192.168.0.8
traceroute to 192.168.0.8 (192.168.0.8), 30 hops max, 60 byte packets
  1  * * *
  2  * * *


(...)

No llega.


Si la conexión fuera entre redes distintas (remotas), pasando el
tráfico por distintos servidores y enrutadores que no están bajo tu
supervisión, podría entenderse el timeout por algún filtro de los ISP,
el tamaño de los paquetes o cortafuegos, pero teniendo controlado el
entorno de conexión (red local) el tiemout es todo un misterio :-?

Si tienes otro equipo desde donde probar (p. j., otro sistema operativo
como Windows con Putty o MacOS), intenta a ver, no vaya a ser que la
guerra te la esté dando el cliente desde donde conectas.


He probado desde otros equipos con Debian y el resultado es el mismo.
El tema tiene que estar en el huraño 192.168.0.8 :-)

A ese equipo lo actualicé, no fue una instalación desde cero, anteriormente
tenía Buster, así que le modifiqué el sources.list reemplazando buster por
bullseye. La actualización no dio problemas.

Voy a ver si encuentro alguna portátil a la que le haya quedado un dual boot
con Windows para probar con Putty

Gracias !


Sólo por curiosidad... ¿has probado a intentar conectarte a otro
servicio/puerto que no sea SSH? P. ej., servidor de correo sin cifrado
(110/25) o cualquier otro que puedas tener configurado en ese equipo.

Lo digo para descartar un problema localizado en ese servicio/
aplicativo/puerto o para confirmar que se trata de un problema
generalizado que afecta a otra combinación de servicios y puertos.



Acabo de instalarle Apache y no responde, solamente funciona de modo local.

Lo raro que responde al ping...




Saludos,



--

Walter O. Dari

http://swcomputacion.com/
http://swcomputacion.com/sistemas/
https://facebook.com/swcomputacion/
https://facebook.com/sistemasSW/

Nuestros horarios:
L a V 8 a 13 hs.
S 11 a 14 hs.

WhatsApp:
2396 577140 (no se atienden llamadas)

Re: ssh no conecta (Bullseye en ambos equipos)

2021-05-17 Por tema Camaleón

El 2021-05-17 a las 12:37 -0300, Walter Omar Dari escribió:

> El 16/5/21 a las 03:52, Camaleón escribió:
> > > > > debug2: ssh_connect_direct
> > > > > debug1: Connecting to 192.168.0.8 [192.168.0.8] port 22.
> > > > > 
> > > > > ... después de un rato da un error de timeout.
> > > > 
> > > > Un error de timeout apunta a que el anfitrión (el equipo al que
> > > > conectas) corta la conexión por algún motivo (directiva de seguridad,
> > > > etc.); si llegas con un ping al equipo, así a bote pronto el cortafuegos
> > > > quedaría descartado.
> > > 
> > > El ping me responde inmediatamente...
> > > 
> > > $ ping 192.168.0.8
> > > PING 192.168.0.8 (192.168.0.8) 56(84) bytes of data.
> > > 64 bytes from 192.168.0.8: icmp_seq=1 ttl=64 time=0.344 ms
> > > 64 bytes from 192.168.0.8: icmp_seq=2 ttl=64 time=0.330 ms
> > > 64 bytes from 192.168.0.8: icmp_seq=3 ttl=64 time=0.338 ms
> > > 64 bytes from 192.168.0.8: icmp_seq=4 ttl=64 time=0.331 ms
> > > ^C
> > 
> > Hum... prueba con una traza, aunque me temo que no proporcionará mucha más
> > información:
> > 
> > traceroute -T -O info -p 22 192.168.0.8
> 
> Te detallo algunas otras cosas que hice (sugerencias de Zeque), al final
> está la traza...
> 
> /home/sw/Uso_compartido/temp/ssh_noconecta2.txt   [BM--]  9 L:[  1+26 27/
> 56] *(775 /1070b) 0010 0x00A [*][X]
> 1)  en el equipo que no permite las conexiones (192.168.0.8)...
> 
> root@debbns:~# iptables -L
> bash: iptables: orden no encontrada
> 
> root@debbns:~# dpkg -l | grep iptables
> ii  iptables1.8.7-1  amd64administration tools for packet
> filtering and NAT

?

Prueba con:
#su - -c "iptables -L"

> hosts.allow y hosts.deny  están vacíos (salvo las lìneas comentadas al
> principio), no hay direcciones IP ni nombres de hosts.
> 
> Probé agregando la línea...
> 
> ALL : ALL : allow
> 
> ... en hosts.allow, pero tampoco da resultados.
> 
> 
> 2) en cualquier equipo que se quiera conectar a 192.168.0.8...
> 
> dari@debwal:~$ nc -vvv 192.168.0.8 22
> ^C sent 0, rcvd 0
> 
> root@debwal:/home/dari# traceroute -T -O info -p 22 192.168.0.8
> traceroute to 192.168.0.8 (192.168.0.8), 30 hops max, 60 byte packets
>  1  * * *
>  2  * * *

(...)

No llega.

> > Si la conexión fuera entre redes distintas (remotas), pasando el
> > tráfico por distintos servidores y enrutadores que no están bajo tu
> > supervisión, podría entenderse el timeout por algún filtro de los ISP,
> > el tamaño de los paquetes o cortafuegos, pero teniendo controlado el
> > entorno de conexión (red local) el tiemout es todo un misterio :-?
> > 
> > Si tienes otro equipo desde donde probar (p. j., otro sistema operativo
> > como Windows con Putty o MacOS), intenta a ver, no vaya a ser que la
> > guerra te la esté dando el cliente desde donde conectas.
> 
> He probado desde otros equipos con Debian y el resultado es el mismo.
> El tema tiene que estar en el huraño 192.168.0.8 :-)
> 
> A ese equipo lo actualicé, no fue una instalación desde cero, anteriormente
> tenía Buster, así que le modifiqué el sources.list reemplazando buster por
> bullseye. La actualización no dio problemas.
> 
> Voy a ver si encuentro alguna portátil a la que le haya quedado un dual boot
> con Windows para probar con Putty
> 
> Gracias !

Sólo por curiosidad... ¿has probado a intentar conectarte a otro 
servicio/puerto que no sea SSH? P. ej., servidor de correo sin cifrado 
(110/25) o cualquier otro que puedas tener configurado en ese equipo.

Lo digo para descartar un problema localizado en ese servicio/
aplicativo/puerto o para confirmar que se trata de un problema 
generalizado que afecta a otra combinación de servicios y puertos.

Saludos,

-- 
Camaleón

Re: ssh no conecta (Bullseye en ambos equipos)

2021-05-17 Por tema OddieX

El lun., 17 de mayo de 2021 12:48, Walter Omar Dari 
escribió:

> Hola, lo que me faltaba probar...
>
> El 16/5/21 a las 03:52, Camaleón escribió:
> > El 2021-05-15 a las 19:56 -0300, Walter Omar Dari escribió:
> >
> > [...]
> >
> >
> > Si tienes otro equipo desde donde probar (p. j., otro sistema operativo
> > como Windows con Putty o MacOS), intenta a ver, no vaya a ser que la
> > guerra te la esté dando el cliente desde donde conectas.
>
> Con Putty tampoco se conecta al equipo en cuestión, a los demás no hay
> problemas.
>
>
> >
> > Saludos,
> >
>
> --
>
> Walter O. Dari
>
> http://swcomputacion.com/
> http://swcomputacion.com/sistemas/
> https://facebook.com/swcomputacion/
> https://facebook.com/sistemasSW/
>
> Nuestros horarios:
> L a V 8 a 13 hs.
> S 11 a 14 hs.
>
> WhatsApp:
> 2396 577140 (no se atienden llamadas)
>
>
>
> Fijate en login.Defs q no encuentra iptables pq desde buster en adelante
> cambiaron los env path... Sino whereis iptables y ejecutalo con path
> completo...

Re: ssh no conecta (Bullseye en ambos equipos)

2021-05-17 Por tema Walter Omar Dari


Hola, lo que me faltaba probar...

El 16/5/21 a las 03:52, Camaleón escribió:

El 2021-05-15 a las 19:56 -0300, Walter Omar Dari escribió:

[...] 



Si tienes otro equipo desde donde probar (p. j., otro sistema operativo
como Windows con Putty o MacOS), intenta a ver, no vaya a ser que la
guerra te la esté dando el cliente desde donde conectas.


Con Putty tampoco se conecta al equipo en cuestión, a los demás no hay 
problemas.





Saludos,



--

Walter O. Dari

http://swcomputacion.com/
http://swcomputacion.com/sistemas/
https://facebook.com/swcomputacion/
https://facebook.com/sistemasSW/

Nuestros horarios:
L a V 8 a 13 hs.
S 11 a 14 hs.

WhatsApp:
2396 577140 (no se atienden llamadas)

Re: ssh no conecta (Bullseye en ambos equipos)

2021-05-17 Por tema Walter Omar Dari


Hola...

El 16/5/21 a las 03:52, Camaleón escribió:

El 2021-05-15 a las 19:56 -0300, Walter Omar Dari escribió:


Hola Camaleón, cómo va ?...


:-)


El 15/5/21 a las 14:27, Camaleón escribió:

Además d elo que te han comentado, revisa las opciones de configuración
de SSH en el sistema donde has puesto testing, quizá alguna opción te
esté dando guerra.



Los archivos de configuración, los contenidos en /etc/ssh/ son prácticamente
idénticos en los dos equipos, salvo los archivos .key


Ok...


debug2: ssh_connect_direct
debug1: Connecting to 192.168.0.8 [192.168.0.8] port 22.

... después de un rato da un error de timeout.


Un error de timeout apunta a que el anfitrión (el equipo al que
conectas) corta la conexión por algún motivo (directiva de seguridad,
etc.); si llegas con un ping al equipo, así a bote pronto el cortafuegos
quedaría descartado.


El ping me responde inmediatamente...

$ ping 192.168.0.8
PING 192.168.0.8 (192.168.0.8) 56(84) bytes of data.
64 bytes from 192.168.0.8: icmp_seq=1 ttl=64 time=0.344 ms
64 bytes from 192.168.0.8: icmp_seq=2 ttl=64 time=0.330 ms
64 bytes from 192.168.0.8: icmp_seq=3 ttl=64 time=0.338 ms
64 bytes from 192.168.0.8: icmp_seq=4 ttl=64 time=0.331 ms
^C


Hum... prueba con una traza, aunque me temo que no proporcionará mucha más
información:

traceroute -T -O info -p 22 192.168.0.8


Te detallo algunas otras cosas que hice (sugerencias de Zeque), al final 
está la traza...


/home/sw/Uso_compartido/temp/ssh_noconecta2.txt   [BM--]  9 L:[  1+26 
27/ 56] *(775 /1070b) 0010 0x00A 
[*][X]

1)  en el equipo que no permite las conexiones (192.168.0.8)...

root@debbns:~# iptables -L
bash: iptables: orden no encontrada

root@debbns:~# dpkg -l | grep iptables
ii  iptables1.8.7-1  amd64administration tools for 
packet filtering and NAT


hosts.allow y hosts.deny  están vacíos (salvo las lìneas comentadas al 
principio), no hay direcciones IP ni nombres de hosts.


Probé agregando la línea...

ALL : ALL : allow

... en hosts.allow, pero tampoco da resultados.


2) en cualquier equipo que se quiera conectar a 192.168.0.8...

dari@debwal:~$ nc -vvv 192.168.0.8 22
^C sent 0, rcvd 0

root@debwal:/home/dari# traceroute -T -O info -p 22 192.168.0.8
traceroute to 192.168.0.8 (192.168.0.8), 30 hops max, 60 byte packets
 1  * * *
 2  * * *
 3  * * *
 4  * * *
 5  * * *
 6  * * *
 7  * * *
 8  * * *
 9  * * *
10  * * *
11  * * *
12  * * *
13  * * *
14  * * *
15  * * *
16  * * *
17  * * *
18  * * *
19  * * *
20  * * *
21  * * *
22  * * *
23  * * *
24  * * *
25  * * *
26  * * *
27  * * *
28  * * *
29  * * *
30  * * *
root@debwal:/home/dari#






Prueba a conectarte desde el propio equipo (ssh root@localhost).


Conecta perfectamente


Me desorienta que no me de algún mensaje más, alguna pista en el modo
"verbose"...


Si la conexión fuera entre redes distintas (remotas), pasando el
tráfico por distintos servidores y enrutadores que no están bajo tu
supervisión, podría entenderse el timeout por algún filtro de los ISP,
el tamaño de los paquetes o cortafuegos, pero teniendo controlado el
entorno de conexión (red local) el tiemout es todo un misterio :-?

Si tienes otro equipo desde donde probar (p. j., otro sistema operativo
como Windows con Putty o MacOS), intenta a ver, no vaya a ser que la
guerra te la esté dando el cliente desde donde conectas.


He probado desde otros equipos con Debian y el resultado es el mismo.
El tema tiene que estar en el huraño 192.168.0.8 :-)

A ese equipo lo actualicé, no fue una instalación desde cero, 
anteriormente tenía Buster, así que le modifiqué el sources.list 
reemplazando buster por bullseye. La actualización no dio problemas.


Voy a ver si encuentro alguna portátil a la que le haya quedado un dual 
boot con Windows para probar con Putty


Gracias !




Saludos,



Saludos,

--

Walter O. Dari

http://swcomputacion.com/
http://swcomputacion.com/sistemas/
https://facebook.com/swcomputacion/
https://facebook.com/sistemasSW/

Nuestros horarios:
L a V 8 a 13 hs.
S 11 a 14 hs.

WhatsApp:
2396 577140 (no se atienden llamadas)

Re: ssh no conecta (Bullseye en ambos equipos)

2021-05-17 Por tema Walter Omar Dari


Hola Zeque...

El 15/5/21 a las 20:53, Zeque escribió:

Walter,

Es raro lo del timeout, probaste hacer un telnet al puerto?
nc -v 192.168.0.8 22



Revistaste el archivo hosts.deny hosts.allow que nada haya cambiado?



Chequea también las reglas de firewall
iptables -L


Te dejo los resultados más uno que me sugirió Camaleon


1)  en el equipo que no permite las conexiones (192.168.0.8)...

root@debbns:~# iptables -L
bash: iptables: orden no encontrada

root@debbns:~# dpkg -l | grep iptables
ii  iptables1.8.7-1  amd64administration tools for 
packet filtering and NAT


hosts.allow y hosts.deny  están vacíos (salvo las lìneas comentadas al 
principio), no hay direcciones IP ni nombres de hosts.


Probé agregando la línea...

ALL : ALL : allow

... en hosts.allow, pero tampoco da resultados.


2) en cualquier equipo que se quiera conectar a 192.168.0.8...

dari@debwal:~$ nc -vvv 192.168.0.8 22
^C sent 0, rcvd 0

root@debwal:/home/dari# traceroute -T -O info -p 22 192.168.0.8
traceroute to 192.168.0.8 (192.168.0.8), 30 hops max, 60 byte packets
 1  * * *
 2  * * *
 3  * * *
 4  * * *
 5  * * *
 6  * * *
 7  * * *
 8  * * *
 9  * * *
10  * * *
11  * * *
12  * * *
13  * * *
14  * * *
15  * * *
16  * * *
17  * * *
18  * * *
19  * * *
20  * * *
21  * * *
22  * * *
23  * * *
24  * * *
25  * * *
26  * * *
27  * * *
28  * * *
29  * * *
30  * * *
root@debwal:/home/dari#


Saludos,



Saludos!
Zeque

El 15 de mayo de 2021 12:49:37 ART, Walter Omar Dari  
escribió:


Hola gente:

Me quiero conectar a un equipo de la red local que antes tenía Buster y
no había problemas, pero no puedo a partir de que le instalé Bullseye.
No se si será por Bullseye u otro motivo.

Cuando quiero conectar queda así...

dari@debwal:~$ ssh 192.168.0.8 -vvv
OpenSSH_8.4p1 Debian-5, OpenSSL 1.1.1k  25 Mar 2021
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: include
/etc/ssh/ssh_config.d/*.conf matched no files
debug1: /etc/ssh/ssh_config line 21: Applying options for *
debug2: resolve_canonicalize: hostname 192.168.0.8 is address
debug3: expanded UserKnownHostsFile '~/.ssh/known_hosts' ->
'/home/wodari/.ssh/known_hosts'
debug3: expanded UserKnownHostsFile '~/.ssh/known_hosts2' ->
'/home/wodari/.ssh/known_hosts2'
debug2: ssh_connect_direct
debug1: Connecting to 192.168.0.8 [192.168.0.8] port 22.

... después de un rato da un error de timeout.


En el equipo al que me quiero conectar, el puerto 22 parece estar bien...

# netstat -plnt
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address   Foreign Address
State   PID/Program name
tcp0  0 127.0.0.1:530.0.0.0:*
LISTEN  652/connmand
tcp0  0 0.0.0.0:22  0.0.0.0:*
LISTEN  586057/sshd: /usr/s
tcp0  0 127.0.0.1:631   0.0.0.0:*
LISTEN  523630/cupsd
tcp0  0 0.0.0.0:44025   0.0.0.0:*
LISTEN  -
tcp0  0 127.0.0.1:250.0.0.0:*
LISTEN  1146/exim4
tcp0  0 0.0.0.0:17500   0.0.0.0:*
LISTEN  581546/dropbox
tcp0  0 127.0.0.1:17600 0.0.0.0:*
LISTEN  581546/dropbox
tcp0  0 127.0.0.1:17603 0.0.0.0:*
LISTEN  581546/dropbox
tcp0  0 0.0.0.0:111 0.0.0.0:*
LISTEN  1/init
tcp6   0  0 :::1716 :::*
LISTEN  580502/kdeconnectd
tcp6   0  0 ::1:53  :::*
LISTEN  652/connmand
tcp6   0  0 :::22   :::*
LISTEN  586057/sshd: /usr/s
tcp6   0  0 ::1:631 :::*
LISTEN  523630/cupsd
tcp6   0  0 :::41785:::*
LISTEN  -
tcp6   0  0 ::1:25  :::*
LISTEN  1146/exim4
tcp6   0  0 :::17500:::*
LISTEN  581546/dropbox
tcp6   0  0 :::111  :::*
LISTEN  1/init

Los archivos de configuración ssh_config y sshd_config están iguales en
los dos equipos, en directorios ssh_config.d y sshd_config.d estàn
vacìos en ambos equipos.

Desde el equipo al cual me quiero comunicar, al mío no tengo problemas,
    ssh conecta sin problemas, el tema es cuando es al revés.

Alguien me puede dar alguna pista ?

Muchas gracias,
-- 


Walter O. Dari

http://swcomputacion.com/ <http://swcomputacion.com/>
http://swcomputacion.com/sistemas/ <http://swcomputacion.com/sistemas/>
https://facebook.com/swcomputacion/
<https://facebook.com/swcomputacion/>
https://facebook.com/sistemasSW/ <https://facebook.com/sistemasSW/>

Nuestros horarios:
L a V 8 a 13 hs.
S 11 a 14 hs.

WhatsApp:
2396 577140 (no se atie

Re: ssh no conecta (Bullseye en ambos equipos)

2021-05-16 Por tema Camaleón

El 2021-05-15 a las 19:56 -0300, Walter Omar Dari escribió:

> Hola Camaleón, cómo va ?...

:-)

> El 15/5/21 a las 14:27, Camaleón escribió:
> > Además d elo que te han comentado, revisa las opciones de configuración
> > de SSH en el sistema donde has puesto testing, quizá alguna opción te
> > esté dando guerra.
> 
> 
> Los archivos de configuración, los contenidos en /etc/ssh/ son prácticamente
> idénticos en los dos equipos, salvo los archivos .key

Ok...

> > > debug2: ssh_connect_direct
> > > debug1: Connecting to 192.168.0.8 [192.168.0.8] port 22.
> > > 
> > > ... después de un rato da un error de timeout.
> > 
> > Un error de timeout apunta a que el anfitrión (el equipo al que
> > conectas) corta la conexión por algún motivo (directiva de seguridad,
> > etc.); si llegas con un ping al equipo, así a bote pronto el cortafuegos
> > quedaría descartado.
> 
> El ping me responde inmediatamente...
> 
> $ ping 192.168.0.8
> PING 192.168.0.8 (192.168.0.8) 56(84) bytes of data.
> 64 bytes from 192.168.0.8: icmp_seq=1 ttl=64 time=0.344 ms
> 64 bytes from 192.168.0.8: icmp_seq=2 ttl=64 time=0.330 ms
> 64 bytes from 192.168.0.8: icmp_seq=3 ttl=64 time=0.338 ms
> 64 bytes from 192.168.0.8: icmp_seq=4 ttl=64 time=0.331 ms
> ^C

Hum... prueba con una traza, aunque me temo que no proporcionará mucha más 
información:

traceroute -T -O info -p 22 192.168.0.8

> > 
> > Prueba a conectarte desde el propio equipo (ssh root@localhost).
> 
> Conecta perfectamente
> 
> 
> Me desorienta que no me de algún mensaje más, alguna pista en el modo
> "verbose"...

Si la conexión fuera entre redes distintas (remotas), pasando el 
tráfico por distintos servidores y enrutadores que no están bajo tu 
supervisión, podría entenderse el timeout por algún filtro de los ISP, 
el tamaño de los paquetes o cortafuegos, pero teniendo controlado el 
entorno de conexión (red local) el tiemout es todo un misterio :-?

Si tienes otro equipo desde donde probar (p. j., otro sistema operativo 
como Windows con Putty o MacOS), intenta a ver, no vaya a ser que la 
guerra te la esté dando el cliente desde donde conectas.

Saludos,

-- 
Camaleón

Re: ssh no conecta (Bullseye en ambos equipos)

2021-05-15 Por tema Zeque

Walter,

 Es raro lo del timeout, probaste hacer un telnet al puerto?
nc -v 192.168.0.8 22
Revistaste el archivo hosts.deny  hosts.allow que nada haya cambiado?
Chequea también las reglas de firewall
iptables -L

Saludos!
Zeque

El 15 de mayo de 2021 12:49:37 ART, Walter Omar Dari  
escribió:
>Hola gente:
>
>Me quiero conectar a un equipo de la red local que antes tenía Buster y 
>no había problemas, pero no puedo a partir de que le instalé Bullseye. 
>No se si será por Bullseye u otro motivo.
>
>Cuando quiero conectar queda así...
>
>dari@debwal:~$ ssh 192.168.0.8 -vvv
>OpenSSH_8.4p1 Debian-5, OpenSSL 1.1.1k  25 Mar 2021
>debug1: Reading configuration data /etc/ssh/ssh_config
>debug1: /etc/ssh/ssh_config line 19: include 
>/etc/ssh/ssh_config.d/*.conf matched no files
>debug1: /etc/ssh/ssh_config line 21: Applying options for *
>debug2: resolve_canonicalize: hostname 192.168.0.8 is address
>debug3: expanded UserKnownHostsFile '~/.ssh/known_hosts' -> 
>'/home/wodari/.ssh/known_hosts'
>debug3: expanded UserKnownHostsFile '~/.ssh/known_hosts2' -> 
>'/home/wodari/.ssh/known_hosts2'
>debug2: ssh_connect_direct
>debug1: Connecting to 192.168.0.8 [192.168.0.8] port 22.
>
>... después de un rato da un error de timeout.
>
>
>En el equipo al que me quiero conectar, el puerto 22 parece estar bien...
>
># netstat -plnt
>Active Internet connections (only servers)
>Proto Recv-Q Send-Q Local Address   Foreign Address 
>State   PID/Program name
>tcp0  0 127.0.0.1:530.0.0.0:* 
>LISTEN  652/connmand
>tcp0  0 0.0.0.0:22  0.0.0.0:* 
>LISTEN  586057/sshd: /usr/s
>tcp0  0 127.0.0.1:631   0.0.0.0:* 
>LISTEN  523630/cupsd
>tcp0  0 0.0.0.0:44025   0.0.0.0:* 
>LISTEN  -
>tcp0  0 127.0.0.1:250.0.0.0:* 
>LISTEN  1146/exim4
>tcp0  0 0.0.0.0:17500   0.0.0.0:* 
>LISTEN  581546/dropbox
>tcp0  0 127.0.0.1:17600 0.0.0.0:* 
>LISTEN  581546/dropbox
>tcp0  0 127.0.0.1:17603 0.0.0.0:* 
>LISTEN  581546/dropbox
>tcp0  0 0.0.0.0:111 0.0.0.0:* 
>LISTEN  1/init
>tcp6   0  0 :::1716 :::* 
>LISTEN  580502/kdeconnectd
>tcp6   0  0 ::1:53  :::* 
>LISTEN  652/connmand
>tcp6   0  0 :::22   :::* 
>LISTEN  586057/sshd: /usr/s
>tcp6   0  0 ::1:631 :::* 
>LISTEN  523630/cupsd
>tcp6   0  0 :::41785:::* 
>LISTEN  -
>tcp6   0  0 ::1:25  :::* 
>LISTEN  1146/exim4
>tcp6   0  0 :::17500:::* 
>LISTEN  581546/dropbox
>tcp6   0  0 :::111  :::* 
>LISTEN  1/init
>
>Los archivos de configuración ssh_config y sshd_config están iguales en 
>los dos equipos, en directorios ssh_config.d y sshd_config.d estàn 
>vacìos en ambos equipos.
>
>Desde el equipo al cual me quiero comunicar, al mío no tengo problemas, 
>ssh conecta sin problemas, el tema es cuando es al revés.
>
>Alguien me puede dar alguna pista ?
>
>Muchas gracias,
>-- 
>
>Walter O. Dari
>
>http://swcomputacion.com/
>http://swcomputacion.com/sistemas/
>https://facebook.com/swcomputacion/
>https://facebook.com/sistemasSW/
>
>Nuestros horarios:
>L a V 8 a 13 hs.
>S 11 a 14 hs.
>
>WhatsApp:
>2396 577140 (no se atienden llamadas)
>

Re: ssh no conecta (Bullseye en ambos equipos)

2021-05-15 Por tema Walter Omar Dari


Hola Camaleón, cómo va ?...

El 15/5/21 a las 14:27, Camaleón escribió:

El 2021-05-15 a las 12:49 -0300, Walter Omar Dari escribió:


Me quiero conectar a un equipo de la red local que antes tenía Buster y no
había problemas, pero no puedo a partir de que le instalé Bullseye. No se si
será por Bullseye u otro motivo.


Además d elo que te han comentado, revisa las opciones de configuración
de SSH en el sistema donde has puesto testing, quizá alguna opción te
esté dando guerra.



Los archivos de configuración, los contenidos en /etc/ssh/ son 
prácticamente idénticos en los dos equipos, salvo los archivos .key



  

Cuando quiero conectar queda así...

dari@debwal:~$ ssh 192.168.0.8 -vvv
OpenSSH_8.4p1 Debian-5, OpenSSL 1.1.1k  25 Mar 2021
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: include /etc/ssh/ssh_config.d/*.conf
matched no files
debug1: /etc/ssh/ssh_config line 21: Applying options for *
debug2: resolve_canonicalize: hostname 192.168.0.8 is address
debug3: expanded UserKnownHostsFile '~/.ssh/known_hosts' ->
'/home/wodari/.ssh/known_hosts'
debug3: expanded UserKnownHostsFile '~/.ssh/known_hosts2' ->
'/home/wodari/.ssh/known_hosts2'
debug2: ssh_connect_direct
debug1: Connecting to 192.168.0.8 [192.168.0.8] port 22.

... después de un rato da un error de timeout.


Un error de timeout apunta a que el anfitrión (el equipo al que
conectas) corta la conexión por algún motivo (directiva de seguridad,
etc.); si llegas con un ping al equipo, así a bote pronto el cortafuegos
quedaría descartado.


El ping me responde inmediatamente...

$ ping 192.168.0.8
PING 192.168.0.8 (192.168.0.8) 56(84) bytes of data.
64 bytes from 192.168.0.8: icmp_seq=1 ttl=64 time=0.344 ms
64 bytes from 192.168.0.8: icmp_seq=2 ttl=64 time=0.330 ms
64 bytes from 192.168.0.8: icmp_seq=3 ttl=64 time=0.338 ms
64 bytes from 192.168.0.8: icmp_seq=4 ttl=64 time=0.331 ms
^C



(...)


Los archivos de configuración ssh_config y sshd_config están iguales en los
dos equipos, en directorios ssh_config.d y sshd_config.d estàn vacìos en
ambos equipos.


¿Y deberían ser iguales? :-?


Los parámetros en los archivos de configuración están iguales, tienen la 
configuración por defecto al instalar Debian Bullseye, no se tocaron en 
ninguno de los dos equipos.



  

Desde el equipo al cual me quiero comunicar, al mío no tengo problemas, ssh
conecta sin problemas, el tema es cuando es al revés.

Alguien me puede dar alguna pista ?


Prueba a conectarte desde el propio equipo (ssh root@localhost).


Conecta perfectamente


Me desorienta que no me de algún mensaje más, alguna pista en el modo 
"verbose"...






Saludos,



--

Walter O. Dari

http://swcomputacion.com/
http://swcomputacion.com/sistemas/
https://facebook.com/swcomputacion/
https://facebook.com/sistemasSW/

Nuestros horarios:
L a V 8 a 13 hs.
S 11 a 14 hs.

WhatsApp:
2396 577140 (no se atienden llamadas)

Re: ssh no conecta (Bullseye en ambos equipos)

2021-05-15 Por tema Walter Omar Dari


Hola...

El 15/5/21 a las 13:55, OddieX escribió:

El sáb, 15 may 2021 a las 13:34, Walter Omar Dari
() escribió:


Hola...

El 15/5/21 a las 13:12, OddieX escribió:



El sáb., 15 de mayo de 2021 12:50, Walter Omar Dari mailto:wlin...@gmail.com>> escribió:

 Hola gente:

 Me quiero conectar a un equipo de la red local que antes tenía Buster y
 no había problemas, pero no puedo a partir de que le instalé Bullseye.
 No se si será por Bullseye u otro motivo.

 [...]




Disculpa! Ahi estoy en la PC! Espero que eliminando ssh y borrando
todo lo viejo y reinstalando se te haya solucionado!



No, desinstalé y purgué las configuraciones, reinstalé y sigo en la 
misma situación.





Saludos!

Offtopic: Mods, sepan discuparme, cambie de cel distinto cliente de
correo y no sabia como hacer reply sin formato!



Saludos,

--

Walter O. Dari

http://swcomputacion.com/
http://swcomputacion.com/sistemas/
https://facebook.com/swcomputacion/
https://facebook.com/sistemasSW/

Nuestros horarios:
L a V 8 a 13 hs.
S 11 a 14 hs.

WhatsApp:
2396 577140 (no se atienden llamadas)

Re: ssh no conecta (Bullseye en ambos equipos)

2021-05-15 Por tema Camaleón

El 2021-05-15 a las 12:49 -0300, Walter Omar Dari escribió:

> Me quiero conectar a un equipo de la red local que antes tenía Buster y no
> había problemas, pero no puedo a partir de que le instalé Bullseye. No se si
> será por Bullseye u otro motivo.

Además d elo que te han comentado, revisa las opciones de configuración 
de SSH en el sistema donde has puesto testing, quizá alguna opción te 
esté dando guerra.
 
> Cuando quiero conectar queda así...
> 
> dari@debwal:~$ ssh 192.168.0.8 -vvv
> OpenSSH_8.4p1 Debian-5, OpenSSL 1.1.1k  25 Mar 2021
> debug1: Reading configuration data /etc/ssh/ssh_config
> debug1: /etc/ssh/ssh_config line 19: include /etc/ssh/ssh_config.d/*.conf
> matched no files
> debug1: /etc/ssh/ssh_config line 21: Applying options for *
> debug2: resolve_canonicalize: hostname 192.168.0.8 is address
> debug3: expanded UserKnownHostsFile '~/.ssh/known_hosts' ->
> '/home/wodari/.ssh/known_hosts'
> debug3: expanded UserKnownHostsFile '~/.ssh/known_hosts2' ->
> '/home/wodari/.ssh/known_hosts2'
> debug2: ssh_connect_direct
> debug1: Connecting to 192.168.0.8 [192.168.0.8] port 22.
> 
> ... después de un rato da un error de timeout.

Un error de timeout apunta a que el anfitrión (el equipo al que 
conectas) corta la conexión por algún motivo (directiva de seguridad, 
etc.); si llegas con un ping al equipo, así a bote pronto el cortafuegos
quedaría descartado.

(...)

> Los archivos de configuración ssh_config y sshd_config están iguales en los
> dos equipos, en directorios ssh_config.d y sshd_config.d estàn vacìos en
> ambos equipos.

¿Y deberían ser iguales? :-?
 
> Desde el equipo al cual me quiero comunicar, al mío no tengo problemas, ssh
> conecta sin problemas, el tema es cuando es al revés.
> 
> Alguien me puede dar alguna pista ?

Prueba a conectarte desde el propio equipo (ssh root@localhost).

Saludos,

-- 
Camaleón

Re: ssh no conecta (Bullseye en ambos equipos)

2021-05-15 Por tema OddieX

El sáb, 15 may 2021 a las 13:34, Walter Omar Dari
() escribió:
>
> Hola...
>
> El 15/5/21 a las 13:12, OddieX escribió:
> >
> >
> > El sáb., 15 de mayo de 2021 12:50, Walter Omar Dari  > <mailto:wlin...@gmail.com>> escribió:
> >
> > Hola gente:
> >
> > Me quiero conectar a un equipo de la red local que antes tenía Buster y
> > no había problemas, pero no puedo a partir de que le instalé Bullseye.
> > No se si será por Bullseye u otro motivo.
> >
> > Cuando quiero conectar queda así...
> >
> > dari@debwal:~$ ssh 192.168.0.8 -vvv
> > OpenSSH_8.4p1 Debian-5, OpenSSL 1.1.1k  25 Mar 2021
> > debug1: Reading configuration data /etc/ssh/ssh_config
> > debug1: /etc/ssh/ssh_config line 19: include
> > /etc/ssh/ssh_config.d/*.conf matched no files
> > debug1: /etc/ssh/ssh_config line 21: Applying options for *
> > debug2: resolve_canonicalize: hostname 192.168.0.8 is address
> > debug3: expanded UserKnownHostsFile '~/.ssh/known_hosts' ->
> > '/home/wodari/.ssh/known_hosts'
> > debug3: expanded UserKnownHostsFile '~/.ssh/known_hosts2' ->
> > '/home/wodari/.ssh/known_hosts2'
> > debug2: ssh_connect_direct
> > debug1: Connecting to 192.168.0.8 [192.168.0.8] port 22.
> >
> > ... después de un rato da un error de timeout.
> >
> >
> > En el equipo al que me quiero conectar, el puerto 22 parece estar
> > bien...
> >
> > # netstat -plnt
> > Active Internet connections (only servers)
> > Proto Recv-Q Send-Q Local Address   Foreign Address
> > State   PID/Program name
> > tcp0  0 127.0.0.1:53 <http://127.0.0.1:53>
> > 0.0.0.0:*
> > LISTEN  652/connmand
> > tcp0  0 0.0.0.0:22 <http://0.0.0.0:22>
> > 0.0.0.0:*
> > LISTEN  586057/sshd: /usr/s
> > tcp0  0 127.0.0.1:631 <http://127.0.0.1:631>
> >   0.0.0.0:*
> > LISTEN  523630/cupsd
> > tcp0  0 0.0.0.0:44025 <http://0.0.0.0:44025>
> >   0.0.0.0:*
> > LISTEN  -
> > tcp0  0 127.0.0.1:25 <http://127.0.0.1:25>
> > 0.0.0.0:*
> > LISTEN  1146/exim4
> > tcp0  0 0.0.0.0:17500 <http://0.0.0.0:17500>
> >   0.0.0.0:*
> > LISTEN  581546/dropbox
> > tcp0  0 127.0.0.1:17600 <http://127.0.0.1:17600>
> >   0.0.0.0:*
> > LISTEN  581546/dropbox
> > tcp0  0 127.0.0.1:17603 <http://127.0.0.1:17603>
> >   0.0.0.0:*
> > LISTEN  581546/dropbox
> > tcp0  0 0.0.0.0:111 <http://0.0.0.0:111>
> >   0.0.0.0:*
> > LISTEN  1/init
> > tcp6   0  0 :::1716 :::*
> > LISTEN  580502/kdeconnectd
> > tcp6   0  0 ::1:53  :::*
> > LISTEN  652/connmand
> > tcp6   0  0 :::22   :::*
> > LISTEN  586057/sshd: /usr/s
> > tcp6   0  0 ::1:631 :::*
> > LISTEN  523630/cupsd
> > tcp6   0  0 :::41785:::*
> > LISTEN  -
> > tcp6   0      0 ::1:25  :::*
> > LISTEN  1146/exim4
> > tcp6   0  0 :::17500:::*
> > LISTEN  581546/dropbox
> > tcp6   0  0 :::111  :::*
> > LISTEN  1/init
> >
> > Los archivos de configuración ssh_config y sshd_config están iguales en
> > los dos equipos, en directorios ssh_config.d y sshd_config.d estàn
> > vacìos en ambos equipos.
> >
> > Desde el equipo al cual me quiero comunicar, al mío no tengo problemas,
> > ssh conecta sin problemas, el tema es cuando es al revés.
> >
> > Alguien me puede dar alguna pista ?
> >
> > Muchas gracias,
> > --
> >
> > Walter O. Dari
> >
> > http://swcomputacion.com/ <http://swcomputacion.com/>
> > http://swcomputacion.com/sistemas/ <http://swcomputacion.com/sistemas/>
> > https://facebook.com/swcomputacion/
> > <https://facebook.com/swcomputacion/>
> > https://facebook.com/sistemasSW/ <https://facebook.com/sistemasSW/>
> >
> > Nuestros horarios:
> > L a V 8 a 13 hs.
> > S 11 a 14 hs.
> >
> > WhatsApp:
> > 2396 577140 (no se atienden llam

Re: ssh no conecta (Bullseye en ambos equipos)

2021-05-15 Por tema Walter Omar Dari


Hola...

El 15/5/21 a las 13:12, OddieX escribió:



El sáb., 15 de mayo de 2021 12:50, Walter Omar Dari <mailto:wlin...@gmail.com>> escribió:


Hola gente:

Me quiero conectar a un equipo de la red local que antes tenía Buster y
no había problemas, pero no puedo a partir de que le instalé Bullseye.
No se si será por Bullseye u otro motivo.

Cuando quiero conectar queda así...

dari@debwal:~$ ssh 192.168.0.8 -vvv
OpenSSH_8.4p1 Debian-5, OpenSSL 1.1.1k  25 Mar 2021
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: include
    /etc/ssh/ssh_config.d/*.conf matched no files
debug1: /etc/ssh/ssh_config line 21: Applying options for *
debug2: resolve_canonicalize: hostname 192.168.0.8 is address
debug3: expanded UserKnownHostsFile '~/.ssh/known_hosts' ->
'/home/wodari/.ssh/known_hosts'
debug3: expanded UserKnownHostsFile '~/.ssh/known_hosts2' ->
'/home/wodari/.ssh/known_hosts2'
debug2: ssh_connect_direct
debug1: Connecting to 192.168.0.8 [192.168.0.8] port 22.

... después de un rato da un error de timeout.


En el equipo al que me quiero conectar, el puerto 22 parece estar
bien...

# netstat -plnt
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address
State       PID/Program name
tcp        0      0 127.0.0.1:53 <http://127.0.0.1:53>   
0.0.0.0:*

LISTEN      652/connmand
tcp        0      0 0.0.0.0:22 <http://0.0.0.0:22> 
0.0.0.0:*

LISTEN      586057/sshd: /usr/s
tcp        0      0 127.0.0.1:631 <http://127.0.0.1:631> 
  0.0.0.0:*

LISTEN      523630/cupsd
tcp        0      0 0.0.0.0:44025 <http://0.0.0.0:44025> 
  0.0.0.0:*

LISTEN      -
tcp        0      0 127.0.0.1:25 <http://127.0.0.1:25>   
0.0.0.0:*

LISTEN      1146/exim4
tcp        0      0 0.0.0.0:17500 <http://0.0.0.0:17500> 
  0.0.0.0:*

LISTEN      581546/dropbox
tcp        0      0 127.0.0.1:17600 <http://127.0.0.1:17600>   
  0.0.0.0:*

LISTEN      581546/dropbox
tcp        0      0 127.0.0.1:17603 <http://127.0.0.1:17603>   
  0.0.0.0:*

LISTEN      581546/dropbox
tcp        0      0 0.0.0.0:111 <http://0.0.0.0:111>   
  0.0.0.0:*

LISTEN      1/init
tcp6       0      0 :::1716                 :::*
LISTEN      580502/kdeconnectd
tcp6       0      0 ::1:53                  :::*
LISTEN      652/connmand
tcp6       0      0 :::22                   :::*
LISTEN      586057/sshd: /usr/s
tcp6       0      0 ::1:631                 :::*
LISTEN      523630/cupsd
tcp6       0      0 :::41785                :::*
LISTEN      -
tcp6       0      0 ::1:25                  :::*
LISTEN      1146/exim4
tcp6       0      0 :::17500                :::*
LISTEN      581546/dropbox
tcp6       0      0 :::111                  :::*
LISTEN      1/init

Los archivos de configuración ssh_config y sshd_config están iguales en
los dos equipos, en directorios ssh_config.d y sshd_config.d estàn
vacìos en ambos equipos.

Desde el equipo al cual me quiero comunicar, al mío no tengo problemas,
ssh conecta sin problemas, el tema es cuando es al revés.

Alguien me puede dar alguna pista ?

Muchas gracias,
-- 


Walter O. Dari

http://swcomputacion.com/ <http://swcomputacion.com/>
http://swcomputacion.com/sistemas/ <http://swcomputacion.com/sistemas/>
https://facebook.com/swcomputacion/
<https://facebook.com/swcomputacion/>
https://facebook.com/sistemasSW/ <https://facebook.com/sistemasSW/>

Nuestros horarios:
L a V 8 a 13 hs.
S 11 a 14 hs.

WhatsApp:
2396 577140 (no se atienden llamadas)




1


Probaste apt-get remove --purge ssh e instalar nuevamente apt-get
install ssh?



La verdad no se me ocurrió, después de pasar por varias versiones de 
Debian en la primera vez que me pasa de no tener una pista, ni siquiera 
en los logs.

Voy a probar, si se llega a solucionar lo comento aquí mismo.



Perdon no se si esta sin formato el mensaje estoy con cel nuevo y no le 
cazo la onda aun




No hay problemas, gracias por responder.

Saludos,


--

Walter O. Dari

http://swcomputacion.com/
http://swcomputacion.com/sistemas/
https://facebook.com/swcomputacion/
https://facebook.com/sistemasSW/

Nuestros horarios:
L a V 8 a 13 hs.
S 11 a 14 hs.

WhatsApp:
2396 577140 (no se atienden llamadas)

Re: ssh no conecta (Bullseye en ambos equipos)

2021-05-15 Por tema OddieX

El sáb., 15 de mayo de 2021 12:50, Walter Omar Dari 
escribió:

> Hola gente:
>
> Me quiero conectar a un equipo de la red local que antes tenía Buster y
> no había problemas, pero no puedo a partir de que le instalé Bullseye.
> No se si será por Bullseye u otro motivo.
>
> Cuando quiero conectar queda así...
>
> dari@debwal:~$ ssh 192.168.0.8 -vvv
> OpenSSH_8.4p1 Debian-5, OpenSSL 1.1.1k  25 Mar 2021
> debug1: Reading configuration data /etc/ssh/ssh_config
> debug1: /etc/ssh/ssh_config line 19: include
> /etc/ssh/ssh_config.d/*.conf matched no files
> debug1: /etc/ssh/ssh_config line 21: Applying options for *
> debug2: resolve_canonicalize: hostname 192.168.0.8 is address
> debug3: expanded UserKnownHostsFile '~/.ssh/known_hosts' ->
> '/home/wodari/.ssh/known_hosts'
> debug3: expanded UserKnownHostsFile '~/.ssh/known_hosts2' ->
> '/home/wodari/.ssh/known_hosts2'
> debug2: ssh_connect_direct
> debug1: Connecting to 192.168.0.8 [192.168.0.8] port 22.
>
> ... después de un rato da un error de timeout.
>
>
> En el equipo al que me quiero conectar, el puerto 22 parece estar bien...
>
> # netstat -plnt
> Active Internet connections (only servers)
> Proto Recv-Q Send-Q Local Address   Foreign Address
> State   PID/Program name
> tcp0  0 127.0.0.1:530.0.0.0:*
> LISTEN  652/connmand
> tcp0  0 0.0.0.0:22  0.0.0.0:*
> LISTEN  586057/sshd: /usr/s
> tcp0  0 127.0.0.1:631   0.0.0.0:*
> LISTEN  523630/cupsd
> tcp0  0 0.0.0.0:44025   0.0.0.0:*
> LISTEN  -
> tcp0  0 127.0.0.1:250.0.0.0:*
> LISTEN  1146/exim4
> tcp0  0 0.0.0.0:17500   0.0.0.0:*
> LISTEN  581546/dropbox
> tcp0  0 127.0.0.1:17600 0.0.0.0:*
> LISTEN  581546/dropbox
> tcp0  0 127.0.0.1:17603 0.0.0.0:*
> LISTEN  581546/dropbox
> tcp0  0 0.0.0.0:111 0.0.0.0:*
> LISTEN  1/init
> tcp6   0  0 :::1716 :::*
> LISTEN  580502/kdeconnectd
> tcp6   0  0 ::1:53  :::*
> LISTEN  652/connmand
> tcp6   0  0 :::22   :::*
> LISTEN  586057/sshd: /usr/s
> tcp6   0  0 ::1:631 :::*
> LISTEN  523630/cupsd
> tcp6   0  0 :::41785:::*
> LISTEN  -
> tcp6   0  0 ::1:25  :::*
> LISTEN  1146/exim4
> tcp6   0  0 :::17500:::*
> LISTEN  581546/dropbox
> tcp6   0  0 :::111  :::*
> LISTEN  1/init
>
> Los archivos de configuración ssh_config y sshd_config están iguales en
> los dos equipos, en directorios ssh_config.d y sshd_config.d estàn
> vacìos en ambos equipos.
>
> Desde el equipo al cual me quiero comunicar, al mío no tengo problemas,
> ssh conecta sin problemas, el tema es cuando es al revés.
>
> Alguien me puede dar alguna pista ?
>
> Muchas gracias,
> --
>
> Walter O. Dari
>
> http://swcomputacion.com/
> http://swcomputacion.com/sistemas/
> https://facebook.com/swcomputacion/
> https://facebook.com/sistemasSW/
>
> Nuestros horarios:
> L a V 8 a 13 hs.
> S 11 a 14 hs.
>
> WhatsApp:
> 2396 577140 (no se atienden llamadas)
>
>
>
>
> 1


Probaste apt-get remove --purge ssh e instalar nuevamente apt-get install
ssh?


Perdon no se si esta sin formato el mensaje estoy con cel nuevo y no le
cazo la onda aun

ssh no conecta (Bullseye en ambos equipos)

2021-05-15 Por tema Walter Omar Dari


Hola gente:

Me quiero conectar a un equipo de la red local que antes tenía Buster y 
no había problemas, pero no puedo a partir de que le instalé Bullseye. 
No se si será por Bullseye u otro motivo.


Cuando quiero conectar queda así...

dari@debwal:~$ ssh 192.168.0.8 -vvv
OpenSSH_8.4p1 Debian-5, OpenSSL 1.1.1k  25 Mar 2021
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: include 
/etc/ssh/ssh_config.d/*.conf matched no files

debug1: /etc/ssh/ssh_config line 21: Applying options for *
debug2: resolve_canonicalize: hostname 192.168.0.8 is address
debug3: expanded UserKnownHostsFile '~/.ssh/known_hosts' -> 
'/home/wodari/.ssh/known_hosts'
debug3: expanded UserKnownHostsFile '~/.ssh/known_hosts2' -> 
'/home/wodari/.ssh/known_hosts2'

debug2: ssh_connect_direct
debug1: Connecting to 192.168.0.8 [192.168.0.8] port 22.

... después de un rato da un error de timeout.


En el equipo al que me quiero conectar, el puerto 22 parece estar bien...

# netstat -plnt
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address   Foreign Address 
State   PID/Program name
tcp0  0 127.0.0.1:530.0.0.0:* 
LISTEN  652/connmand
tcp0  0 0.0.0.0:22  0.0.0.0:* 
LISTEN  586057/sshd: /usr/s
tcp0  0 127.0.0.1:631   0.0.0.0:* 
LISTEN  523630/cupsd
tcp0  0 0.0.0.0:44025   0.0.0.0:* 
LISTEN  -
tcp0  0 127.0.0.1:250.0.0.0:* 
LISTEN  1146/exim4
tcp0  0 0.0.0.0:17500   0.0.0.0:* 
LISTEN  581546/dropbox
tcp0  0 127.0.0.1:17600 0.0.0.0:* 
LISTEN  581546/dropbox
tcp0  0 127.0.0.1:17603 0.0.0.0:* 
LISTEN  581546/dropbox
tcp0  0 0.0.0.0:111 0.0.0.0:* 
LISTEN  1/init
tcp6   0  0 :::1716 :::* 
LISTEN  580502/kdeconnectd
tcp6   0  0 ::1:53  :::* 
LISTEN  652/connmand
tcp6   0  0 :::22   :::* 
LISTEN  586057/sshd: /usr/s
tcp6   0  0 ::1:631 :::* 
LISTEN  523630/cupsd
tcp6   0  0 :::41785:::* 
LISTEN  -
tcp6   0  0 ::1:25  :::* 
LISTEN  1146/exim4
tcp6   0  0 :::17500:::* 
LISTEN  581546/dropbox
tcp6   0  0 :::111  :::* 
LISTEN  1/init


Los archivos de configuración ssh_config y sshd_config están iguales en 
los dos equipos, en directorios ssh_config.d y sshd_config.d estàn 
vacìos en ambos equipos.


Desde el equipo al cual me quiero comunicar, al mío no tengo problemas, 
ssh conecta sin problemas, el tema es cuando es al revés.


Alguien me puede dar alguna pista ?

Muchas gracias,
--

Walter O. Dari

http://swcomputacion.com/
http://swcomputacion.com/sistemas/
https://facebook.com/swcomputacion/
https://facebook.com/sistemasSW/

Nuestros horarios:
L a V 8 a 13 hs.
S 11 a 14 hs.

WhatsApp:
2396 577140 (no se atienden llamadas)

Re: LibreOffice no abre por SSH.

2020-12-01 Por tema Jose Ab bA

Roberto:

Desde LibreOffice: Archivo, abrir remoto, etc... na de na, no rula.
Desde culaquier terminal: ssh user@192.168.1.2 \ lowriter
/home/usuario/Documents/archivo.odt... tampoco va.
Desde cualquier terminal: lowriter
use@192.168.1.2/home/usuario/Documents/archivo.odt... tampo va.

La solucion me la acaba de dar Camaleon:

apt-get install libreoffice-gnome (me cago en to... si gnome no lo uso pa
na y no lo quiero!).

Se han iinstalado dos paquetes:
libreoffice-gnome libreoffice-style-elementary

Ahora rula como deberia... Genial!

Voy a ver si me cepillo el libreoffice-gnome y solo con
libreoffice-style-elementary rula bien...

...Me lo he cepillao y no rula osease que hay que tenerlo instalado.


Muchas gracias de nuevo a los dos!

Y a todo el resto de la lista por hacer del software libre mas libre aun!

El mar, 1 dic 2020 a las 17:55, Jose Ab bA () escribió:

> Hola otra vez!
>
> Siempre accedo al servidor desde el escritorio de Mate.
>
> 1. Creo una conexion asi:
> Barra de menu (la tradicional) -> Lugares -> Conectar con el servidor ->
> (configuras la ip servidor, ssh, etc.).
>
> Con esto genero un marcador en el navegador de archivos de Mate (en caja).
>
> 2. En el navegador de archivos pinchas sobre el icono que se acaba de
> crear (en caja) y directamente abre la conexion con el servidor en la la
> direccion que le habia expecificado (por ejemplo /media/sda3/aqui_mismo).
>
> 3. Navegas por los directorios y archivos como si estuvieses en local.
>
> 4. Una vez localizado el archivo que deseas editar le pinchas y
> LibreOffice (en el cliente) intenta abrirlo.
>
> Pero ahi LibreOffice se queda frito, no lo abre.
>
> Algunas veces me toca matarlo con kill o con xkill.
>
> El caso es que al final tengo que copiar del remoto (del servidor) y pegar
> en el local (el cliente) para poder trabajar con el archivo.
>
> Puede ser algo de samba, pero no lo tengo claro, el unico paquete de samba
> que hay instalado tanto en el server como en el cliente es:
> ii  samba-libs:amd64
>
> Oye! Que muchas gracias por el interes prestado y vuestro tiempo!
>
> Y disculpar si se pierde parte de la conversacion, no estoy subscrtio a la
> lista y posteo sobre ella desde gmail respondiendo sobre mi propia consulta.
>
>
> El mar, 1 dic 2020 a las 11:15, Jose Ab bA ()
> escribió:
>
>> Hola de nuevo!
>>
>> Y ya que me he enciscao, vuelvo haceros otra consulta.
>>
>> Resulta que tengo un servidor con un puñao de archivos .odt, .ods, .xml,
>> etc. (los de LibreOffice).
>>
>> Solo puedo acceder al servidor por ssh, y lo hago desde el escritorio
>> (con la caja de Mate).
>>
>> Pero cuando pincho sobre ellos para abrirlos, no se abren directamente.
>>
>> Tengo que descargarmelos, trabajar con ellos localmente y luego volverlos
>> a subir (un fastidio vaya!).
>>
>> Tanto el servidor como el cliente rulan con Buster...
>>
>> Es cosa del cliente?
>> Del servidor?
>> Tengo que configurar algo?
>>
>> En otras distros o versiones previas no recuerdo que me hubiese pasado.
>>
>> De nuevo gracias de antemano!
>>
>

Re: LibreOffice no abre por SSH.

2020-12-01 Por tema Jose Ab bA

Roberto:

Desde LibreOffice: Archivo, abrir remoto, etc... na de na, no rula.
Desde culaquier terminal: ssh user@192.168.1.2 \ lowriter
/home/usuario/Documents/archivo.odt... tampoco va.
Desde cualquier terminal: lowriter
use@192.168.1.2/home/usuario/Documents/archivo.odt... tampo va.

La solucion me la acaba de dar Camaleon:

apt-get install libreoffice-gnome (me cago en to... si gnome no lo uso pa
na y no lo quiero!).

Se han iinstalado dos paquetes:
libreoffice-gnome libreoffice-style-elementary

Ahora rula como deberia... Genial!

Voy a ver si me cepillo el libreoffice-gnome y solo con
libreoffice-style-elementary rula bien...

Muchas gracias de nuevo a los dos!

Y a todo el resto de la lista por hacer del software libre mas libre aun!

El mar, 1 dic 2020 a las 18:22, Roberto C. Sánchez ()
escribió:

> On Tue, Dec 01, 2020 at 05:55:04PM +0100, Jose Ab bA wrote:
> >
> >4. Una vez localizado el archivo que deseas editar le pinchas y
> >LibreOffice (en el cliente) intenta abrirlo.
> >
> >Pero ahi LibreOffice se queda frito, no lo abre.
> >Algunas veces me toca matarlo con kill o con xkill.
> >El caso es que al final tengo que copiar del remoto (del servidor) y
> pegar
> >en el local (el cliente) para poder trabajar con el archivo.
> >
> ¿Y si en lugar de lanzar LibreOffice abriendo el archivo en el
> navegador, que si lo abres por el terminal?:
>
> lowriter /home/usuario/Documents/archivo.odt
>
> (Sustituyendo en lugar de lowriter la aplicación que le corresponde al
> archivo que quieres abrir)
>
> ¿Te resulta algún mensaje que indica el error?
>
> Saludos,
>
> -Roberto
>
> --
> Roberto C. Sánchez
>

Re: LibreOffice no abre por SSH.

2020-12-01 Por tema Camaleón

El 2020-12-01 a las 17:55 +0100, Jose Ab bA escribió:

> Siempre accedo al servidor desde el escritorio de Mate.
> 
> 1. Creo una conexion asi:

(...)

Vale, entonces será una conexión de tipo SFTP.

Pues yo no tengo problemas, me funciona bien. Eso sí, tengo XFCE 
(Thnar) e instalado el LibreOffice oficial, no el que proporciona Debian, 
así como el paquete «libobasis7.0-gnome-integration» para el trabajo 
desde entornos remotos (GIO).

Mira a ver si tienes ese paquete instalado, en Debian se llama 
«libreoffice-gnome».

Saludos,

-- 
Camaleón

Re: LibreOffice no abre por SSH.

2020-12-01 Por tema Roberto C . Sánchez

On Tue, Dec 01, 2020 at 05:55:04PM +0100, Jose Ab bA wrote:
> 
>4. Una vez localizado el archivo que deseas editar le pinchas y
>LibreOffice (en el cliente) intenta abrirlo.
> 
>Pero ahi LibreOffice se queda frito, no lo abre.
>Algunas veces me toca matarlo con kill o con xkill.
>El caso es que al final tengo que copiar del remoto (del servidor) y pegar
>en el local (el cliente) para poder trabajar con el archivo.
> 
¿Y si en lugar de lanzar LibreOffice abriendo el archivo en el
navegador, que si lo abres por el terminal?:

lowriter /home/usuario/Documents/archivo.odt

(Sustituyendo en lugar de lowriter la aplicación que le corresponde al
archivo que quieres abrir)

¿Te resulta algún mensaje que indica el error?

Saludos,

-Roberto

-- 
Roberto C. Sánchez

Re: LibreOffice no abre por SSH.

2020-12-01 Por tema Jose Ab bA

Hola otra vez!

Siempre accedo al servidor desde el escritorio de Mate.

1. Creo una conexion asi:
Barra de menu (la tradicional) -> Lugares -> Conectar con el servidor ->
(configuras la ip servidor, ssh, etc.).

Con esto genero un marcador en el navegador de archivos de Mate (en caja).

2. En el navegador de archivos pinchas sobre el icono que se acaba de crear
(en caja) y directamente abre la conexion con el servidor en la la
direccion que le habia expecificado (por ejemplo /media/sda3/aqui_mismo).

3. Navegas por los directorios y archivos como si estuvieses en local.

4. Una vez localizado el archivo que deseas editar le pinchas y LibreOffice
(en el cliente) intenta abrirlo.

Pero ahi LibreOffice se queda frito, no lo abre.

Algunas veces me toca matarlo con kill o con xkill.

El caso es que al final tengo que copiar del remoto (del servidor) y pegar
en el local (el cliente) para poder trabajar con el archivo.

Puede ser algo de samba, pero no lo tengo claro, el unico paquete de samba
que hay instalado tanto en el server como en el cliente es:
ii  samba-libs:amd64

Oye! Que muchas gracias por el interes prestado y vuestro tiempo!

Y disculpar si se pierde parte de la conversacion, no estoy subscrtio a la
lista y posteo sobre ella desde gmail respondiendo sobre mi propia consulta.


El mar, 1 dic 2020 a las 11:15, Jose Ab bA () escribió:

> Hola de nuevo!
>
> Y ya que me he enciscao, vuelvo haceros otra consulta.
>
> Resulta que tengo un servidor con un puñao de archivos .odt, .ods, .xml,
> etc. (los de LibreOffice).
>
> Solo puedo acceder al servidor por ssh, y lo hago desde el escritorio (con
> la caja de Mate).
>
> Pero cuando pincho sobre ellos para abrirlos, no se abren directamente.
>
> Tengo que descargarmelos, trabajar con ellos localmente y luego volverlos
> a subir (un fastidio vaya!).
>
> Tanto el servidor como el cliente rulan con Buster...
>
> Es cosa del cliente?
> Del servidor?
> Tengo que configurar algo?
>
> En otras distros o versiones previas no recuerdo que me hubiese pasado.
>
> De nuevo gracias de antemano!
>

Re: LibreOffice no abre por SSH.

2020-12-01 Por tema Roberto C . Sánchez

On Tue, Dec 01, 2020 at 11:15:51AM +0100, Jose Ab bA wrote:
>Hola de nuevo!
> 
>Y ya que me he enciscao, vuelvo haceros otra consulta.
> 
>Resulta que tengo un servidor con un puñao de archivos .odt, .ods, .xml,
>etc. (los de LibreOffice).
> 
>Solo puedo acceder al servidor por ssh, y lo hago desde el escritorio (con
>la caja de Mate).
> 
>Pero cuando pincho sobre ellos para abrirlos, no se abren directamente.
> 
>Tengo que descargarmelos, trabajar con ellos localmente y luego volverlos
>a subir (un fastidio vaya!).
> 
>Tanto el servidor como el cliente rulan con Buster...
> 
>Es cosa del cliente?
>Del servidor?
>Tengo que configurar algo?
> 
>En otras distros o versiones previas no recuerdo que me hubiese pasado.
> 
>De nuevo gracias de antemano!

Jose,

¿Es posible que ya tienes LibreOffice abierto a través de otra conexión?
¿Quizás en una sesión física o VNC o hasta otra de SSH?

Descubrí hace muchos años (cuando solo habia OpenOffice.org) que si yo
tenía una ventana de OpenOffice.org abierta en mi computadora y entonces
después yo intentaba abrir otro documento remotamente (por una conexión
de SSH o VNC) que OpenOffice.org no lo habre.  Entonces al regresar
físicamente a la computadora vi que todos los documentos que intenté
abrir por conexión remota estaban ahí abiertos en el mismo escritorio
donde ya tenía abierto el primer documento.  Lo mismo pasaba al entrar
por una conexión SSH y entonces intentar abrir orto documento por otra
conexión SSH.

Es decir, OpenOffice.org (y todos que se derivan del mismo) siempre abre
todas las ventanas en el mismo escritorio.

De lo que yo he podido determinar ha sido de esa manera desde el
principio y nunca se ha arreglado.

Saludos,

-Roberto

-- 
Roberto C. Sánchez

Re: LibreOffice no abre por SSH.

2020-12-01 Por tema Camaleón

El 2020-12-01 a las 11:15 +0100, Jose Ab bA escribió:

> Y ya que me he enciscao, vuelvo haceros otra consulta.
> 
> Resulta que tengo un servidor con un puñao de archivos .odt, .ods, .xml,
> etc. (los de LibreOffice).
> 
> Solo puedo acceder al servidor por ssh, y lo hago desde el escritorio (con
> la caja de Mate).
> 
> Pero cuando pincho sobre ellos para abrirlos, no se abren directamente.

(...)

¿Cómo accedes mediante SSH? Mediante una consola, usas algún cliente 
gráfico, son SFTP, etc...

Accediendo a un recurso samba no me da problemas, de hecho los archivos 
de LO son de los pocos que los puedo abrir directamente desde una 
ubicación remota (me fallan los PDF, por ejemplo).

Saludos,

-- 
Camaleón

LibreOffice no abre por SSH.

2020-12-01 Por tema Jose Ab bA

Hola de nuevo!

Y ya que me he enciscao, vuelvo haceros otra consulta.

Resulta que tengo un servidor con un puñao de archivos .odt, .ods, .xml,
etc. (los de LibreOffice).

Solo puedo acceder al servidor por ssh, y lo hago desde el escritorio (con
la caja de Mate).

Pero cuando pincho sobre ellos para abrirlos, no se abren directamente.

Tengo que descargarmelos, trabajar con ellos localmente y luego volverlos a
subir (un fastidio vaya!).

Tanto el servidor como el cliente rulan con Buster...

Es cosa del cliente?
Del servidor?
Tengo que configurar algo?

En otras distros o versiones previas no recuerdo que me hubiese pasado.

De nuevo gracias de antemano!

Re: [OT] Acceso ssh

2020-10-05 Por tema User

On Mon, 05 Oct 2020 21:01:27 +0200, Ángel wrote:

> On 2020-10-05 at 05:50 +, User wrote:
>> Curioso!
>> 
>> Para probar $ssh -R, instale Openssh-server, en mi Buster, e
>> inmediatamente, tenia peticiones ssh!
>> 
>> Como lo haran?
> 
> Hay bots escaneando continuamente servidores ssh e intentando acceder.
> Para un servidor ssh en el puerto 22, es "normal" ver 1-2
> intentos diarios. Casi todos intentos con el usuario root.
> 
> Un saludo

Si, pero me referia, a que tengo un servidor al que no puedo acceder, de 
fuera de la Lan! Y alguien si puede pasar el router que tiene todos los 
puertos bloqueados, y al que yo no tengo acceso!

Por eso decia, Como lo haran?
Gracias por responder.

Re: [OT] Acceso ssh

2020-10-05 Por tema Ángel

On 2020-10-05 at 05:50 +, User wrote:
> Curioso!
> 
> Para probar $ssh -R, instale Openssh-server, en mi Buster, e 
> inmediatamente, tenia peticiones ssh!
> 
> Como lo haran?

Hay bots escaneando continuamente servidores ssh e intentando acceder.
Para un servidor ssh en el puerto 22, es "normal" ver 1-2
intentos diarios. Casi todos intentos con el usuario root.

Un saludo

Re: [OT] Acceso ssh

2020-10-04 Por tema User

On Fri, 02 Oct 2020 18:39:46 +, User wrote:

> On Fri, 02 Oct 2020 05:31:47 +, Andrés DG wrote:
> 
>> Nmap tendría que devolverte los puertos que se encuentrar abiertos.
>> Salvo que este bloqueado el protocolo ICMP (en ese caso creo que las
>> opciones PS y PA funcionaban para obtener info de los hosts conectados
>> a la red nmap -PS ip_a_consultar  o   nmap -PA ip_a_consultar).
>> En mi caso me pasaba con el router de la oficina, que de buenas a
>> primera no me dejaba acceder de forma remota (a través de una IP
>> pública) al servidor por ssh. Tenía que reiniciarlo para poder acceder
>> de forma remota (desde la red local nunca tenía problemas). Terminé
>> solicitando una IP pública estática y de ahí en más, hasta ahora, no
>> tuve problemas. Aun así, en mi caso, creo que debe haber sido alguna
>> falla del router de la oficina.
>> Perdón que no pueda ayudarte más.
> 
> Me ayudastes, gracias.
> 
> Hice nmap a la Lan, y resulta que es el router el que esta filtrando el
> ssh. Probare a entrar via puerto 80!
> 
> Gracias.

Curioso!

Para probar $ssh -R, instale Openssh-server, en mi Buster, e 
inmediatamente, tenia peticiones ssh!

Como lo haran?

Re: [OT] Acceso ssh

2020-10-02 Por tema User

On Fri, 02 Oct 2020 09:20:19 +0200, Fran Blanco wrote:

> Alguna regla en el host.allow o en el host.deny?
> 
> Puedes acceder desde la Red local? Para descartar problema de
> enrutamiento o nateo en los routers que comentas.
> 
> Entiendo que obviamente has visto que el SSH está en escucha y en que
> puerto.
> 
> Saludos

Ya identifique el problema; el router de entrada filtra ssh por el 22 y 
no puedo cambiarlo; no tengo reglas en host.xxx.

Intentare cambiar el puerto de entrada al 80 en el servidor.

gracias.

Re: [OT] Acceso ssh

2020-10-02 Por tema User

On Fri, 02 Oct 2020 05:31:47 +, Andrés DG wrote:

> Nmap tendría que devolverte los puertos que se encuentrar abiertos.
> Salvo que este bloqueado el protocolo ICMP (en ese caso creo que las
> opciones PS y PA funcionaban para obtener info de los hosts conectados a
> la red nmap -PS ip_a_consultar  o   nmap -PA ip_a_consultar).
> En mi caso me pasaba con el router de la oficina, que de buenas a
> primera no me dejaba acceder de forma remota (a través de una IP
> pública) al servidor por ssh. Tenía que reiniciarlo para poder acceder
> de forma remota (desde la red local nunca tenía problemas). Terminé
> solicitando una IP pública estática y de ahí en más, hasta ahora, no
> tuve problemas. Aun así, en mi caso, creo que debe haber sido alguna
> falla del router de la oficina.
> Perdón que no pueda ayudarte más.

Me ayudastes, gracias.

Hice nmap a la Lan, y resulta que es el router el que esta filtrando el 
ssh. Probare a entrar via puerto 80!

Gracias.

Re: [OT] Acceso ssh

2020-10-02 Por tema Fran Blanco

Alguna regla en el host.allow o en el host.deny?

Puedes acceder desde la Red local? Para descartar problema de enrutamiento
o nateo en los routers que comentas.

Entiendo que obviamente has visto que el SSH está en escucha y en que
puerto.

Saludos

El vie., 2 oct. 2020 9:04, Andrés DG  escribió:

> Nmap tendría que devolverte los puertos que se encuentrar abiertos. Salvo
> que este bloqueado el protocolo ICMP (en ese caso creo que las opciones PS
> y PA funcionaban para obtener info de los hosts conectados a la red nmap
> -PS ip_a_consultar  o   nmap -PA ip_a_consultar).
> En mi caso me pasaba con el router de la oficina, que de buenas a primera
> no me dejaba acceder de forma remota (a través de una IP pública) al
> servidor por ssh. Tenía que reiniciarlo para poder acceder de forma remota
> (desde la red local nunca tenía problemas). Terminé solicitando una IP
> pública estática y de ahí en más, hasta ahora, no tuve problemas. Aun así,
> en mi caso, creo que debe haber sido alguna falla del router de la oficina.
> Perdón que no pueda ayudarte más.
> --
> *De:* user 
> *Enviado:* jueves, 1 de octubre de 2020 21:07
> *Para:* debian-user-spanish@lists.debian.org <
> debian-user-spanish@lists.debian.org>
> *Asunto:* Re: [OT] Acceso ssh
>
>
> On Thu, 01 Oct 2020 20:07:27 +, User wrote:
>
> > Hola:
> >
> > Tengo un servidor que no puedo acceder por IP publica!
> >
> > Anteriormente, habian 2 lineas separadas, y podia conectarme sin
> > problema,
> > via IP publica y/o privada; ahora solo hay 1 linea, con 2 ruteadores, y
> > no puedo acceder por ninguno de los ruteadores, usando la IP publica; si
> > puedo acceder via IP privada!
> >
> > Nmap, no me dice nada; y no aparece el puerto ssh.
> >
> > Alguien tiene idea de cual seria la situacion, por favor?
> >
> > Muchas gracias por su atencion.
>
> Segun veo, el mensaje no esta claro:
> - No tengo acceso a los ruteadoes.
> _ NO es asunto de firewall.
> _ Uso Buster, al dia.
> _ NO tiene nada que ver si la IP, esfija o variable.
>
> Gracias, por las respuestas; y espero que ahora, este mas claro.
>
>

RE: [OT] Acceso ssh

2020-10-02 Por tema Andrés DG

Nmap tendría que devolverte los puertos que se encuentrar abiertos. Salvo que 
este bloqueado el protocolo ICMP (en ese caso creo que las opciones PS y PA 
funcionaban para obtener info de los hosts conectados a la red nmap -PS 
ip_a_consultar  o   nmap -PA ip_a_consultar).
En mi caso me pasaba con el router de la oficina, que de buenas a primera no me 
dejaba acceder de forma remota (a través de una IP pública) al servidor por 
ssh. Tenía que reiniciarlo para poder acceder de forma remota (desde la red 
local nunca tenía problemas). Terminé solicitando una IP pública estática y de 
ahí en más, hasta ahora, no tuve problemas. Aun así, en mi caso, creo que debe 
haber sido alguna falla del router de la oficina.
Perdón que no pueda ayudarte más.

De: user 
Enviado: jueves, 1 de octubre de 2020 21:07
Para: debian-user-spanish@lists.debian.org 

Asunto: Re: [OT] Acceso ssh

On Thu, 01 Oct 2020 20:07:27 +, User wrote:

> Hola:
>
> Tengo un servidor que no puedo acceder por IP publica!
>
> Anteriormente, habian 2 lineas separadas, y podia conectarme sin
> problema,
> via IP publica y/o privada; ahora solo hay 1 linea, con 2 ruteadores, y
> no puedo acceder por ninguno de los ruteadores, usando la IP publica; si
> puedo acceder via IP privada!
>
> Nmap, no me dice nada; y no aparece el puerto ssh.
>
> Alguien tiene idea de cual seria la situacion, por favor?
>
> Muchas gracias por su atencion.

Segun veo, el mensaje no esta claro:
- No tengo acceso a los ruteadoes.
_ NO es asunto de firewall.
_ Uso Buster, al dia.
_ NO tiene nada que ver si la IP, esfija o variable.

Gracias, por las respuestas; y espero que ahora, este mas claro.

Re: [OT] Acceso ssh

2020-10-01 Por tema user



On Thu, 01 Oct 2020 20:07:27 +, User wrote:

> Hola:
> 
> Tengo un servidor que no puedo acceder por IP publica!
> 
> Anteriormente, habian 2 lineas separadas, y podia conectarme sin
> problema,
> via IP publica y/o privada; ahora solo hay 1 linea, con 2 ruteadores, y
> no puedo acceder por ninguno de los ruteadores, usando la IP publica; si
> puedo acceder via IP privada!
> 
> Nmap, no me dice nada; y no aparece el puerto ssh.
> 
> Alguien tiene idea de cual seria la situacion, por favor?
> 
> Muchas gracias por su atencion.

Segun veo, el mensaje no esta claro:
- No tengo acceso a los ruteadoes.
_ NO es asunto de firewall.
_ Uso Buster, al dia.
_ NO tiene nada que ver si la IP, esfija o variable.

Gracias, por las respuestas; y espero que ahora, este mas claro.

[OT] Acceso ssh

2020-10-01 Por tema User

Hola:

Tengo un servidor que no puedo acceder por IP publica!

Anteriormente, habian 2 lineas separadas, y podia conectarme sin problema, 
via IP publica y/o privada; ahora solo hay 1 linea, con 2 ruteadores, y 
no puedo acceder por ninguno de los ruteadores, usando la IP publica; si 
puedo acceder via IP privada!

Nmap, no me dice nada; y no aparece el puerto ssh.

Alguien tiene idea de cual seria la situacion, por favor?

Muchas gracias por su atencion.

Re: [OT] Acceso SSH por Consola a Google Drive.

2020-08-17 Por tema Carlos Dagorret

On Sun, 16 Aug 2020 15:48:05 -0400 Carlos Castillo
 writes:

> El dom., 16 ago. 2020 2:25 p. m., Camaleón  escribió:
>
>  El 2020-08-16 a las 19:57 +0200, Ramses escribió:
>
>  > Estoy montando un script que necesitaría acceder a un fichero.txt 
> compartido en Google Drive, bien para descargarlo, modificarlo y volverlo a 
> subir, o modificarlo directamente en Google Drive.
>  > 

>
> Hay muchas opciones para lograr esto, puedes usar rclone para montar el Drive 
> como un disco local, o puedes usar Python para interactuar con el archivo. Yo 
> he visto esto último para acceder a hojas de cálculo en Google docs.
>
> Es cuestión de ser creativos.

Puedes conseguir montar el sistema de archivos FUSE para utilizar Google
Drive.
Una implementación de FUSE es GCSF, que es rápido en las lectura pues
usa un sistema de cache para ello.
El proyecto se encuentra aquí: https://github.com/harababurel/gcsf

Carlos Dagorret

Re: [OT] Acceso SSH por Consola a Google Drive.

2020-08-16 Por tema Ramses

El 16 de agosto de 2020 21:36:09 CEST, "Matías Herranz" 
 escribió:
>On Sun, Aug 16, 2020, 2:57 PM Ramses  wrote:
>
>> Hola a tod@s,
>>
>> Estoy montando un script que necesitaría acceder a un fichero.txt
>> compartido en Google Drive, bien para descargarlo, modificarlo y
>volverlo a
>> subir, o modificarlo directamente en Google Drive.
>>
>
>Probaste con rclone? https://rclone.org/
>
>Me funcionó bárbaro para hacer cosas al estilo de lo que mencionaste.

Es una opción que voy a ver.

Parece que tiene una opción precompilada que no necesita ser instalada, sólo 
descargar y ejecutar.


Saludos

Re: [OT] Acceso SSH por Consola a Google Drive.

2020-08-16 Por tema Matías Herranz

On Sun, Aug 16, 2020, 2:57 PM Ramses  wrote:

> Hola a tod@s,
>
> Estoy montando un script que necesitaría acceder a un fichero.txt
> compartido en Google Drive, bien para descargarlo, modificarlo y volverlo a
> subir, o modificarlo directamente en Google Drive.
>

Probaste con rclone? https://rclone.org/

Me funcionó bárbaro para hacer cosas al estilo de lo que mencionaste.

Re: [OT] Acceso SSH por Consola a Google Drive.

2020-08-16 Por tema Carlos Castillo

El dom., 16 ago. 2020 2:25 p. m., Camaleón  escribió:

> El 2020-08-16 a las 19:57 +0200, Ramses escribió:
>
> > Estoy montando un script que necesitaría acceder a un fichero.txt
> compartido en Google Drive, bien para descargarlo, modificarlo y volverlo a
> subir, o modificarlo directamente en Google Drive.
> >
> > No sé si algun@ está realizando este tipo de operaciones, me pero
> parece que puede ser algo habitual.
> >
> > ¿Existe alguna forma de hacer esto por Consola, vía SSH o alguna otra
> forma que pueda integrar en mi script?
> >
> > En caso de necesitar alguna aplicación de terceros, ¿alguna que no
> necesite instalación, es decir, que sea descargar, descomprimir y ejecutar,
> sin necesidad de instalarla en el Sistema?
>
> Me temo que para acceder a los servicios de Alphabet, sólo con SSH no te
> va a servir: quieren tu alma, no tus claves cifradas ;-(
>
> Más allá de la cuenta de correo de Gmail, que uso desde Mutt, no tengo
> activado ningún servicio de esta empresa, por lo que poco puedo
> aconsejarte.
>
> Revisa esta lista de aplicaciones, por si alguna te pudiera servir:
>
> Top 12 Best Google Drive Linux Client Software in 2020
> https://www.ubuntupit.com/top-12-best-google-drive-linux-client-software/
>
> Hasta que no saquen un cliente oficial para acceder, y dado que cambian
> continuamente sus sistemas de autentificación, cada vez más complicados
> de seguir, no te extrañe que lo que montes deje de funcionar cada cierto
> tiempo.
>
> Saludos,
>
> --
> Camaleón


Saludos,

Hay muchas opciones para lograr esto, puedes usar rclone para montar el
Drive como un disco local, o puedes usar Python para interactuar con el
archivo. Yo he visto esto último para acceder a hojas de cálculo en Google
docs.

Es cuestión de ser creativos.

Re: [OT] Acceso SSH por Consola a Google Drive.

2020-08-16 Por tema Camaleón

El 2020-08-16 a las 19:57 +0200, Ramses escribió:

> Estoy montando un script que necesitaría acceder a un fichero.txt compartido 
> en Google Drive, bien para descargarlo, modificarlo y volverlo a subir, o 
> modificarlo directamente en Google Drive.
> 
> No sé si algun@ está realizando este tipo de operaciones, me pero parece que 
> puede ser algo habitual.
> 
> ¿Existe alguna forma de hacer esto por Consola, vía SSH o alguna otra forma 
> que pueda integrar en mi script?
> 
> En caso de necesitar alguna aplicación de terceros, ¿alguna que no necesite 
> instalación, es decir, que sea descargar, descomprimir y ejecutar, sin 
> necesidad de instalarla en el Sistema?

Me temo que para acceder a los servicios de Alphabet, sólo con SSH no te
va a servir: quieren tu alma, no tus claves cifradas ;-(

Más allá de la cuenta de correo de Gmail, que uso desde Mutt, no tengo 
activado ningún servicio de esta empresa, por lo que poco puedo 
aconsejarte.

Revisa esta lista de aplicaciones, por si alguna te pudiera servir:

Top 12 Best Google Drive Linux Client Software in 2020
https://www.ubuntupit.com/top-12-best-google-drive-linux-client-software/

Hasta que no saquen un cliente oficial para acceder, y dado que cambian 
continuamente sus sistemas de autentificación, cada vez más complicados 
de seguir, no te extrañe que lo que montes deje de funcionar cada cierto 
tiempo.

Saludos, 

-- 
Camaleón

[OT] Acceso SSH por Consola a Google Drive.

2020-08-16 Por tema Ramses

Hola a tod@s,

Estoy montando un script que necesitaría acceder a un fichero.txt compartido en 
Google Drive, bien para descargarlo, modificarlo y volverlo a subir, o 
modificarlo directamente en Google Drive.

No sé si algun@ está realizando este tipo de operaciones, me pero parece que 
puede ser algo habitual.

¿Existe alguna forma de hacer esto por Consola, vía SSH o alguna otra forma que 
pueda integrar en mi script?

En caso de necesitar alguna aplicación de terceros, ¿alguna que no necesite 
instalación, es decir, que sea descargar, descomprimir y ejecutar, sin 
necesidad de instalarla en el Sistema?


Saludos y gracias

Re: xdmcp y ssh -X

2020-03-11 Por tema Sergio Daniel Gomez


Solo para confirmarte, hay 4 emails con el mismo asunto y mismo remitente.

El 11/03/2020 a las 7:56, TRUJILLO CARMONA ANTONIO escribió:

Es raro, es la tercera vez que envio este correo y parece que no llega,
esta vez lo intento desde otra cuenta.


Estoy usando Debian 10, desde siempre he usado las conexiones gráficas

remotas para gestionar servidores.

También he utilizado ssh -X yo@mipc para trabajo remoto.

Nada de esto funciona ahora, no se desde cuando ni porque, he intentado
reconfigurar gdm con:


[daemon]
# Esto he probado a ponerlo y quitarlo sin diferencia aparente
# WaylandEnable=false

[security]
DisallowTCP=false

[xdmcp]
Enable=true

[chooser]

[debug]

He probado a instalar el xauth sin resultados.

he probado a usar KDE y lxdt He probado a usar sddm sin resultados.

Desde que no funciona gksu utilizo "ssh -X root@localhost" para poder
lanzar aplicaciones gráficas como administrador, esto si sigue funcionando.

En las conexiones no locales de ssh se puede ver:

"X11 forwarding request failed on channel 0"

el fichero .Xauthority no siempre se crea, pero eso creo que depende de
si se usa Wayland o no, de todas formas aunque se cree no funciona y en
Internet dicen que wayland es compatible con las comunicaciones X
remotas sin necesidad de xauth que es especifico de xorg.


Si no se usa wayland ssh -X sigue sin funcionar, pero "xhost +" +
"Display=mi-ip:0" si funciona, pero esto es inseguro porque esta
enviando todo el trafico por fuera del tunel ssh, es decir en plano.


¿Alguna idea para que vuelva a funcionar?

xdmcp y ssh -X

2020-03-11 Por tema TRUJILLO CARMONA ANTONIO

Es raro, es la tercera vez que envio este correo y parece que no llega,
esta vez lo intento desde otra cuenta.


Estoy usando Debian 10, desde siempre he usado las conexiones gráficas

remotas para gestionar servidores.

También he utilizado ssh -X yo@mipc para trabajo remoto.

Nada de esto funciona ahora, no se desde cuando ni porque, he intentado
reconfigurar gdm con:


[daemon]
# Esto he probado a ponerlo y quitarlo sin diferencia aparente
# WaylandEnable=false

[security]
DisallowTCP=false

[xdmcp]
Enable=true

[chooser]

[debug]

He probado a instalar el xauth sin resultados.

he probado a usar KDE y lxdt He probado a usar sddm sin resultados.

Desde que no funciona gksu utilizo "ssh -X root@localhost" para poder
lanzar aplicaciones gráficas como administrador, esto si sigue funcionando.

En las conexiones no locales de ssh se puede ver:

"X11 forwarding request failed on channel 0"

el fichero .Xauthority no siempre se crea, pero eso creo que depende de
si se usa Wayland o no, de todas formas aunque se cree no funciona y en
Internet dicen que wayland es compatible con las comunicaciones X
remotas sin necesidad de xauth que es especifico de xorg.


Si no se usa wayland ssh -X sigue sin funcionar, pero "xhost +" +
"Display=mi-ip:0" si funciona, pero esto es inseguro porque esta
enviando todo el trafico por fuera del tunel ssh, es decir en plano.


¿Alguna idea para que vuelva a funcionar?

xdmcp y ssh -X

2020-03-11 Por tema Antonio Trujillo Carmona



Estoy usando Debian 10, desde siempre he usado las conexiones gráficas
remotas para gestionar servidores.

También he utilizado ssh -X yo@mipc para trabajo remoto.

Nada de esto funciona ahora, no se desde cuando ni porque, he intentado
reconfigurar gdm con:


[daemon]
# Esto he probado a ponerlo y quitarlo sin diferencia aparente
# WaylandEnable=false

[security]
DisallowTCP=false

[xdmcp]
Enable=true

[chooser]

[debug]

He probado a instalar el xauth sin resultados.

he probado a usar KDE y lxdt He probado a usar sddm sin resultados.

Desde que no funciona gksu utilizo "ssh -X root@localhost" para poder
lanzar aplicaciones gráficas como administrador, esto si sigue funcionando.

En las conexiones no locales de ssh se puede ver:

"X11 forwarding request failed on channel 0"

el fichero .Xauthority no siempre se crea, pero eso creo que depende de
si se usa Wayland o no, de todas formas aunque se cree no funciona y en
Internet dicen que wayland es compatible con las comunicaciones X
remotas sin necesidad de xauth que es especifico de xorg.


Si no se usa wayland ssh -X sigue sin funcionar, pero "xhost +" +
"Display=mi-ip:0" si funciona, pero esto es inseguro porque esta
enviando todo el trafico por fuera del tunel ssh, es decir en plano.


¿Alguna idea para que vuelva a funcionar?

xdmcp y ssh -X

2020-03-11 Por tema Antonio Trujillo Carmona

Estoy usando Debian 10, desde siempre he usado las conexiones gráficas
remotas para gestionar servidores.

También he utilizado ssh -X yo@mipc para trabajo remoto.

Nada de esto funciona ahora, no se desde cuando ni porque, he intentado
reconfigurar gdm con:


[daemon]
# Esto he probado a ponerlo y quitarlo sin diferencia aparente
# WaylandEnable=false

[security]
DisallowTCP=false

[xdmcp]
Enable=true

[chooser]

[debug]

He probado a instalar el xauth sin resultados.

he probado a usar KDE y lxdt He probado a usar sddm sin resultados.

Desde que no funciona gksu utilizo "ssh -X root@localhost" para poder
lanzar aplicaciones gráficas como administrador, esto si sigue funcionando.

En las conexiones no locales de ssh se puede ver:

"X11 forwarding request failed on channel 0"

el fichero .Xauthority no siempre se crea, pero eso creo que depende de
si se usa Wayland o no, de todas formas aunque se cree no funciona y en
Internet dicen que wayland es compatible con las comunicaciones X
remotas sin necesidad de xauth que es especifico de xorg.


¿Alguna idea para que vuelva a funcionar?







signature.asc
Description: OpenPGP digital signature

xdmcp y ssh -X

2020-03-09 Por tema Antonio Trujillo Carmona

Estoy usando Debian 10, desde siempre he usado las conexiones gráficas
remotas para gestionar servidores.

También he utilizado ssh -X yo@mipc para trabajo remoto.

Nada de esto funciona ahora, no se desde cuando ni porque, he intentado
reconfigurar gdm con:


[daemon]
# Esto he probado a ponerlo y quitarlo sin diferencia aparente
# WaylandEnable=false

[security]
DisallowTCP=false

[xdmcp]
Enable=true

[chooser]

[debug]

He probado a instalar el xauth sin resultados.

he probado a usar KDE y lxdt He probado a usar sddm sin resultados.

Desde que no funciona gksu utilizo "ssh -X root@localhost" para poder
lanzar aplicaciones gráficas como administrador, esto si sigue funcionando.

En las conexiones no locales de ssh se puede ver:

"X11 forwarding request failed on channel 0"

el fichero .Xauthority no siempre se crea, pero eso creo que depende de
si se usa Wayland o no, de todas formas aunque se cree no funciona y en
Internet dicen que wayland es compatible con las comunicaciones X
remotas sin necesidad de xauth que es especifico de xorg.


¿Alguna idea para que vuelva a funcionar?




signature.asc
Description: OpenPGP digital signature

Re: añadir cron por ssh

2019-11-25 Por tema Paynalton

Si un ave no rompe su huevo morirá antes de nacer.
Nosotros somos el ave y el mundo es nuestro huevo.
POR LA REVOLUCIÓN DEL MUNDO

Ciudad de México


El sáb., 23 nov. 2019 a las 15:04, miguel angel gonzalez (<
mangelgonza...@gmail.com>) escribió:

> Lo tengo configurado y lo utilizo para otras tareas, pero el módulo de
> cron para la versión de ansible que tengo no admite una serie de opciones.
> ¿Ves mal la idea de modificar así el cron de algún usuario?
> Gracias.
>
> El sáb., 23 nov. 2019 21:33, Paynalton  escribió:
>
>>
>>
>> El sáb., 23 de noviembre de 2019 1:28 p. m., miguel angel gonzalez <
>> mangelgonza...@gmail.com> escribió:
>>
>>> Buenas tardes,
>>> necesito añadir un cron a muchas máquinas y estoy mirando opciones:
>>>
>>> ssh -p225 root@192.168.1.20 'echo "0 23 * * shutdown -r now" >>
>>>> /var/spool/cron/crontabs/root'
>>>>
>>>
>>> La opción anterior os parece una buena practica? Me refiero a editar el
>>> fichero de
>>> /var/spool/cron/crontabs/root.
>>>
>>
Habría que juzgar cuales son tus limitaciones.

Si, como en el ejemplo, lo que quieres es que todos los equipos se apaguen
a cierta hora, veo mejor usar un solo cron en un equipo central que envíe
por ansible la orden de apagarse a todos los equipos de la red. Aparte
puedes monitorizar con un snmp si algún equipo ignoró la orden de apagarse
e intentar nuevamente enviar la instrucción antes de reportar al
administrador.


>
>>> Muchas gracias!
>>> Buen día.
>>>
>>> --
>>> /m.a.
>>>
>>
>> Dale una mirada a ansible, está hecho precisamente para realizar tareas
>> automatizadas a través de múltiples servidores.
>>
>>>

Re: añadir cron por ssh

2019-11-23 Por tema miguel angel gonzalez

Lo tengo configurado y lo utilizo para otras tareas, pero el módulo de cron
para la versión de ansible que tengo no admite una serie de opciones. ¿Ves
mal la idea de modificar así el cron de algún usuario?
Gracias.

El sáb., 23 nov. 2019 21:33, Paynalton  escribió:

>
>
> El sáb., 23 de noviembre de 2019 1:28 p. m., miguel angel gonzalez <
> mangelgonza...@gmail.com> escribió:
>
>> Buenas tardes,
>> necesito añadir un cron a muchas máquinas y estoy mirando opciones:
>>
>> ssh -p225 root@192.168.1.20 'echo "0 23 * * shutdown -r now" >>
>>> /var/spool/cron/crontabs/root'
>>>
>>
>> La opción anterior os parece una buena practica? Me refiero a editar el
>> fichero de
>> /var/spool/cron/crontabs/root.
>>
>> Muchas gracias!
>> Buen día.
>>
>> --
>> /m.a.
>>
>
> Dale una mirada a ansible, está hecho precisamente para realizar tareas
> automatizadas a través de múltiples servidores.
>
>>

Re: añadir cron por ssh

2019-11-23 Por tema Paynalton

El sáb., 23 de noviembre de 2019 1:28 p. m., miguel angel gonzalez <
mangelgonza...@gmail.com> escribió:

> Buenas tardes,
> necesito añadir un cron a muchas máquinas y estoy mirando opciones:
>
> ssh -p225 root@192.168.1.20 'echo "0 23 * * shutdown -r now" >>
>> /var/spool/cron/crontabs/root'
>>
>
> La opción anterior os parece una buena practica? Me refiero a editar el
> fichero de
> /var/spool/cron/crontabs/root.
>
> Muchas gracias!
> Buen día.
>
> --
> /m.a.
>

Dale una mirada a ansible, está hecho precisamente para realizar tareas
automatizadas a través de múltiples servidores.

>

añadir cron por ssh

2019-11-23 Por tema miguel angel gonzalez

Buenas tardes,
necesito añadir un cron a muchas máquinas y estoy mirando opciones:

ssh -p225 root@192.168.1.20 'echo "0 23 * * shutdown -r now" >>
> /var/spool/cron/crontabs/root'
>

La opción anterior os parece una buena practica? Me refiero a editar el
fichero de
/var/spool/cron/crontabs/root.

Muchas gracias!
Buen día.

-- 
/m.a.

Re: SSH - web client

2018-05-14 Por tema Alfonso Camacho

https://github.com/liftoff/GateOne

El 14 de mayo de 2018 12:50:20 CEST, Alejandro Jurado 
<alexjuradope...@gmail.com> escribió:
>Hola lista!!!
>
>Alguien conoce un cliente web para hacer conexiones ssh, basicamente
>para acceder a la terminal. Y de ser necesarios los servicios del
>servidor.
>
>Gracias anticipadas.
>Alex J.

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: SSH - web client

2018-05-14 Por tema Alejandro Jurado

Si, es esto!!! Muchas gracias.

El 14 de mayo de 2018 13:01:13 CEST, juansantiago <juansanti...@riseup.net> 
escribió:
>Pues por ejemplo shellinabox, no puedo hablarte de la perdida de 
>seguridad con respecto a conectarte mediante shell pero me sospecho que
>
>se pierde seguridad, hace tiempo lo probé porque un proveedor de host
>lo 
>ofrecía, pero era incomodo por que no permitía copiar y pegar :) , más 
>allá de eso, lo mismo que hacerlo mediante shell de tus sistema. Creo 
>que es mas o menos lo que buscas.
>
>
>El 14/05/18 a las 12:50, Alejandro Jurado escribió:
>> Hola lista!!!
>>
>> Alguien conoce un cliente web para hacer conexiones ssh, basicamente 
>> para acceder a la terminal. Y de ser necesarios los servicios del 
>> servidor.
>>
>> Gracias anticipadas.
>> Alex J. 

-- 
En este mensaje se adjunta (signature.asc) una firma digital que certifica la 
procedencia legitima del mensaje desde mi cuenta de correo eletrónico.

Por favor, firma tus mensajes. Si quieres saber como se hace estaré encantado 
de explicartelo.

Re: SSH - web client

2018-05-14 Por tema juansantiago

Pues por ejemplo shellinabox, no puedo hablarte de la perdida de 
seguridad con respecto a conectarte mediante shell pero me sospecho que 
se pierde seguridad, hace tiempo lo probé porque un proveedor de host lo 
ofrecía, pero era incomodo por que no permitía copiar y pegar :) , más 
allá de eso, lo mismo que hacerlo mediante shell de tus sistema. Creo 
que es mas o menos lo que buscas.



El 14/05/18 a las 12:50, Alejandro Jurado escribió:

Hola lista!!!

Alguien conoce un cliente web para hacer conexiones ssh, basicamente 
para acceder a la terminal. Y de ser necesarios los servicios del 
servidor.


Gracias anticipadas.
Alex J.

SSH - web client

2018-05-14 Por tema Alejandro Jurado

Hola lista!!!

Alguien conoce un cliente web para hacer conexiones ssh, basicamente para 
acceder a la terminal. Y de ser necesarios los servicios del servidor.

Gracias anticipadas.
Alex J.

signature.asc
Description: PGP signature

Re: rsync por ssh

2018-02-28 Por tema rv riveravaldez

2018-02-28 11:58 GMT-03:00 Alberto Luaces <alua...@udc.es>:
> miguel angel gonzalez writes:
>
>> Buenos días,
>> Necesito hacer una tranferencia de muchos datos entre entornos diferentes es 
>> decir, redes diferentes, tengo una máquina con una tarjeta en los dos 
>> entornos. ¿Se os ocurre como hacerlo con rsync?
>> Estoy dándole vueltas a meterlo en un tunel ssh, por eso he creado claves 
>> pública y privada, pero no doy con la idea.
>> Gracias!

Disponiendo de ssh una solución simple es usar sshfs.
Montadas las máquinas se sincroniza como si fuera entre carpetas locales.
Está el tema de velocidad de transmisión y consumo de recursos de la
CPU (sshfs supuestamente es menos eficiente que nfs), pero si no hay
limitaciones muy severas en esos apartados, es una manera simple de
resolverlo al vuelo.
Saludos

Re: rsync por ssh

2018-02-28 Por tema Alberto Luaces

miguel angel gonzalez writes:

> Buenos días,
> Necesito hacer una tranferencia de muchos datos entre entornos diferentes es 
> decir, redes diferentes, tengo una máquina con una tarjeta en los dos 
> entornos. ¿Se os ocurre como hacerlo con rsync?
> Estoy dándole vueltas a meterlo en un tunel ssh, por eso he creado claves 
> pública y privada, pero no doy con la idea.
> Gracias!

Ésta es  la solución completa: haces el túnel y después ordenas a rsync
a pasar por él especificando concretamente cómo invocar a ssh.

https://stackoverflow.com/a/21465177/2658323

-- 
Alberto

Re: rsync por ssh

2018-02-28 Por tema Galvatorix Torixgalva

Hola,

es necesario que sea con rsync?, lo digo porque lo que se me ha ocurrido
ahora mismo es un servidor torrent y en las maquinas cliente un cliente
torrent.

Tambien podrias usar un servidor ftp y clientes ftp.

Saludos




Libre
de virus. www.avast.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

Re: rsync por ssh

2018-02-28 Por tema Ricardo Frydman

Concretamente: cual es la duda?
La primer salida de una busqueda por google, ya te da una punta para
investigar:
http://www.vicente-navarro.com/blog/2008/01/13/backups-con-rsync/

El 28 de febrero de 2018, 9:23, miguel angel gonzalez <
mangelgonza...@gmail.com> escribió:

> Buenos días,
> Necesito hacer una tranferencia de muchos datos entre entornos diferentes
> es decir, redes diferentes, tengo una máquina con una tarjeta en los dos
> entornos. ¿Se os ocurre como hacerlo con rsync?
> Estoy dándole vueltas a meterlo en un tunel ssh, por eso he creado claves
> pública y privada, pero no doy con la idea.
> Gracias!
>
>


-- 
Ricardo A.Frydman
Administrador AIX/RedHat - Avantia operadora de tarjetas
Sun Certified System Administrator - Solaris 10

pgp.mit.edu ID A04134BD
<http://pgp.mit.edu/pks/lookup?op=get=0x0984BAA9A04134BD>


"Aequam memento rebus in arduis servare mentem"

rsync por ssh

2018-02-28 Por tema miguel angel gonzalez

Buenos días,
Necesito hacer una tranferencia de muchos datos entre entornos diferentes
es decir, redes diferentes, tengo una máquina con una tarjeta en los dos
entornos. ¿Se os ocurre como hacerlo con rsync?
Estoy dándole vueltas a meterlo en un tunel ssh, por eso he creado claves
pública y privada, pero no doy con la idea.
Gracias!

Re: [SOLUCIONADO] Conectar desde clientes "enjaulados" vía SSH a MySQL.

2018-01-24 Por tema Ramses II

El día 24 de enero de 2018, 12:48, Cristian Mitchell
<mitchell6...@gmail.com> escribió:
>
>
> El 24 de enero de 2018, 08:45, Ramses<ramses.sevi...@gmail.com> escribió:
>>
>> El 24 de enero de 2018 12:18:02 CET, Cristian Mitchell
>> <mitchell6...@gmail.com> escribió:
>> >El 24 de enero de 2018, 04:55, Ramses II<ramses.sevi...@gmail.com>
>> >escribió:
>> >
>> >> Cristian, buenos días de nuevo,
>> >>
>> >> Bien, por TCP parece que ya funciona:
>> >>
>> >> 
>> >> 
>> >> -bash-4.2$ /usr/bin/mysql -h 127.0.0.1 -u root -p --protocol=tcp
>> >> Enter password:
>> >> Welcome to the MySQL monitor.  Commands end with ; or \g.
>> >> Your MySQL connection id is 46
>> >> Server version: 5.5.59-0+deb7u1 (Debian)
>> >>
>> >> Copyright (c) 2000, 2018, Oracle and/or its affiliates. All rights
>> >> reserved.
>> >>
>> >> Oracle is a registered trademark of Oracle Corporation and/or its
>> >> affiliates. Other names may be trademarks of their respective
>> >> owners.
>> >>
>> >> Type 'help;' or '\h' for help. Type '\c' to clear the current input
>> >> statement.
>> >>
>> >> mysql>
>> >> mysql> quit
>> >> Bye
>> >> -bash-4.2$
>> >> 
>> >> 
>> >>
>> >> Ahora sólo queda ver si hay forma de hacerlo por socket de MySQL.
>> >>
>> >> Si ejecuto en la sesión "enjaulada" el comando que me has comentado:
>> >>
>> >> 
>> >> 
>> >> -bash-4.2$ mount -o bind,noexec /var/run/mysqld/mysqld.sock
>> >> mount: only root can do that
>> >> -bash-4.2$
>> >> 
>> >> 
>> >>
>> >> Lo que te comentaba, que dice que sólo lo puede ejecutar "root".
>> >>
>> >> De cualquier forma, si ejecuto sólo "mount", tampoco va:
>> >>
>> >> 
>> >> 
>> >> -bash-4.2$ mount
>> >> warning: failed to read mtab
>> >> -bash-4.2$
>> >> 
>> >> 
>> >>
>> >>
>> >> Gracias y saludos,
>> >>
>> >> Ramses
>> >>
>> >> El día 24 de enero de 2018, 0:37, Cristian Mitchell
>> >> <mitchell6...@gmail.com> escribió:
>> >> >
>> >> >
>> >> > El 23 de enero de 2018, 20:32, Cristian
>> >Mitchell<mitchell6...@gmail.com>
>> >> > escribió:
>> >> >>
>> >> >>
>> >> >>
>> >> >> El 23 de enero de 2018, 19:40, Ramses<ramses.sevi...@gmail.com>
>> >> escribió:
>> >> >>>
>> >> >>> El 23 de enero de 2018 23:20:09 CET, Cristian Mitchell
>> >> >>> <mitchell6...@gmail.com> escribió:
>> >> >>> >El 23 de enero de 2018, 15:26, Ramses<ramses.sevi...@gmail.com>
>> >> >>> >escribió:
>> >> >>> >
>> >> >>> >> El 23 de enero de 2018 18:24:23 CET, Matias Mucciolo <
>> >> >>> >> mmucci...@suteba.org.ar> escribió:
>> >> >>> >> >On Tuesday, January 23, 2018 5:29:07 PM -03 Ramses wrote:
>> >> >>> >> >> Hola a tod@s,
>> >> >>> >> >>
>> >> >>> >> >> Tengo instalado MySQL Server con su proceso habitual.
>> >> >>> >> >>
>> >> >>> >> >> Ahora quiero dar acceso a Clientes vía SSH, pero no quiero
>> >que
>> >> >>> >esos
>> >> >>> >> >usuarios
>> >> >>> >> >> puedan ejecutar comandos de la S

Re: Conectar desde clientes "enjaulados" vía SSH a MySQL.

2018-01-24 Por tema Cristian Mitchell

El 24 de enero de 2018, 08:45, Ramses<ramses.sevi...@gmail.com> escribió:

> El 24 de enero de 2018 12:18:02 CET, Cristian Mitchell <
> mitchell6...@gmail.com> escribió:
> >El 24 de enero de 2018, 04:55, Ramses II<ramses.sevi...@gmail.com>
> >escribió:
> >
> >> Cristian, buenos días de nuevo,
> >>
> >> Bien, por TCP parece que ya funciona:
> >>
> >> 
> >> 
> >> -bash-4.2$ /usr/bin/mysql -h 127.0.0.1 -u root -p --protocol=tcp
> >> Enter password:
> >> Welcome to the MySQL monitor.  Commands end with ; or \g.
> >> Your MySQL connection id is 46
> >> Server version: 5.5.59-0+deb7u1 (Debian)
> >>
> >> Copyright (c) 2000, 2018, Oracle and/or its affiliates. All rights
> >> reserved.
> >>
> >> Oracle is a registered trademark of Oracle Corporation and/or its
> >> affiliates. Other names may be trademarks of their respective
> >> owners.
> >>
> >> Type 'help;' or '\h' for help. Type '\c' to clear the current input
> >> statement.
> >>
> >> mysql>
> >> mysql> quit
> >> Bye
> >> -bash-4.2$
> >> 
> >> 
> >>
> >> Ahora sólo queda ver si hay forma de hacerlo por socket de MySQL.
> >>
> >> Si ejecuto en la sesión "enjaulada" el comando que me has comentado:
> >>
> >> 
> >> 
> >> -bash-4.2$ mount -o bind,noexec /var/run/mysqld/mysqld.sock
> >> mount: only root can do that
> >> -bash-4.2$
> >> 
> >> 
> >>
> >> Lo que te comentaba, que dice que sólo lo puede ejecutar "root".
> >>
> >> De cualquier forma, si ejecuto sólo "mount", tampoco va:
> >>
> >> 
> >> 
> >> -bash-4.2$ mount
> >> warning: failed to read mtab
> >> -bash-4.2$
> >> 
> >> 
> >>
> >>
> >> Gracias y saludos,
> >>
> >> Ramses
> >>
> >> El día 24 de enero de 2018, 0:37, Cristian Mitchell
> >> <mitchell6...@gmail.com> escribió:
> >> >
> >> >
> >> > El 23 de enero de 2018, 20:32, Cristian
> >Mitchell<mitchell6...@gmail.com>
> >> > escribió:
> >> >>
> >> >>
> >> >>
> >> >> El 23 de enero de 2018, 19:40, Ramses<ramses.sevi...@gmail.com>
> >> escribió:
> >> >>>
> >> >>> El 23 de enero de 2018 23:20:09 CET, Cristian Mitchell
> >> >>> <mitchell6...@gmail.com> escribió:
> >> >>> >El 23 de enero de 2018, 15:26, Ramses<ramses.sevi...@gmail.com>
> >> >>> >escribió:
> >> >>> >
> >> >>> >> El 23 de enero de 2018 18:24:23 CET, Matias Mucciolo <
> >> >>> >> mmucci...@suteba.org.ar> escribió:
> >> >>> >> >On Tuesday, January 23, 2018 5:29:07 PM -03 Ramses wrote:
> >> >>> >> >> Hola a tod@s,
> >> >>> >> >>
> >> >>> >> >> Tengo instalado MySQL Server con su proceso habitual.
> >> >>> >> >>
> >> >>> >> >> Ahora quiero dar acceso a Clientes vía SSH, pero no quiero
> >que
> >> >>> >esos
> >> >>> >> >usuarios
> >> >>> >> >> puedan ejecutar comandos de la Shell de Linux mediante el
> >comando
> >> >>> >> >"system"
> >> >>> >> >> de MySQL.
> >> >>> >> >>
> >> >>> >> >> Parece ser que no hay forma de impedir los Usuarios de
> >MySQL
> >> >>> >puedan
> >> >>> >> >ejecutar
> >> >>> >> >> el comando "system" y la únic

Re: Conectar desde clientes "enjaulados" vía SSH a MySQL.

2018-01-24 Por tema Ramses

El 24 de enero de 2018 12:18:02 CET, Cristian Mitchell <mitchell6...@gmail.com> 
escribió:
>El 24 de enero de 2018, 04:55, Ramses II<ramses.sevi...@gmail.com>
>escribió:
>
>> Cristian, buenos días de nuevo,
>>
>> Bien, por TCP parece que ya funciona:
>>
>> 
>> 
>> -bash-4.2$ /usr/bin/mysql -h 127.0.0.1 -u root -p --protocol=tcp
>> Enter password:
>> Welcome to the MySQL monitor.  Commands end with ; or \g.
>> Your MySQL connection id is 46
>> Server version: 5.5.59-0+deb7u1 (Debian)
>>
>> Copyright (c) 2000, 2018, Oracle and/or its affiliates. All rights
>> reserved.
>>
>> Oracle is a registered trademark of Oracle Corporation and/or its
>> affiliates. Other names may be trademarks of their respective
>> owners.
>>
>> Type 'help;' or '\h' for help. Type '\c' to clear the current input
>> statement.
>>
>> mysql>
>> mysql> quit
>> Bye
>> -bash-4.2$
>> 
>> 
>>
>> Ahora sólo queda ver si hay forma de hacerlo por socket de MySQL.
>>
>> Si ejecuto en la sesión "enjaulada" el comando que me has comentado:
>>
>> 
>> 
>> -bash-4.2$ mount -o bind,noexec /var/run/mysqld/mysqld.sock
>> mount: only root can do that
>> -bash-4.2$
>> 
>> 
>>
>> Lo que te comentaba, que dice que sólo lo puede ejecutar "root".
>>
>> De cualquier forma, si ejecuto sólo "mount", tampoco va:
>>
>> 
>> 
>> -bash-4.2$ mount
>> warning: failed to read mtab
>> -bash-4.2$
>> 
>> 
>>
>>
>> Gracias y saludos,
>>
>> Ramses
>>
>> El día 24 de enero de 2018, 0:37, Cristian Mitchell
>> <mitchell6...@gmail.com> escribió:
>> >
>> >
>> > El 23 de enero de 2018, 20:32, Cristian
>Mitchell<mitchell6...@gmail.com>
>> > escribió:
>> >>
>> >>
>> >>
>> >> El 23 de enero de 2018, 19:40, Ramses<ramses.sevi...@gmail.com>
>> escribió:
>> >>>
>> >>> El 23 de enero de 2018 23:20:09 CET, Cristian Mitchell
>> >>> <mitchell6...@gmail.com> escribió:
>> >>> >El 23 de enero de 2018, 15:26, Ramses<ramses.sevi...@gmail.com>
>> >>> >escribió:
>> >>> >
>> >>> >> El 23 de enero de 2018 18:24:23 CET, Matias Mucciolo <
>> >>> >> mmucci...@suteba.org.ar> escribió:
>> >>> >> >On Tuesday, January 23, 2018 5:29:07 PM -03 Ramses wrote:
>> >>> >> >> Hola a tod@s,
>> >>> >> >>
>> >>> >> >> Tengo instalado MySQL Server con su proceso habitual.
>> >>> >> >>
>> >>> >> >> Ahora quiero dar acceso a Clientes vía SSH, pero no quiero
>que
>> >>> >esos
>> >>> >> >usuarios
>> >>> >> >> puedan ejecutar comandos de la Shell de Linux mediante el
>comando
>> >>> >> >"system"
>> >>> >> >> de MySQL.
>> >>> >> >>
>> >>> >> >> Parece ser que no hay forma de impedir los Usuarios de
>MySQL
>> >>> >puedan
>> >>> >> >ejecutar
>> >>> >> >> el comando "system" y la única forma de limitar el uso de
>los
>> >>> >> >comandos del
>> >>> >> >> Shell de Linux es enjaular (chroot jail) estos Usuarios
>SSH, y
>> >>> >sólo
>> >>> >> >copiar
>> >>> >> >> en la jaula los comandos que les permito y sus librerías
>> >>> >asociadas.
>> >>> >> >>
>> >>> >> >> Bien, tengo ya el entorno "chroot jail" configurado y el
>Usuario
>> >>> >SSH
>&

Re: Conectar desde clientes "enjaulados" vía SSH a MySQL.

2018-01-24 Por tema Matias Mucciolo


On Wednesday, January 24, 2018 8:18:02 AM -03 Cristian Mitchell wrote:
> El 24 de enero de 2018, 04:55, Ramses II<ramses.sevi...@gmail.com> escribió:
> > Cristian, buenos días de nuevo,
> > 
> > Bien, por TCP parece que ya funciona:
> > 
> > 
> > 
> > -bash-4.2$ /usr/bin/mysql -h 127.0.0.1 -u root -p --protocol=tcp
> > Enter password:
> > Welcome to the MySQL monitor.  Commands end with ; or \g.
> > Your MySQL connection id is 46
> > Server version: 5.5.59-0+deb7u1 (Debian)
> > 
> > Copyright (c) 2000, 2018, Oracle and/or its affiliates. All rights
> > reserved.
> > 
> > Oracle is a registered trademark of Oracle Corporation and/or its
> > affiliates. Other names may be trademarks of their respective
> > owners.
> > 
> > Type 'help;' or '\h' for help. Type '\c' to clear the current input
> > statement.
> > 
> > mysql>
> > mysql> quit
> > Bye
> > -bash-4.2$
> > 
> > 
> > 
> > Ahora sólo queda ver si hay forma de hacerlo por socket de MySQL.
> > 
> > Si ejecuto en la sesión "enjaulada" el comando que me has comentado:
> > 
> > 
> > 
> > -bash-4.2$ mount -o bind,noexec /var/run/mysqld/mysqld.sock
> > mount: only root can do that
> > -bash-4.2$
> > 
> > 
> > 
> > Lo que te comentaba, que dice que sólo lo puede ejecutar "root".
> > 
> > De cualquier forma, si ejecuto sólo "mount", tampoco va:
> > 
> > 
> > 
> > -bash-4.2$ mount
> > warning: failed to read mtab
> > -bash-4.2$
> > 
> > 
> > 
> > 
> > Gracias y saludos,
> > 
> > Ramses
> > 
> > El día 24 de enero de 2018, 0:37, Cristian Mitchell
> > 
> > <mitchell6...@gmail.com> escribió:
> > > El 23 de enero de 2018, 20:32, Cristian Mitchell<mitchell6...@gmail.com>
> > > 
> > > escribió:
> > >> El 23 de enero de 2018, 19:40, Ramses<ramses.sevi...@gmail.com>
> > 
> > escribió:
> > >>> El 23 de enero de 2018 23:20:09 CET, Cristian Mitchell
> > >>> 
> > >>> <mitchell6...@gmail.com> escribió:
> > >>> >El 23 de enero de 2018, 15:26, Ramses<ramses.sevi...@gmail.com>
> > >>> >
> > >>> >escribió:
> > >>> >> El 23 de enero de 2018 18:24:23 CET, Matias Mucciolo <
> > >>> >> 
> > >>> >> mmucci...@suteba.org.ar> escribió:
> > >>> >> >On Tuesday, January 23, 2018 5:29:07 PM -03 Ramses wrote:
> > >>> >> >> Hola a tod@s,
> > >>> >> >> 
> > >>> >> >> Tengo instalado MySQL Server con su proceso habitual.
> > >>> >> >> 
> > >>> >> >> Ahora quiero dar acceso a Clientes vía SSH, pero no quiero que
> > >>> >
> > >>> >esos
> > >>> >
> > >>> >> >usuarios
> > >>> >> >
> > >>> >> >> puedan ejecutar comandos de la Shell de Linux mediante el
> > >>> >> >> comando
> > >>> >> >
> > >>> >> >"system"
> > >>> >> >
> > >>> >> >> de MySQL.
> > >>> >> >> 
> > >>> >> >> Parece ser que no hay forma de impedir los Usuarios de MySQL
> > >>> >
> > >>> >puedan
> > >>> >
> > >>> >> >ejecutar
> > >>> >> >
> > >>> >> >> el comando "system" y la única forma de limitar el uso de los
> > >>> >> >
> > >>> >> >comandos del
> > >>> >> >
> > >>> >> >> Shell de Linux es enjaular (chroot jail) est

Re: Conectar desde clientes "enjaulados" vía SSH a MySQL.

2018-01-24 Por tema Cristian Mitchell

El 24 de enero de 2018, 04:55, Ramses II<ramses.sevi...@gmail.com> escribió:

> Cristian, buenos días de nuevo,
>
> Bien, por TCP parece que ya funciona:
>
> 
> 
> -bash-4.2$ /usr/bin/mysql -h 127.0.0.1 -u root -p --protocol=tcp
> Enter password:
> Welcome to the MySQL monitor.  Commands end with ; or \g.
> Your MySQL connection id is 46
> Server version: 5.5.59-0+deb7u1 (Debian)
>
> Copyright (c) 2000, 2018, Oracle and/or its affiliates. All rights
> reserved.
>
> Oracle is a registered trademark of Oracle Corporation and/or its
> affiliates. Other names may be trademarks of their respective
> owners.
>
> Type 'help;' or '\h' for help. Type '\c' to clear the current input
> statement.
>
> mysql>
> mysql> quit
> Bye
> -bash-4.2$
> 
> 
>
> Ahora sólo queda ver si hay forma de hacerlo por socket de MySQL.
>
> Si ejecuto en la sesión "enjaulada" el comando que me has comentado:
>
> 
> 
> -bash-4.2$ mount -o bind,noexec /var/run/mysqld/mysqld.sock
> mount: only root can do that
> -bash-4.2$
> 
> 
>
> Lo que te comentaba, que dice que sólo lo puede ejecutar "root".
>
> De cualquier forma, si ejecuto sólo "mount", tampoco va:
>
> 
> 
> -bash-4.2$ mount
> warning: failed to read mtab
> -bash-4.2$
> 
> 
>
>
> Gracias y saludos,
>
> Ramses
>
> El día 24 de enero de 2018, 0:37, Cristian Mitchell
> <mitchell6...@gmail.com> escribió:
> >
> >
> > El 23 de enero de 2018, 20:32, Cristian Mitchell<mitchell6...@gmail.com>
> > escribió:
> >>
> >>
> >>
> >> El 23 de enero de 2018, 19:40, Ramses<ramses.sevi...@gmail.com>
> escribió:
> >>>
> >>> El 23 de enero de 2018 23:20:09 CET, Cristian Mitchell
> >>> <mitchell6...@gmail.com> escribió:
> >>> >El 23 de enero de 2018, 15:26, Ramses<ramses.sevi...@gmail.com>
> >>> >escribió:
> >>> >
> >>> >> El 23 de enero de 2018 18:24:23 CET, Matias Mucciolo <
> >>> >> mmucci...@suteba.org.ar> escribió:
> >>> >> >On Tuesday, January 23, 2018 5:29:07 PM -03 Ramses wrote:
> >>> >> >> Hola a tod@s,
> >>> >> >>
> >>> >> >> Tengo instalado MySQL Server con su proceso habitual.
> >>> >> >>
> >>> >> >> Ahora quiero dar acceso a Clientes vía SSH, pero no quiero que
> >>> >esos
> >>> >> >usuarios
> >>> >> >> puedan ejecutar comandos de la Shell de Linux mediante el comando
> >>> >> >"system"
> >>> >> >> de MySQL.
> >>> >> >>
> >>> >> >> Parece ser que no hay forma de impedir los Usuarios de MySQL
> >>> >puedan
> >>> >> >ejecutar
> >>> >> >> el comando "system" y la única forma de limitar el uso de los
> >>> >> >comandos del
> >>> >> >> Shell de Linux es enjaular (chroot jail) estos Usuarios SSH, y
> >>> >sólo
> >>> >> >copiar
> >>> >> >> en la jaula los comandos que les permito y sus librerías
> >>> >asociadas.
> >>> >> >>
> >>> >> >> Bien, tengo ya el entorno "chroot jail" configurado y el Usuario
> >>> >SSH
> >>> >> >se
> >>> >> >> conecta.
> >>> >> >>
> >>> >> >> He copiado el fichero de arranque "/usr/sbin/mysql" en el
> >>> >directorio
> >>> >> >> "enjaulado".
> >>> >> >>
> >>> >> >> Con el comando "ldd /usr/sbin/mysql" averiguo las librerías
> >>> >asociadas
> >>> >> >y las
> >>> >> &g

Re: Conectar desde clientes "enjaulados" vía SSH a MySQL.

2018-01-23 Por tema Ramses II

Cristian, buenos días de nuevo,

Bien, por TCP parece que ya funciona:


-bash-4.2$ /usr/bin/mysql -h 127.0.0.1 -u root -p --protocol=tcp
Enter password:
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 46
Server version: 5.5.59-0+deb7u1 (Debian)

Copyright (c) 2000, 2018, Oracle and/or its affiliates. All rights reserved.

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql>
mysql> quit
Bye
-bash-4.2$


Ahora sólo queda ver si hay forma de hacerlo por socket de MySQL.

Si ejecuto en la sesión "enjaulada" el comando que me has comentado:


-bash-4.2$ mount -o bind,noexec /var/run/mysqld/mysqld.sock
mount: only root can do that
-bash-4.2$


Lo que te comentaba, que dice que sólo lo puede ejecutar "root".

De cualquier forma, si ejecuto sólo "mount", tampoco va:


-bash-4.2$ mount
warning: failed to read mtab
-bash-4.2$



Gracias y saludos,

Ramses

El día 24 de enero de 2018, 0:37, Cristian Mitchell
<mitchell6...@gmail.com> escribió:
>
>
> El 23 de enero de 2018, 20:32, Cristian Mitchell<mitchell6...@gmail.com>
> escribió:
>>
>>
>>
>> El 23 de enero de 2018, 19:40, Ramses<ramses.sevi...@gmail.com> escribió:
>>>
>>> El 23 de enero de 2018 23:20:09 CET, Cristian Mitchell
>>> <mitchell6...@gmail.com> escribió:
>>> >El 23 de enero de 2018, 15:26, Ramses<ramses.sevi...@gmail.com>
>>> >escribió:
>>> >
>>> >> El 23 de enero de 2018 18:24:23 CET, Matias Mucciolo <
>>> >> mmucci...@suteba.org.ar> escribió:
>>> >> >On Tuesday, January 23, 2018 5:29:07 PM -03 Ramses wrote:
>>> >> >> Hola a tod@s,
>>> >> >>
>>> >> >> Tengo instalado MySQL Server con su proceso habitual.
>>> >> >>
>>> >> >> Ahora quiero dar acceso a Clientes vía SSH, pero no quiero que
>>> >esos
>>> >> >usuarios
>>> >> >> puedan ejecutar comandos de la Shell de Linux mediante el comando
>>> >> >"system"
>>> >> >> de MySQL.
>>> >> >>
>>> >> >> Parece ser que no hay forma de impedir los Usuarios de MySQL
>>> >puedan
>>> >> >ejecutar
>>> >> >> el comando "system" y la única forma de limitar el uso de los
>>> >> >comandos del
>>> >> >> Shell de Linux es enjaular (chroot jail) estos Usuarios SSH, y
>>> >sólo
>>> >> >copiar
>>> >> >> en la jaula los comandos que les permito y sus librerías
>>> >asociadas.
>>> >> >>
>>> >> >> Bien, tengo ya el entorno "chroot jail" configurado y el Usuario
>>> >SSH
>>> >> >se
>>> >> >> conecta.
>>> >> >>
>>> >> >> He copiado el fichero de arranque "/usr/sbin/mysql" en el
>>> >directorio
>>> >> >> "enjaulado".
>>> >> >>
>>> >> >> Con el comando "ldd /usr/sbin/mysql" averiguo las librerías
>>> >asociadas
>>> >> >y las
>>> >> >> he copiado en el directorio "enjaulado".
>>> >> >>
>>> >> >> Ahora, cuando se conecta un Usuario "enjaulado" vía SSH y ejecuta,
>>> >> >por
>>> >> >> ejemplo, "/usr/sbin/mysql -u root -p", MySQL pide la password,
>>> >pero
>>> >> >al
>>> >> >> introducirla, da un error de socket diciendo que no encuentra
>>> >> >> "/var/run/mysqld/mysqld.sock", y ahí estoy estancado...
>>> >> >>
>>> >> >> ¿Hay a

Re: Conectar desde clientes "enjaulados" vía SSH a MySQL.

2018-01-23 Por tema Ramses II

Matías, buenos días,

El día 23 de enero de 2018, 19:29, Matias Mucciolo
<mmucci...@suteba.org.ar> escribió:
>
> On Tuesday, January 23, 2018 7:23:26 PM -03 Ramses wrote:
>> El 23 de enero de 2018 18:24:23 CET, Matias Mucciolo
> <mmucci...@suteba.org.ar> escribió:
>> >On Tuesday, January 23, 2018 5:29:07 PM -03 Ramses wrote:
>> >> Hola a tod@s,
>> >>
>> >> Tengo instalado MySQL Server con su proceso habitual.
>> >>
>> >> Ahora quiero dar acceso a Clientes vía SSH, pero no quiero que esos
>> >
>> >usuarios
>> >
>> >> puedan ejecutar comandos de la Shell de Linux mediante el comando
>> >
>> >"system"
>> >
>> >> de MySQL.
>> >>
>> >> Parece ser que no hay forma de impedir los Usuarios de MySQL puedan
>> >
>> >ejecutar
>> >
>> >> el comando "system" y la única forma de limitar el uso de los
>> >
>> >comandos del
>> >
>> >> Shell de Linux es enjaular (chroot jail) estos Usuarios SSH, y sólo
>> >
>> >copiar
>> >
>> >> en la jaula los comandos que les permito y sus librerías asociadas.
>> >>
>> >> Bien, tengo ya el entorno "chroot jail" configurado y el Usuario SSH
>> >
>> >se
>> >
>> >> conecta.
>> >>
>> >> He copiado el fichero de arranque "/usr/sbin/mysql" en el directorio
>> >> "enjaulado".
>> >>
>> >> Con el comando "ldd /usr/sbin/mysql" averiguo las librerías asociadas
>> >
>> >y las
>> >
>> >> he copiado en el directorio "enjaulado".
>> >>
>> >> Ahora, cuando se conecta un Usuario "enjaulado" vía SSH y ejecuta,
>> >
>> >por
>> >
>> >> ejemplo, "/usr/sbin/mysql -u root -p", MySQL pide la password, pero
>> >
>> >al
>> >
>> >> introducirla, da un error de socket diciendo que no encuentra
>> >> "/var/run/mysqld/mysqld.sock", y ahí estoy estancado...
>> >>
>> >> ¿Hay alguien que haya hecho esto y pueda comentarme qué pasos me
>> >
>> >faltan por
>> >
>> >> hacer?
>> >>
>> >>
>> >> Gracias y saludos,
>> >>
>> >> Ramses
>> >
>> >obviamente se estan tratando de conectar mediante el socket
>> >que crea mysql y los clientes enjaulados no pueden acceder.
>> >creo que mysql tiene una opcion para que la "conexion"
>> >sea por tcp...eso deberia funcionar..
>> >
>> >saludos
>> >Matias
>>
>> Matías, gracias por contestar.
>>
>> Pero, ¿sabes si tengo que copiar algún fichero de configuración, como el
>> my.cnf a la "jaula"?.
>>
>> Hasta el momento sólo copiado programas y librerías al entorno "enjaulado".
>>
>> Y estoy buscando información tanto en Linux genérico y Debian, como en
>> MySQL, y no encuentro lo que me aclare este tema...
>>
>>
>> Saludos y gracias,
>>
>> Ramses
>
> no... no tenes que copiar nada...mientras que ande el binario de mysql.
>
> proba esto con el usuario enjaulado:
>
>
> mysql -u root -p --protocol=tcp
>
> asi no usa el socket y usa tcp.
> saludos
>

Bien, ejecutando el comando que me ponías:


-bash-4.2$ /usr/bin/mysql -u root -p --protocol=tcp
Enter password:
ERROR 2005 (HY000): Unknown MySQL server host 'localhost' (2)
-bash-4.2$


El error que da me imagino que es porque no está definido el fichero
"/etc/hosts" en la jaula, porque:


-bash-4.2$ /usr/bin/mysql -h 127.0.0.1 -u root -p --protocol=tcp
Enter password:
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 46
Server version: 5.5.59-0+deb7u1 (Debian)

Copyright (c) 2000, 2018, Oracle and/or its affiliates. All rights reserved.

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql>
mysql> quit
Bye
-bash-4.2$


Funciona.

Ahora sólo queda ver si hay forma de hacerlo por socket de MySQL.


Gracias y saludos,

Ramses

Re: Conectar desde clientes "enjaulados" vía SSH a MySQL.

2018-01-23 Por tema Ramses

El 24 de enero de 2018 0:37:07 CET, Cristian Mitchell <mitchell6...@gmail.com> 
escribió:
>El 23 de enero de 2018, 20:32, Cristian
>Mitchell<mitchell6...@gmail.com>
>escribió:
>
>>
>>
>> El 23 de enero de 2018, 19:40, Ramses<ramses.sevi...@gmail.com>
>escribió:
>>
>>> El 23 de enero de 2018 23:20:09 CET, Cristian Mitchell <
>>> mitchell6...@gmail.com> escribió:
>>> >El 23 de enero de 2018, 15:26, Ramses<ramses.sevi...@gmail.com>
>>> >escribió:
>>> >
>>> >> El 23 de enero de 2018 18:24:23 CET, Matias Mucciolo <
>>> >> mmucci...@suteba.org.ar> escribió:
>>> >> >On Tuesday, January 23, 2018 5:29:07 PM -03 Ramses wrote:
>>> >> >> Hola a tod@s,
>>> >> >>
>>> >> >> Tengo instalado MySQL Server con su proceso habitual.
>>> >> >>
>>> >> >> Ahora quiero dar acceso a Clientes vía SSH, pero no quiero que
>>> >esos
>>> >> >usuarios
>>> >> >> puedan ejecutar comandos de la Shell de Linux mediante el
>comando
>>> >> >"system"
>>> >> >> de MySQL.
>>> >> >>
>>> >> >> Parece ser que no hay forma de impedir los Usuarios de MySQL
>>> >puedan
>>> >> >ejecutar
>>> >> >> el comando "system" y la única forma de limitar el uso de los
>>> >> >comandos del
>>> >> >> Shell de Linux es enjaular (chroot jail) estos Usuarios SSH, y
>>> >sólo
>>> >> >copiar
>>> >> >> en la jaula los comandos que les permito y sus librerías
>>> >asociadas.
>>> >> >>
>>> >> >> Bien, tengo ya el entorno "chroot jail" configurado y el
>Usuario
>>> >SSH
>>> >> >se
>>> >> >> conecta.
>>> >> >>
>>> >> >> He copiado el fichero de arranque "/usr/sbin/mysql" en el
>>> >directorio
>>> >> >> "enjaulado".
>>> >> >>
>>> >> >> Con el comando "ldd /usr/sbin/mysql" averiguo las librerías
>>> >asociadas
>>> >> >y las
>>> >> >> he copiado en el directorio "enjaulado".
>>> >> >>
>>> >> >> Ahora, cuando se conecta un Usuario "enjaulado" vía SSH y
>ejecuta,
>>> >> >por
>>> >> >> ejemplo, "/usr/sbin/mysql -u root -p", MySQL pide la password,
>>> >pero
>>> >> >al
>>> >> >> introducirla, da un error de socket diciendo que no encuentra
>>> >> >> "/var/run/mysqld/mysqld.sock", y ahí estoy estancado...
>>> >> >>
>>> >> >> ¿Hay alguien que haya hecho esto y pueda comentarme qué pasos
>me
>>> >> >faltan por
>>> >> >> hacer?
>>> >> >>
>>> >> >>
>>> >> >> Gracias y saludos,
>>> >> >>
>>> >> >> Ramses
>>> >> >
>>> >> >obviamente se estan tratando de conectar mediante el socket
>>> >> >que crea mysql y los clientes enjaulados no pueden acceder.
>>> >> >creo que mysql tiene una opcion para que la "conexion"
>>> >> >sea por tcp...eso deberia funcionar..
>>> >> >
>>> >> >saludos
>>> >> >Matias
>>> >>
>>> >> Matías, gracias por contestar.
>>> >>
>>> >> Pero, ¿sabes si tengo que copiar algún fichero de configuración,
>como
>>> >el
>>> >> my.cnf a la "jaula"?.
>>> >>
>>> >> Hasta el momento sólo copiado programas y librerías al entorno
>>> >"enjaulado".
>>> >>
>>> >> Y estoy buscando información tanto en Linux genérico y Debian,
>como
>>> >en
>>> >> MySQL, y no encuentro lo que me aclare este tema...
>>> >>
>>> >>
>>> >> P.D.: Disculpas Matías, el otro se me fue al personal...
>>> >>
>>> >>
>>> >> Saludos y gracias,
>>> >>
>>> >> Ramses
>>> >>
>>> >>
>>> >como te estas logueando a mysql?
>>>
>>> Cristian, ¿te refieres a esto que ponía en mi correo?
>>>
>>> El cliente se conecta vía SSH a un entorno "enjaulado" y ejecuta:
>>>
>>> /usr/sbin/mysql -u root -p
>>>
>>
>> alguien comentaba esto
>>  si haces asi  nada mas te estas conectado por socket el cual
>nesesitas
>> acceso
>> pero si haces mysql -h localhost -u myname -ppassword mydb
>> esto evita tu problema de sock
>>
>>
>>
>>
>>>
>>>
>>> Saludos,
>>>
>>> Ramses
>>>
>>>
>>
>>
>> --
>> MrIX
>> Linux user number 412793.
>> http://counter.li.org/
>>
>> las grandes obras,
>> las sueñan los santos locos,
>> las realizan los luchadores natos,
>> las aprovechan los felices cuerdo,
>> y las critican los inútiles crónicos,
>>
>>
>si no tu otra opción es
>
>
>mount -o bind,noexec /var/run/mysqld/mysqld.sock (al chroot)

Cristian, buenos días,

¿Te refieres a ejecutar el comando "mount -o bind,noexec 
/var/run/mysqld/mysqld.sock" desde la sesión de un usuario "enjaulado" antes de 
lanzar el "/usr/sbin/mysql"?

Creo haberlo ejecutado ayer y no me dejaba. Copié el "mount" y sus librerías 
asociadas a la jaula y al ejecutarlo me decía que sólo podía ejecutar ese 
comando el "root", y ahí me quedé. A parte del "mount" y las librerías, ¿habría 
que copiar a la jaula algún otro fichero?.


Saludos y gracias,

Ramses

Re: Conectar desde clientes "enjaulados" vía SSH a MySQL.

2018-01-23 Por tema Cristian Mitchell

El 23 de enero de 2018, 20:32, Cristian Mitchell<mitchell6...@gmail.com>
escribió:

>
>
> El 23 de enero de 2018, 19:40, Ramses<ramses.sevi...@gmail.com> escribió:
>
>> El 23 de enero de 2018 23:20:09 CET, Cristian Mitchell <
>> mitchell6...@gmail.com> escribió:
>> >El 23 de enero de 2018, 15:26, Ramses<ramses.sevi...@gmail.com>
>> >escribió:
>> >
>> >> El 23 de enero de 2018 18:24:23 CET, Matias Mucciolo <
>> >> mmucci...@suteba.org.ar> escribió:
>> >> >On Tuesday, January 23, 2018 5:29:07 PM -03 Ramses wrote:
>> >> >> Hola a tod@s,
>> >> >>
>> >> >> Tengo instalado MySQL Server con su proceso habitual.
>> >> >>
>> >> >> Ahora quiero dar acceso a Clientes vía SSH, pero no quiero que
>> >esos
>> >> >usuarios
>> >> >> puedan ejecutar comandos de la Shell de Linux mediante el comando
>> >> >"system"
>> >> >> de MySQL.
>> >> >>
>> >> >> Parece ser que no hay forma de impedir los Usuarios de MySQL
>> >puedan
>> >> >ejecutar
>> >> >> el comando "system" y la única forma de limitar el uso de los
>> >> >comandos del
>> >> >> Shell de Linux es enjaular (chroot jail) estos Usuarios SSH, y
>> >sólo
>> >> >copiar
>> >> >> en la jaula los comandos que les permito y sus librerías
>> >asociadas.
>> >> >>
>> >> >> Bien, tengo ya el entorno "chroot jail" configurado y el Usuario
>> >SSH
>> >> >se
>> >> >> conecta.
>> >> >>
>> >> >> He copiado el fichero de arranque "/usr/sbin/mysql" en el
>> >directorio
>> >> >> "enjaulado".
>> >> >>
>> >> >> Con el comando "ldd /usr/sbin/mysql" averiguo las librerías
>> >asociadas
>> >> >y las
>> >> >> he copiado en el directorio "enjaulado".
>> >> >>
>> >> >> Ahora, cuando se conecta un Usuario "enjaulado" vía SSH y ejecuta,
>> >> >por
>> >> >> ejemplo, "/usr/sbin/mysql -u root -p", MySQL pide la password,
>> >pero
>> >> >al
>> >> >> introducirla, da un error de socket diciendo que no encuentra
>> >> >> "/var/run/mysqld/mysqld.sock", y ahí estoy estancado...
>> >> >>
>> >> >> ¿Hay alguien que haya hecho esto y pueda comentarme qué pasos me
>> >> >faltan por
>> >> >> hacer?
>> >> >>
>> >> >>
>> >> >> Gracias y saludos,
>> >> >>
>> >> >> Ramses
>> >> >
>> >> >obviamente se estan tratando de conectar mediante el socket
>> >> >que crea mysql y los clientes enjaulados no pueden acceder.
>> >> >creo que mysql tiene una opcion para que la "conexion"
>> >> >sea por tcp...eso deberia funcionar..
>> >> >
>> >> >saludos
>> >> >Matias
>> >>
>> >> Matías, gracias por contestar.
>> >>
>> >> Pero, ¿sabes si tengo que copiar algún fichero de configuración, como
>> >el
>> >> my.cnf a la "jaula"?.
>> >>
>> >> Hasta el momento sólo copiado programas y librerías al entorno
>> >"enjaulado".
>> >>
>> >> Y estoy buscando información tanto en Linux genérico y Debian, como
>> >en
>> >> MySQL, y no encuentro lo que me aclare este tema...
>> >>
>> >>
>> >> P.D.: Disculpas Matías, el otro se me fue al personal...
>> >>
>> >>
>> >> Saludos y gracias,
>> >>
>> >> Ramses
>> >>
>> >>
>> >como te estas logueando a mysql?
>>
>> Cristian, ¿te refieres a esto que ponía en mi correo?
>>
>> El cliente se conecta vía SSH a un entorno "enjaulado" y ejecuta:
>>
>> /usr/sbin/mysql -u root -p
>>
>
> alguien comentaba esto
>  si haces asi  nada mas te estas conectado por socket el cual nesesitas
> acceso
> pero si haces mysql -h localhost -u myname -ppassword mydb
> esto evita tu problema de sock
>
>
>
>
>>
>>
>> Saludos,
>>
>> Ramses
>>
>>
>
>
> --
> MrIX
> Linux user number 412793.
> http://counter.li.org/
>
> las grandes obras,
> las sueñan los santos locos,
> las realizan los luchadores natos,
> las aprovechan los felices cuerdo,
> y las critican los inútiles crónicos,
>
>
si no tu otra opción es


mount -o bind,noexec /var/run/mysqld/mysqld.sock (al chroot)

-- 
MrIX
Linux user number 412793.
http://counter.li.org/

las grandes obras,
las sueñan los santos locos,
las realizan los luchadores natos,
las aprovechan los felices cuerdo,
y las critican los inútiles crónicos,

Re: Conectar desde clientes "enjaulados" vía SSH a MySQL.

2018-01-23 Por tema Cristian Mitchell

El 23 de enero de 2018, 19:40, Ramses<ramses.sevi...@gmail.com> escribió:

> El 23 de enero de 2018 23:20:09 CET, Cristian Mitchell <
> mitchell6...@gmail.com> escribió:
> >El 23 de enero de 2018, 15:26, Ramses<ramses.sevi...@gmail.com>
> >escribió:
> >
> >> El 23 de enero de 2018 18:24:23 CET, Matias Mucciolo <
> >> mmucci...@suteba.org.ar> escribió:
> >> >On Tuesday, January 23, 2018 5:29:07 PM -03 Ramses wrote:
> >> >> Hola a tod@s,
> >> >>
> >> >> Tengo instalado MySQL Server con su proceso habitual.
> >> >>
> >> >> Ahora quiero dar acceso a Clientes vía SSH, pero no quiero que
> >esos
> >> >usuarios
> >> >> puedan ejecutar comandos de la Shell de Linux mediante el comando
> >> >"system"
> >> >> de MySQL.
> >> >>
> >> >> Parece ser que no hay forma de impedir los Usuarios de MySQL
> >puedan
> >> >ejecutar
> >> >> el comando "system" y la única forma de limitar el uso de los
> >> >comandos del
> >> >> Shell de Linux es enjaular (chroot jail) estos Usuarios SSH, y
> >sólo
> >> >copiar
> >> >> en la jaula los comandos que les permito y sus librerías
> >asociadas.
> >> >>
> >> >> Bien, tengo ya el entorno "chroot jail" configurado y el Usuario
> >SSH
> >> >se
> >> >> conecta.
> >> >>
> >> >> He copiado el fichero de arranque "/usr/sbin/mysql" en el
> >directorio
> >> >> "enjaulado".
> >> >>
> >> >> Con el comando "ldd /usr/sbin/mysql" averiguo las librerías
> >asociadas
> >> >y las
> >> >> he copiado en el directorio "enjaulado".
> >> >>
> >> >> Ahora, cuando se conecta un Usuario "enjaulado" vía SSH y ejecuta,
> >> >por
> >> >> ejemplo, "/usr/sbin/mysql -u root -p", MySQL pide la password,
> >pero
> >> >al
> >> >> introducirla, da un error de socket diciendo que no encuentra
> >> >> "/var/run/mysqld/mysqld.sock", y ahí estoy estancado...
> >> >>
> >> >> ¿Hay alguien que haya hecho esto y pueda comentarme qué pasos me
> >> >faltan por
> >> >> hacer?
> >> >>
> >> >>
> >> >> Gracias y saludos,
> >> >>
> >> >> Ramses
> >> >
> >> >obviamente se estan tratando de conectar mediante el socket
> >> >que crea mysql y los clientes enjaulados no pueden acceder.
> >> >creo que mysql tiene una opcion para que la "conexion"
> >> >sea por tcp...eso deberia funcionar..
> >> >
> >> >saludos
> >> >Matias
> >>
> >> Matías, gracias por contestar.
> >>
> >> Pero, ¿sabes si tengo que copiar algún fichero de configuración, como
> >el
> >> my.cnf a la "jaula"?.
> >>
> >> Hasta el momento sólo copiado programas y librerías al entorno
> >"enjaulado".
> >>
> >> Y estoy buscando información tanto en Linux genérico y Debian, como
> >en
> >> MySQL, y no encuentro lo que me aclare este tema...
> >>
> >>
> >> P.D.: Disculpas Matías, el otro se me fue al personal...
> >>
> >>
> >> Saludos y gracias,
> >>
> >> Ramses
> >>
> >>
> >como te estas logueando a mysql?
>
> Cristian, ¿te refieres a esto que ponía en mi correo?
>
> El cliente se conecta vía SSH a un entorno "enjaulado" y ejecuta:
>
> /usr/sbin/mysql -u root -p
>

alguien comentaba esto
 si haces asi  nada mas te estas conectado por socket el cual nesesitas
acceso
pero si haces mysql -h localhost -u myname -ppassword mydb
esto evita tu problema de sock




>
>
> Saludos,
>
> Ramses
>
>


-- 
MrIX
Linux user number 412793.
http://counter.li.org/

las grandes obras,
las sueñan los santos locos,
las realizan los luchadores natos,
las aprovechan los felices cuerdo,
y las critican los inútiles crónicos,

Re: Conectar desde clientes "enjaulados" vía SSH a MySQL.

2018-01-23 Por tema Ramses

El 23 de enero de 2018 23:20:09 CET, Cristian Mitchell <mitchell6...@gmail.com> 
escribió:
>El 23 de enero de 2018, 15:26, Ramses<ramses.sevi...@gmail.com>
>escribió:
>
>> El 23 de enero de 2018 18:24:23 CET, Matias Mucciolo <
>> mmucci...@suteba.org.ar> escribió:
>> >On Tuesday, January 23, 2018 5:29:07 PM -03 Ramses wrote:
>> >> Hola a tod@s,
>> >>
>> >> Tengo instalado MySQL Server con su proceso habitual.
>> >>
>> >> Ahora quiero dar acceso a Clientes vía SSH, pero no quiero que
>esos
>> >usuarios
>> >> puedan ejecutar comandos de la Shell de Linux mediante el comando
>> >"system"
>> >> de MySQL.
>> >>
>> >> Parece ser que no hay forma de impedir los Usuarios de MySQL
>puedan
>> >ejecutar
>> >> el comando "system" y la única forma de limitar el uso de los
>> >comandos del
>> >> Shell de Linux es enjaular (chroot jail) estos Usuarios SSH, y
>sólo
>> >copiar
>> >> en la jaula los comandos que les permito y sus librerías
>asociadas.
>> >>
>> >> Bien, tengo ya el entorno "chroot jail" configurado y el Usuario
>SSH
>> >se
>> >> conecta.
>> >>
>> >> He copiado el fichero de arranque "/usr/sbin/mysql" en el
>directorio
>> >> "enjaulado".
>> >>
>> >> Con el comando "ldd /usr/sbin/mysql" averiguo las librerías
>asociadas
>> >y las
>> >> he copiado en el directorio "enjaulado".
>> >>
>> >> Ahora, cuando se conecta un Usuario "enjaulado" vía SSH y ejecuta,
>> >por
>> >> ejemplo, "/usr/sbin/mysql -u root -p", MySQL pide la password,
>pero
>> >al
>> >> introducirla, da un error de socket diciendo que no encuentra
>> >> "/var/run/mysqld/mysqld.sock", y ahí estoy estancado...
>> >>
>> >> ¿Hay alguien que haya hecho esto y pueda comentarme qué pasos me
>> >faltan por
>> >> hacer?
>> >>
>> >>
>> >> Gracias y saludos,
>> >>
>> >> Ramses
>> >
>> >obviamente se estan tratando de conectar mediante el socket
>> >que crea mysql y los clientes enjaulados no pueden acceder.
>> >creo que mysql tiene una opcion para que la "conexion"
>> >sea por tcp...eso deberia funcionar..
>> >
>> >saludos
>> >Matias
>>
>> Matías, gracias por contestar.
>>
>> Pero, ¿sabes si tengo que copiar algún fichero de configuración, como
>el
>> my.cnf a la "jaula"?.
>>
>> Hasta el momento sólo copiado programas y librerías al entorno
>"enjaulado".
>>
>> Y estoy buscando información tanto en Linux genérico y Debian, como
>en
>> MySQL, y no encuentro lo que me aclare este tema...
>>
>>
>> P.D.: Disculpas Matías, el otro se me fue al personal...
>>
>>
>> Saludos y gracias,
>>
>> Ramses
>>
>>
>como te estas logueando a mysql?

Cristian, ¿te refieres a esto que ponía en mi correo?

El cliente se conecta vía SSH a un entorno "enjaulado" y ejecuta:

/usr/sbin/mysql -u root -p


Saludos,

Ramses

Re: Conectar desde clientes "enjaulados" vía SSH a MySQL.

2018-01-23 Por tema Cristian Mitchell

El 23 de enero de 2018, 15:26, Ramses<ramses.sevi...@gmail.com> escribió:

> El 23 de enero de 2018 18:24:23 CET, Matias Mucciolo <
> mmucci...@suteba.org.ar> escribió:
> >On Tuesday, January 23, 2018 5:29:07 PM -03 Ramses wrote:
> >> Hola a tod@s,
> >>
> >> Tengo instalado MySQL Server con su proceso habitual.
> >>
> >> Ahora quiero dar acceso a Clientes vía SSH, pero no quiero que esos
> >usuarios
> >> puedan ejecutar comandos de la Shell de Linux mediante el comando
> >"system"
> >> de MySQL.
> >>
> >> Parece ser que no hay forma de impedir los Usuarios de MySQL puedan
> >ejecutar
> >> el comando "system" y la única forma de limitar el uso de los
> >comandos del
> >> Shell de Linux es enjaular (chroot jail) estos Usuarios SSH, y sólo
> >copiar
> >> en la jaula los comandos que les permito y sus librerías asociadas.
> >>
> >> Bien, tengo ya el entorno "chroot jail" configurado y el Usuario SSH
> >se
> >> conecta.
> >>
> >> He copiado el fichero de arranque "/usr/sbin/mysql" en el directorio
> >> "enjaulado".
> >>
> >> Con el comando "ldd /usr/sbin/mysql" averiguo las librerías asociadas
> >y las
> >> he copiado en el directorio "enjaulado".
> >>
> >> Ahora, cuando se conecta un Usuario "enjaulado" vía SSH y ejecuta,
> >por
> >> ejemplo, "/usr/sbin/mysql -u root -p", MySQL pide la password, pero
> >al
> >> introducirla, da un error de socket diciendo que no encuentra
> >> "/var/run/mysqld/mysqld.sock", y ahí estoy estancado...
> >>
> >> ¿Hay alguien que haya hecho esto y pueda comentarme qué pasos me
> >faltan por
> >> hacer?
> >>
> >>
> >> Gracias y saludos,
> >>
> >> Ramses
> >
> >obviamente se estan tratando de conectar mediante el socket
> >que crea mysql y los clientes enjaulados no pueden acceder.
> >creo que mysql tiene una opcion para que la "conexion"
> >sea por tcp...eso deberia funcionar..
> >
> >saludos
> >Matias
>
> Matías, gracias por contestar.
>
> Pero, ¿sabes si tengo que copiar algún fichero de configuración, como el
> my.cnf a la "jaula"?.
>
> Hasta el momento sólo copiado programas y librerías al entorno "enjaulado".
>
> Y estoy buscando información tanto en Linux genérico y Debian, como en
> MySQL, y no encuentro lo que me aclare este tema...
>
>
> P.D.: Disculpas Matías, el otro se me fue al personal...
>
>
> Saludos y gracias,
>
> Ramses
>
>
como te estas logueando a mysql?

-- 
MrIX
Linux user number 412793.
http://counter.li.org/

las grandes obras,
las sueñan los santos locos,
las realizan los luchadores natos,
las aprovechan los felices cuerdo,
y las critican los inútiles crónicos,

Re: Conectar desde clientes "enjaulados" vía SSH a MySQL.

2018-01-23 Por tema Ramses

El 23 de enero de 2018 18:24:23 CET, Matias Mucciolo <mmucci...@suteba.org.ar> 
escribió:
>On Tuesday, January 23, 2018 5:29:07 PM -03 Ramses wrote:
>> Hola a tod@s,
>> 
>> Tengo instalado MySQL Server con su proceso habitual.
>> 
>> Ahora quiero dar acceso a Clientes vía SSH, pero no quiero que esos
>usuarios
>> puedan ejecutar comandos de la Shell de Linux mediante el comando
>"system"
>> de MySQL.
>> 
>> Parece ser que no hay forma de impedir los Usuarios de MySQL puedan
>ejecutar
>> el comando "system" y la única forma de limitar el uso de los
>comandos del
>> Shell de Linux es enjaular (chroot jail) estos Usuarios SSH, y sólo
>copiar
>> en la jaula los comandos que les permito y sus librerías asociadas.
>> 
>> Bien, tengo ya el entorno "chroot jail" configurado y el Usuario SSH
>se
>> conecta.
>> 
>> He copiado el fichero de arranque "/usr/sbin/mysql" en el directorio
>> "enjaulado".
>> 
>> Con el comando "ldd /usr/sbin/mysql" averiguo las librerías asociadas
>y las
>> he copiado en el directorio "enjaulado".
>> 
>> Ahora, cuando se conecta un Usuario "enjaulado" vía SSH y ejecuta,
>por
>> ejemplo, "/usr/sbin/mysql -u root -p", MySQL pide la password, pero
>al
>> introducirla, da un error de socket diciendo que no encuentra
>> "/var/run/mysqld/mysqld.sock", y ahí estoy estancado...
>> 
>> ¿Hay alguien que haya hecho esto y pueda comentarme qué pasos me
>faltan por
>> hacer?
>> 
>> 
>> Gracias y saludos,
>> 
>> Ramses
>
>obviamente se estan tratando de conectar mediante el socket 
>que crea mysql y los clientes enjaulados no pueden acceder.
>creo que mysql tiene una opcion para que la "conexion"
>sea por tcp...eso deberia funcionar..
>
>saludos
>Matias

Matías, gracias por contestar.

Pero, ¿sabes si tengo que copiar algún fichero de configuración, como el my.cnf 
a la "jaula"?.

Hasta el momento sólo copiado programas y librerías al entorno "enjaulado".

Y estoy buscando información tanto en Linux genérico y Debian, como en MySQL, y 
no encuentro lo que me aclare este tema...


P.D.: Disculpas Matías, el otro se me fue al personal...


Saludos y gracias,

Ramses

Re: Conectar desde clientes "enjaulados" vía SSH a MySQL.

2018-01-23 Por tema Matias Mucciolo

On Tuesday, January 23, 2018 5:29:07 PM -03 Ramses wrote:
> Hola a tod@s,
> 
> Tengo instalado MySQL Server con su proceso habitual.
> 
> Ahora quiero dar acceso a Clientes vía SSH, pero no quiero que esos usuarios
> puedan ejecutar comandos de la Shell de Linux mediante el comando "system"
> de MySQL.
> 
> Parece ser que no hay forma de impedir los Usuarios de MySQL puedan ejecutar
> el comando "system" y la única forma de limitar el uso de los comandos del
> Shell de Linux es enjaular (chroot jail) estos Usuarios SSH, y sólo copiar
> en la jaula los comandos que les permito y sus librerías asociadas.
> 
> Bien, tengo ya el entorno "chroot jail" configurado y el Usuario SSH se
> conecta.
> 
> He copiado el fichero de arranque "/usr/sbin/mysql" en el directorio
> "enjaulado".
> 
> Con el comando "ldd /usr/sbin/mysql" averiguo las librerías asociadas y las
> he copiado en el directorio "enjaulado".
> 
> Ahora, cuando se conecta un Usuario "enjaulado" vía SSH y ejecuta, por
> ejemplo, "/usr/sbin/mysql -u root -p", MySQL pide la password, pero al
> introducirla, da un error de socket diciendo que no encuentra
> "/var/run/mysqld/mysqld.sock", y ahí estoy estancado...
> 
> ¿Hay alguien que haya hecho esto y pueda comentarme qué pasos me faltan por
> hacer?
> 
> 
> Gracias y saludos,
> 
> Ramses

obviamente se estan tratando de conectar mediante el socket 
que crea mysql y los clientes enjaulados no pueden acceder.
creo que mysql tiene una opcion para que la "conexion"
sea por tcp...eso deberia funcionar..

saludos
Matias

Conectar desde clientes "enjaulados" vía SSH a MySQL.

2018-01-23 Por tema Ramses

Hola a tod@s,

Tengo instalado MySQL Server con su proceso habitual.

Ahora quiero dar acceso a Clientes vía SSH, pero no quiero que esos usuarios 
puedan ejecutar comandos de la Shell de Linux mediante el comando "system" de 
MySQL.

Parece ser que no hay forma de impedir los Usuarios de MySQL puedan ejecutar el 
comando "system" y la única forma de limitar el uso de los comandos del Shell 
de Linux es enjaular (chroot jail) estos Usuarios SSH, y sólo copiar en la 
jaula los comandos que les permito y sus librerías asociadas.

Bien, tengo ya el entorno "chroot jail" configurado y el Usuario SSH se conecta.

He copiado el fichero de arranque "/usr/sbin/mysql" en el directorio 
"enjaulado".

Con el comando "ldd /usr/sbin/mysql" averiguo las librerías asociadas y las he 
copiado en el directorio "enjaulado".

Ahora, cuando se conecta un Usuario "enjaulado" vía SSH y ejecuta, por ejemplo, 
"/usr/sbin/mysql -u root -p", MySQL pide la password, pero al introducirla, da 
un error de socket diciendo que no encuentra "/var/run/mysqld/mysqld.sock", y 
ahí estoy estancado...

¿Hay alguien que haya hecho esto y pueda comentarme qué pasos me faltan por 
hacer?


Gracias y saludos,

Ramses

Re: acceso por ssh permite dos claves distintas... [SOLUCIONADO]

2017-11-22 Por tema Walter O. Dari


Omití poner SOLUCIONADO en las respuestas anteriores...


--

Walter O. Dari

http://swcomputacion.com/
http://swcomputacion.com/sistemas/
https://facebook.com/swcomputacion/
https://facebook.com/sistemasSW/

Re: acceso por ssh permite dos claves distintas...

2017-11-21 Por tema Walter O. Dari


El 21/11/17 a las 14:22, Erick Ocrospoma escribió:

Hola,

Solo se me ocurren 2 escenarios:

1) Que el servidor en cuestion este autenticado con 
LDAP/ActiveDirectory, y que tengas un usuario con el mismo nombre en 
ambos lados.


Luego de dar unas cuantas vueltas, descubrí que la clave "vieja" estaba 
configurada para ingresar en samba. Estaba convencido que la había 
cambiado, evidentemente voy a tener que revisar mis "convencimientos".


Muchas gracias por la ayuda !





2) Que tengas el sudoers modificado y que este apuntando a otro usuario 
(una especie de alias).


Puedes revisar tu /var/log/auth.log para que tengas mejor detalle.

2017-11-21 9:03 GMT-05:00 Walter O. Dari <wlin...@gmail.com 
<mailto:wlin...@gmail.com>>:


El 20/11/17 a las 22:03, Cristian Mitchell escribiÃ³:



El 20 de noviembre de 2017, 18:38, Walter O.
Dari<wlin...@gmail.com <mailto:wlin...@gmail.com>
<mailto:wlin...@gmail.com <mailto:wlin...@gmail.com>>> escribiÃƒÂ³:

Â  Â  Hola gente, es raro lo que me pasÃƒÂ³.

Â  Â  Tengo un servidor (debian wheezy) al cual accedo
normalmente desde
Â  Â  mi equipo de escritorio mediante ssh sin necesidad de
contraseÃƒÂ±a ya
Â  Â  que valida por "key", mi equipo estÃƒÂ¡ dentro de
authorized_keys en
Â  Â  el servidor.

Â  Â  Hoy tuve que ingresar desde una notebook que no estÃƒÂ¡
registrada en
Â  Â  ese servidor por lo que me pide contraseÃƒÂ±a.
Inmediatamente despuÃƒÂ©s
Â  Â  de ingresarla y apretar [Enter] me doy cuenta que habÃƒÂa
puesto una
Â  Â  vieja, la sorpresa fue que ingresÃƒÂ© al servidor sin
problemas.

Â  Â  Me desconectÃƒÂ© y volvÃƒÂ a ingresar y nuevamente me
aceptÃƒÂ³ la
Â  Â  contraseÃƒÂ±a vieja.

Â  Â  VolvÃƒÂ a desconectarme y probÃƒÂ© ingresar nuevamente,
esta vez con la
Â  Â  contraseÃƒÂ±a actual y tambiÃƒÂ©n me permitiÃƒÂ³ el ingreso.

Â  Â  Ante esta situaciÃƒÂ³n, nuevamente me desconectÃƒÂ© y
probÃƒÂ© con una
Â  Â  contraseÃƒÂ±a inventada y me rechazÃƒÂ³.

Â  Â  Es como que "recuerda" contraseÃƒÂ±as anteriores.
Seguramente es una
Â  Â  falla del ssh, no ?

Â  Â  Saludos,

Â  Â  --
Â  Â  Walter O. Dari

Â  Â http://swcomputacion.com/
Â  Â http://swcomputacion.com/sistemas/
<http://swcomputacion.com/sistemas/>
<http://swcomputacion.com/sistemas/
<http://swcomputacion.com/sistemas/>>
Â  Â https://facebook.com/swcomputacion/
<https://facebook.com/swcomputacion/>
Â  Â  <https://facebook.com/swcomputacion/
<https://facebook.com/swcomputacion/>>
Â  Â https://facebook.com/sistemasSW/
<https://facebook.com/sistemasSW/>
<https://facebook.com/sistemasSW/
<https://facebook.com/sistemasSW/>>


En cualquier caso eso depende del linux
es un tema de pam
empezar por /etc/shadow


Estas son 3 lÃneas de distintos usuarios del shadow del servidor.
La primera responde al usuario en cuestiÃ³n que permite ingresar con
la clave vigente y una anterior.
Puede ser que en esa lÃnea, mÃ¡s larga que las de los dos usuarios
siguientes, figuren las dos claves (o 3) por la longitud que tiene ?


user1:$6$AhJci8V7$X6ryudeX8LZUl.J9t32S/1C/DrDqO2/DQexGvBiewzIbekjl9B1Gyna50AsMgSVi/dg.h2RmN8zqLQLML8gNC0:16456:0:9:7:::
user2:$1$y5c69jJc$y8bl3oxIYjDOvW1XH9rXE/:14174:0:9:7:::
user3:$1$zY4VlxPh$eH/w.lgbCGltnlm/vKL0s.:14174:0:9:7:::

Estuve buscando en Google pero no obtuve resultados, a lo mejor
estÃ¡ mal planteada la bÃºsqueda...


https://www.google.com.ar/search?ei=EDAUWqzADcKHwQS5jaZA=etc%2Fshadow+mas+de+una+clave+para+un+usuario=etc%2Fshadow+mas+de+una+clave+para+un+usuario_l=psy-ab.3...67255.67255.0.67893.1.1.0.0.0.0.124.124.0j1.1.00...1c.1.64.psy-ab..0.0.00.j2KMiqZqnOA

<https://www.google.com.ar/search?ei=EDAUWqzADcKHwQS5jaZA=etc%2Fshadow+mas+de+una+clave+para+un+usuario=etc%2Fshadow+mas+de+una+clave+para+un+usuario_l=psy-ab.3...67255.67255.0.67893.1.1.0.0.0.0.124.124.0j1.1.00...1c.1.64.psy-ab..0.0.00.j2KMiqZqnOA>



-- 
MrIX

Linux user number 412793.
http://counter.li.org/

las grandes obras,
las sueÃƒÂ±an los santos locos,
las realizan los luchadores natos,
las aprovechan los felices cuerdo,
y las critican los inÃƒÂºtiles crÃƒÂ³nicos,


Saludos,

-- 


Walter O. Dari

http://swcomputacion.com/
http://swcomputacion.com/sistemas/ <http://swcomputacion.com/sistemas/>
https://facebook.com/swcomputacion/
<https://facebook.com/swcomputacion/>
https://facebook.com/sistemasSW/ <ht

Re: acceso por ssh permite dos claves distintas...

2017-11-21 Por tema Walter O. Dari


El 21/11/17 a las 21:58, Cristian Mitchell escribió:



El 21 de noviembre de 2017, 17:05, Walter O. Dari<wlin...@gmail.com 
<mailto:wlin...@gmail.com>> escribiÃ³:


El 21/11/17 a las 16:02, Cristian Mitchell escribiÃ³:



El 21 de noviembre de 2017, 14:22, Erick
Ocrospoma<zipper1...@gmail.com <mailto:zipper1...@gmail.com>
<mailto:zipper1...@gmail.com <mailto:zipper1...@gmail.com>>>
escribiÃƒÂ³:

Â  Â  Hola,

Â  Â  Solo se me ocurren 2 escenarios:

Â  Â  1) Que el servidor en cuestion este autenticado con
Â  Â  LDAP/ActiveDirectory, y que tengas un usuario con el mismo
nombre en
Â  Â  ambos lados.

Â  Â  2) Que tengas el sudoers modificado y que este apuntando a
otro
Â  Â  usuario (una especie de alias).

Â  Â  Puedes revisar tu /var/log/auth.log para que tengas mejor
detalle.

Â  Â  2017-11-21 9:03 GMT-05:00 Walter O. Dari
<wlin...@gmail.com <mailto:wlin...@gmail.com>
Â  Â  <mailto:wlin...@gmail.com <mailto:wlin...@gmail.com>>>:

Â  Â  Â  Â  El 20/11/17 a las 22:03, Cristian Mitchell escribiÃƒÂ³:



Â  Â  Â  Â  Â  Â  El 20 de noviembre de 2017, 18:38, Walter O.
Â  Â  Â  Â  Â  Â  Dari<wlin...@gmail.com
<mailto:wlin...@gmail.com> <mailto:wlin...@gmail.com
<mailto:wlin...@gmail.com>>
Â  Â  Â  Â  Â  Â  <mailto:wlin...@gmail.com
<mailto:wlin...@gmail.com> <mailto:wlin...@gmail.com
<mailto:wlin...@gmail.com>>>>
Â  Â  Â  Â  Â  Â  escribiÃƒÆ’Ã‚Â³:

Â  Â  Â  Â  Â  Â  Ã‚Â  Ã‚Â  Hola gente, es raro lo que me
pasÃƒÆ’Ã‚Â³.

Â  Â  Â  Â  Â  Â  Ã‚Â  Ã‚Â  Tengo un servidor (debian wheezy) al
cual accedo
    Â  Â  Â  Â  Â  Â  normalmente desde
Â  Â  Â  Â  Â  Â  Ã‚Â  Ã‚Â  mi equipo de escritorio mediante ssh
sin necesidad de
Â  Â  Â  Â  Â  Â  contraseÃƒÆ’Ã‚Â±a ya
Â  Â  Â  Â  Â  Â  Ã‚Â  Ã‚Â  que valida por "key", mi equipo
estÃƒÆ’Ã‚Â¡ dentro de
Â  Â  Â  Â  Â  Â  authorized_keys en
Â  Â  Â  Â  Â  Â  Ã‚Â  Ã‚Â  el servidor.

Â  Â  Â  Â  Â  Â  Ã‚Â  Ã‚Â  Hoy tuve que ingresar desde una
notebook que no
Â  Â  Â  Â  Â  Â  estÃƒÆ’Ã‚Â¡ registrada en
Â  Â  Â  Â  Â  Â  Ã‚Â  Ã‚Â  ese servidor por lo que me pide
contraseÃƒÆ’Ã‚Â±a.
Â  Â  Â  Â  Â  Â  Inmediatamente despuÃƒÆ’Ã‚Â©s
Â  Â  Â  Â  Â  Â  Ã‚Â  Ã‚Â  de ingresarla y apretar [Enter] me
doy cuenta que
Â  Â  Â  Â  Â  Â  habÃƒÆ’Ã‚Âa puesto una
Â  Â  Â  Â  Â  Â  Ã‚Â  Ã‚Â  vieja, la sorpresa fue que
ingresÃƒÆ’Ã‚Â© al servidor sin
Â  Â  Â  Â  Â  Â  problemas.

Â  Â  Â  Â  Â  Â  Ã‚Â  Ã‚Â  Me desconectÃƒÆ’Ã‚Â© y volvÃƒÆ’Ã‚Â
a ingresar y nuevamente me
Â  Â  Â  Â  Â  Â  aceptÃƒÆ’Ã‚Â³ la
Â  Â  Â  Â  Â  Â  Ã‚Â  Ã‚Â  contraseÃƒÆ’Ã‚Â±a vieja.

Â  Â  Â  Â  Â  Â  Ã‚Â  Ã‚Â  VolvÃƒÆ’Ã‚Â a desconectarme y
probÃƒÆ’Ã‚Â© ingresar
Â  Â  Â  Â  Â  Â  nuevamente, esta vez con la
Â  Â  Â  Â  Â  Â  Ã‚Â  Ã‚Â  contraseÃƒÆ’Ã‚Â±a actual y
tambiÃƒÆ’Ã‚Â©n me permitiÃƒÆ’Ã‚Â³ el
Â  Â  Â  Â  Â  Â  ingreso.

Â  Â  Â  Â  Â  Â  Ã‚Â  Ã‚Â  Ante esta situaciÃƒÆ’Ã‚Â³n,
nuevamente me desconectÃƒÆ’Ã‚Â© y
Â  Â  Â  Â  Â  Â  probÃƒÆ’Ã‚Â© con una
Â  Â  Â  Â  Â  Â  Ã‚Â  Ã‚Â  contraseÃƒÆ’Ã‚Â±a inventada y me
rechazÃƒÆ’Ã‚Â³.

Â  Â  Â  Â  Â  Â  Ã‚Â  Ã‚Â  Es como que "recuerda"
        contraseÃƒÆ’Ã‚Â±as anteriores.
Â  Â  Â  Â  Â  Â  Seguramente es una
Â  Â  Â  Â  Â  Â  Ã‚Â  Ã‚Â  falla del ssh, no ?

Â  Â  Â  Â  Â  Â  Ã‚Â  Ã‚Â  Saludos,

Â  Â  Â  Â  Â  Â  Ã‚Â  Ã‚Â  --
Â  Â  Â  Â  Â  Â  Ã‚Â  Ã‚Â  Walter O. Dari

Â  Â  Â  Â  Â  Â  Ã‚Â  Ã‚ http://swcomputacion.com/
Â  Â  Â  Â  Â  Â  Ã‚Â  Ã‚ http://swcomputacion.com/sistemas/
<http://swcomputacion.com/sistemas/>
Â  Â  Â  Â  Â  Â  <http://swcomputacion.com/sistemas/
<http://swcomputacion.com/sistemas/>>
Â  Â  Â  Â  Â  Â  <http://swcomputacion.com/sistemas/
<http://swcomputacion.com/sistemas/>
Â  Â  Â  Â  Â  Â  <http://swcomputacion.com/sistemas/
<http://swcomputacion.com/sistemas/>>>
Â  Â  Â  Â  Â  Â  Ã‚Â  Ã‚ https://facebook.com/swcomputacion/
<https://facebook.com/swcomputacion/>
Â  Â  Â  Â  Â  Â  <https://facebook.com/swcomputacion/
<https://facebook.com/swcomputacion/>>
Â  Â  Â  Â  Â  Â  Ã‚Â  Ã‚Â  <https://facebook.com/swcomputacion/
<https://facebook.com/swcomputacion/>
Â  Â  Â  Â  Â  Â  <https://facebook.com/swcomputacion/
<https://facebook.com/swcomputacion/>>>
Â  Â

Re: acceso por ssh permite dos claves distintas...

2017-11-21 Por tema Cristian Mitchell

El 21 de noviembre de 2017, 17:05, Walter O. Dari<wlin...@gmail.com>
escribió:

> El 21/11/17 a las 16:02, Cristian Mitchell escribió:
>
>>
>>
>> El 21 de noviembre de 2017, 14:22, Erick Ocrospoma<zipper1...@gmail.com
>> <mailto:zipper1...@gmail.com>> escribiÃ³:
>>
>> Hola,
>>
>> Solo se me ocurren 2 escenarios:
>>
>> 1) Que el servidor en cuestion este autenticado con
>> LDAP/ActiveDirectory, y que tengas un usuario con el mismo nombre en
>> ambos lados.
>>
>> 2) Que tengas el sudoers modificado y que este apuntando a otro
>> usuario (una especie de alias).
>>
>> Puedes revisar tu /var/log/auth.log para que tengas mejor detalle.
>>
>> 2017-11-21 9:03 GMT-05:00 Walter O. Dari <wlin...@gmail.com
>> <mailto:wlin...@gmail.com>>:
>>
>> El 20/11/17 a las 22:03, Cristian Mitchell escribiÃ³:
>>
>>
>>
>> El 20 de noviembre de 2017, 18:38, Walter O.
>> Dari<wlin...@gmail.com <mailto:wlin...@gmail.com>
>> <mailto:wlin...@gmail.com <mailto:wlin...@gmail.com>>>
>> escribiÃƒÂ³:
>>
>> Â  Â  Hola gente, es raro lo que me pasÃƒÂ³.
>>
>> Â  Â  Tengo un servidor (debian wheezy) al cual accedo
>> normalmente desde
>> Â  Â  mi equipo de escritorio mediante ssh sin necesidad de
>> contraseÃƒÂ±a ya
>> Â  Â  que valida por "key", mi equipo estÃƒÂ¡ dentro de
>> authorized_keys en
>> Â  Â  el servidor.
>>
>> Â  Â  Hoy tuve que ingresar desde una notebook que no
>> estÃƒÂ¡ registrada en
>> Â  Â  ese servidor por lo que me pide contraseÃƒÂ±a.
>> Inmediatamente despuÃƒÂ©s
>> Â  Â  de ingresarla y apretar [Enter] me doy cuenta que
>> habÃƒÂa puesto una
>> Â  Â  vieja, la sorpresa fue que ingresÃƒÂ© al servidor sin
>> problemas.
>>
>> Â  Â  Me desconectÃƒÂ© y volvÃƒÂ a ingresar y nuevamente me
>> aceptÃƒÂ³ la
>> Â  Â  contraseÃƒÂ±a vieja.
>>
>> Â  Â  VolvÃƒÂ a desconectarme y probÃƒÂ© ingresar
>> nuevamente, esta vez con la
>>     Â  Â  contraseÃƒÂ±a actual y tambiÃƒÂ©n me permitiÃƒÂ³ el
>> ingreso.
>>
>> Â  Â  Ante esta situaciÃƒÂ³n, nuevamente me desconectÃƒÂ© y
>> probÃƒÂ© con una
>> Â  Â  contraseÃƒÂ±a inventada y me rechazÃƒÂ³.
>>
>> Â  Â  Es como que "recuerda" contraseÃƒÂ±as anteriores.
>> Seguramente es una
>> Â  Â  falla del ssh, no ?
>>
>> Â  Â  Saludos,
>>
>> Â  Â  --
>> Â  Â  Walter O. Dari
>>
>> Â  Â http://swcomputacion.com/
>> Â  Â http://swcomputacion.com/sistemas/
>> <http://swcomputacion.com/sistemas/>
>> <http://swcomputacion.com/sistemas/
>> <http://swcomputacion.com/sistemas/>>
>> Â  Â https://facebook.com/swcomputacion/
>> <https://facebook.com/swcomputacion/>
>> Â  Â  <https://facebook.com/swcomputacion/
>> <https://facebook.com/swcomputacion/>>
>> Â  Â https://facebook.com/sistemasSW/
>> <https://facebook.com/sistemasSW/>
>> <https://facebook.com/sistemasSW/
>> <https://facebook.com/sistemasSW/>>
>>
>>
>> En cualquier caso eso depende del linux
>> es un tema de pam
>> empezar por /etc/shadow
>>
>>
>> Estas son 3 lÃneas de distintos usuarios del shadow del servidor.
>> La primera responde al usuario en cuestiÃ³n que permite ingresar
>> con la clave vigente y una anterior.
>> Puede ser que en esa lÃnea, mÃ¡s larga que las de los dos
>> usuarios siguientes, figuren las dos claves (o 3) por la
>> longitud que tiene ?
>>
>> user1:$6$AhJci8V7$X6ryudeX8LZUl.J9t32S/1C/DrDqO2/DQexGvBiewz
>> Ibekjl9B1Gyna50AsMgSVi/dg.h2RmN8zqLQLML8gNC0:16456:0:9:7:::
>> user2:$1$y5c69jJc$y8bl3oxIYjDOvW1XH9rXE/:14174:0:9:7:::
>> user3:$1$zY4VlxPh$eH/w.lgbCGltnlm/vKL0s.:14174:0:9:7:::
>>
>> Estuve buscando en Google pero no obtuve resu

Re: acceso por ssh permite dos claves distintas...

2017-11-21 Por tema Walter O. Dari


El 21/11/17 a las 16:02, Cristian Mitchell escribió:



El 21 de noviembre de 2017, 14:22, Erick Ocrospoma<zipper1...@gmail.com 
<mailto:zipper1...@gmail.com>> escribiÃ³:


Hola,

Solo se me ocurren 2 escenarios:

1) Que el servidor en cuestion este autenticado con
LDAP/ActiveDirectory, y que tengas un usuario con el mismo nombre en
ambos lados.

2) Que tengas el sudoers modificado y que este apuntando a otro
usuario (una especie de alias).

Puedes revisar tu /var/log/auth.log para que tengas mejor detalle.

2017-11-21 9:03 GMT-05:00 Walter O. Dari <wlin...@gmail.com
<mailto:wlin...@gmail.com>>:

El 20/11/17 a las 22:03, Cristian Mitchell escribiÃ³:



El 20 de noviembre de 2017, 18:38, Walter O.
Dari<wlin...@gmail.com <mailto:wlin...@gmail.com>
<mailto:wlin...@gmail.com <mailto:wlin...@gmail.com>>>
escribiÃƒÂ³:

Â  Â  Hola gente, es raro lo que me pasÃƒÂ³.

Â  Â  Tengo un servidor (debian wheezy) al cual accedo
normalmente desde
        Â  Â  mi equipo de escritorio mediante ssh sin necesidad de
contraseÃƒÂ±a ya
Â  Â  que valida por "key", mi equipo estÃƒÂ¡ dentro de
authorized_keys en
Â  Â  el servidor.

Â  Â  Hoy tuve que ingresar desde una notebook que no
estÃƒÂ¡ registrada en
Â  Â  ese servidor por lo que me pide contraseÃƒÂ±a.
Inmediatamente despuÃƒÂ©s
Â  Â  de ingresarla y apretar [Enter] me doy cuenta que
habÃƒÂa puesto una
Â  Â  vieja, la sorpresa fue que ingresÃƒÂ© al servidor sin
problemas.

Â  Â  Me desconectÃƒÂ© y volvÃƒÂ a ingresar y nuevamente me
aceptÃƒÂ³ la
Â  Â  contraseÃƒÂ±a vieja.

Â  Â  VolvÃƒÂ a desconectarme y probÃƒÂ© ingresar
nuevamente, esta vez con la
Â  Â  contraseÃƒÂ±a actual y tambiÃƒÂ©n me permitiÃƒÂ³ el
ingreso.

Â  Â  Ante esta situaciÃƒÂ³n, nuevamente me desconectÃƒÂ© y
probÃƒÂ© con una
Â  Â  contraseÃƒÂ±a inventada y me rechazÃƒÂ³.

Â  Â  Es como que "recuerda" contraseÃƒÂ±as anteriores.
Seguramente es una
Â  Â  falla del ssh, no ?

Â  Â  Saludos,

Â  Â  --
Â  Â  Walter O. Dari

Â  Â http://swcomputacion.com/
Â  Â http://swcomputacion.com/sistemas/
<http://swcomputacion.com/sistemas/>
<http://swcomputacion.com/sistemas/
<http://swcomputacion.com/sistemas/>>
Â  Â https://facebook.com/swcomputacion/
<https://facebook.com/swcomputacion/>
Â  Â  <https://facebook.com/swcomputacion/
<https://facebook.com/swcomputacion/>>
Â  Â https://facebook.com/sistemasSW/
<https://facebook.com/sistemasSW/>
<https://facebook.com/sistemasSW/
<https://facebook.com/sistemasSW/>>


En cualquier caso eso depende del linux
es un tema de pam
empezar por /etc/shadow


Estas son 3 lÃneas de distintos usuarios del shadow del servidor.
La primera responde al usuario en cuestiÃ³n que permite ingresar
con la clave vigente y una anterior.
Puede ser que en esa lÃnea, mÃ¡s larga que las de los dos
usuarios siguientes, figuren las dos claves (o 3) por la
longitud que tiene ?


user1:$6$AhJci8V7$X6ryudeX8LZUl.J9t32S/1C/DrDqO2/DQexGvBiewzIbekjl9B1Gyna50AsMgSVi/dg.h2RmN8zqLQLML8gNC0:16456:0:9:7:::
user2:$1$y5c69jJc$y8bl3oxIYjDOvW1XH9rXE/:14174:0:9:7:::
user3:$1$zY4VlxPh$eH/w.lgbCGltnlm/vKL0s.:14174:0:9:7:::

Estuve buscando en Google pero no obtuve resultados, a lo mejor
estÃ¡ mal planteada la bÃºsqueda...


https://www.google.com.ar/search?ei=EDAUWqzADcKHwQS5jaZA=etc%2Fshadow+mas+de+una+clave+para+un+usuario=etc%2Fshadow+mas+de+una+clave+para+un+usuario_l=psy-ab.3...67255.67255.0.67893.1.1.0.0.0.0.124.124.0j1.1.00...1c.1.64.psy-ab..0.0.00.j2KMiqZqnOA

<https://www.google.com.ar/search?ei=EDAUWqzADcKHwQS5jaZA=etc%2Fshadow+mas+de+una+clave+para+un+usuario=etc%2Fshadow+mas+de+una+clave+para+un+usuario_l=psy-ab.3...67255.67255.0.67893.1.1.0.0.0.0.124.124.0j1.1.00...1c.1.64.psy-ab..0.0.00.j2KMiqZqnOA>



-- 
MrIX

Linux user number 412793.
http://counter.li.org/

las grandes obras,
las sueÃƒÂ±an los santos locos,
las realizan los luchadores natos,
las aprovechan los felices cuerdo,
y las critican los inÃƒÂºtiles crÃƒÂ³nicos,


Saludos,

-- 


Walter O. Dari

Re: acceso por ssh permite dos claves distintas...

2017-11-21 Por tema Walter O. Dari


Hola Erick...

El 21/11/17 a las 14:22, Erick Ocrospoma escribió:

Hola,

Solo se me ocurren 2 escenarios:

1) Que el servidor en cuestion este autenticado con 
LDAP/ActiveDirectory, y que tengas un usuario con el mismo nombre en 
ambos lados.


El servidor también tiene samba instalado para compartir algunos datos 
con equipos con Windows, el usuario tiene el mismo nombre pero también 
la clave es igual a la última que estoy usando.


2) Que tengas el sudoers modificado y que este apuntando a otro usuario 
(una especie de alias).


No estoy utilizando nada de sudoers, tiene la configuración por defecto 
que queda al instalar Debian.




Puedes revisar tu /var/log/auth.log para que tengas mejor detalle.


Ahora veo que auth.log tiene fecha del 2-ene-2015, por algún motivo no 
está registrando la actividad.


Bueno, algo más para ver.






2017-11-21 9:03 GMT-05:00 Walter O. Dari <wlin...@gmail.com 
<mailto:wlin...@gmail.com>>:


El 20/11/17 a las 22:03, Cristian Mitchell escribiÃ³:



El 20 de noviembre de 2017, 18:38, Walter O.
Dari<wlin...@gmail.com <mailto:wlin...@gmail.com>
<mailto:wlin...@gmail.com <mailto:wlin...@gmail.com>>> escribiÃƒÂ³:

Â  Â  Hola gente, es raro lo que me pasÃƒÂ³.

Â  Â  Tengo un servidor (debian wheezy) al cual accedo
normalmente desde
Â  Â  mi equipo de escritorio mediante ssh sin necesidad de
contraseÃƒÂ±a ya
Â  Â  que valida por "key", mi equipo estÃƒÂ¡ dentro de
authorized_keys en
Â  Â  el servidor.

Â  Â  Hoy tuve que ingresar desde una notebook que no estÃƒÂ¡
registrada en
Â  Â  ese servidor por lo que me pide contraseÃƒÂ±a.
Inmediatamente despuÃƒÂ©s
Â  Â  de ingresarla y apretar [Enter] me doy cuenta que habÃƒÂa
puesto una
Â  Â  vieja, la sorpresa fue que ingresÃƒÂ© al servidor sin
problemas.

Â  Â  Me desconectÃƒÂ© y volvÃƒÂ a ingresar y nuevamente me
aceptÃƒÂ³ la
Â  Â  contraseÃƒÂ±a vieja.

Â  Â  VolvÃƒÂ a desconectarme y probÃƒÂ© ingresar nuevamente,
esta vez con la
Â  Â  contraseÃƒÂ±a actual y tambiÃƒÂ©n me permitiÃƒÂ³ el ingreso.

Â  Â  Ante esta situaciÃƒÂ³n, nuevamente me desconectÃƒÂ© y
probÃƒÂ© con una
Â  Â  contraseÃƒÂ±a inventada y me rechazÃƒÂ³.

Â  Â  Es como que "recuerda" contraseÃƒÂ±as anteriores.
Seguramente es una
Â  Â  falla del ssh, no ?

Â  Â  Saludos,

Â  Â  --
Â  Â  Walter O. Dari

Â  Â http://swcomputacion.com/
Â  Â http://swcomputacion.com/sistemas/
<http://swcomputacion.com/sistemas/>
<http://swcomputacion.com/sistemas/
<http://swcomputacion.com/sistemas/>>
Â  Â https://facebook.com/swcomputacion/
<https://facebook.com/swcomputacion/>
Â  Â  <https://facebook.com/swcomputacion/
<https://facebook.com/swcomputacion/>>
Â  Â https://facebook.com/sistemasSW/
<https://facebook.com/sistemasSW/>
<https://facebook.com/sistemasSW/
<https://facebook.com/sistemasSW/>>


En cualquier caso eso depende del linux
es un tema de pam
empezar por /etc/shadow


Estas son 3 lÃneas de distintos usuarios del shadow del servidor.
La primera responde al usuario en cuestiÃ³n que permite ingresar con
la clave vigente y una anterior.
Puede ser que en esa lÃnea, mÃ¡s larga que las de los dos usuarios
siguientes, figuren las dos claves (o 3) por la longitud que tiene ?


user1:$6$AhJci8V7$X6ryudeX8LZUl.J9t32S/1C/DrDqO2/DQexGvBiewzIbekjl9B1Gyna50AsMgSVi/dg.h2RmN8zqLQLML8gNC0:16456:0:9:7:::
user2:$1$y5c69jJc$y8bl3oxIYjDOvW1XH9rXE/:14174:0:9:7:::
user3:$1$zY4VlxPh$eH/w.lgbCGltnlm/vKL0s.:14174:0:9:7:::

Estuve buscando en Google pero no obtuve resultados, a lo mejor
estÃ¡ mal planteada la bÃºsqueda...


https://www.google.com.ar/search?ei=EDAUWqzADcKHwQS5jaZA=etc%2Fshadow+mas+de+una+clave+para+un+usuario=etc%2Fshadow+mas+de+una+clave+para+un+usuario_l=psy-ab.3...67255.67255.0.67893.1.1.0.0.0.0.124.124.0j1.1.00...1c.1.64.psy-ab..0.0.00.j2KMiqZqnOA

<https://www.google.com.ar/search?ei=EDAUWqzADcKHwQS5jaZA=etc%2Fshadow+mas+de+una+clave+para+un+usuario=etc%2Fshadow+mas+de+una+clave+para+un+usuario_l=psy-ab.3...67255.67255.0.67893.1.1.0.0.0.0.124.124.0j1.1.00...1c.1.64.psy-ab..0.0.00.j2KMiqZqnOA>



-- 
MrIX

Linux user number 412793.
http://counter.li.org/

las grandes obras,
las sueÃƒÂ±an los santos locos,
las realizan los luchadores natos,
las aprovechan los felices cuerdo,
y las critican los inÃƒÂºtiles crÃƒÂ³nicos,


Saludos,

-- 


Walter O. Dari

http://swcomputacion.com/
http://swcomputacion.

Re: acceso por ssh permite dos claves distintas...

2017-11-21 Por tema Cristian Mitchell

El 21 de noviembre de 2017, 14:22, Erick Ocrospoma<zipper1...@gmail.com>
escribió:

> Hola,
>
> Solo se me ocurren 2 escenarios:
>
> 1) Que el servidor en cuestion este autenticado con LDAP/ActiveDirectory,
> y que tengas un usuario con el mismo nombre en ambos lados.
>
> 2) Que tengas el sudoers modificado y que este apuntando a otro usuario
> (una especie de alias).
>
> Puedes revisar tu /var/log/auth.log para que tengas mejor detalle.
>
> 2017-11-21 9:03 GMT-05:00 Walter O. Dari <wlin...@gmail.com>:
>
>> El 20/11/17 a las 22:03, Cristian Mitchell escribió:
>>
>>>
>>>
>>> El 20 de noviembre de 2017, 18:38, Walter O. Dari<wlin...@gmail.com
>>> <mailto:wlin...@gmail.com>> escribiÃ³:
>>>
>>> Hola gente, es raro lo que me pasÃ³.
>>>
>>> Tengo un servidor (debian wheezy) al cual accedo normalmente desde
>>> mi equipo de escritorio mediante ssh sin necesidad de contraseÃ±a ya
>>> que valida por "key", mi equipo estÃ¡ dentro de authorized_keys en
>>> el servidor.
>>>
>>> Hoy tuve que ingresar desde una notebook que no estÃ¡ registrada en
>>> ese servidor por lo que me pide contraseÃ±a. Inmediatamente despuÃ©s
>>> de ingresarla y apretar [Enter] me doy cuenta que habÃa puesto una
>>> vieja, la sorpresa fue que ingresÃ© al servidor sin problemas.
>>>
>>> Me desconectÃ© y volvÃ a ingresar y nuevamente me aceptÃ³ la
>>> contraseÃ±a vieja.
>>>
>>> VolvÃ a desconectarme y probÃ© ingresar nuevamente, esta vez con la
>>> contraseÃ±a actual y tambiÃ©n me permitiÃ³ el ingreso.
>>>
>>> Ante esta situaciÃ³n, nuevamente me desconectÃ© y probÃ© con una
>>> contraseÃ±a inventada y me rechazÃ³.
>>>
>>> Es como que "recuerda" contraseÃ±as anteriores. Seguramente es una
>>> falla del ssh, no ?
>>>
>>> Saludos,
>>>
>>> --
>>> Walter O. Dari
>>>
>>> http://swcomputacion.com/
>>> http://swcomputacion.com/sistemas/ <http://swcomputacion.com/sist
>>> emas/>
>>> https://facebook.com/swcomputacion/
>>> <https://facebook.com/swcomputacion/>
>>> https://facebook.com/sistemasSW/ <https://facebook.com/sistemasSW/>
>>>
>>>
>>> En cualquier caso eso depende del linux
>>> es un tema de pam
>>> empezar por /etc/shadow
>>>
>>
>> Estas son 3 líneas de distintos usuarios del shadow del servidor.
>> La primera responde al usuario en cuestión que permite ingresar con la
>> clave vigente y una anterior.
>> Puede ser que en esa línea, más larga que las de los dos usuarios
>> siguientes, figuren las dos claves (o 3) por la longitud que tiene ?
>>
>> user1:$6$AhJci8V7$X6ryudeX8LZUl.J9t32S/1C/DrDqO2/DQexGvBiewz
>> Ibekjl9B1Gyna50AsMgSVi/dg.h2RmN8zqLQLML8gNC0:16456:0:9:7:::
>> user2:$1$y5c69jJc$y8bl3oxIYjDOvW1XH9rXE/:14174:0:9:7:::
>> user3:$1$zY4VlxPh$eH/w.lgbCGltnlm/vKL0s.:14174:0:9:7:::
>>
>> Estuve buscando en Google pero no obtuve resultados, a lo mejor está mal
>> planteada la búsqueda...
>>
>> https://www.google.com.ar/search?ei=EDAUWqzADcKHwQS5jaZA=e
>> tc%2Fshadow+mas+de+una+clave+para+un+usuario=etc%2Fshadow
>> +mas+de+una+clave+para+un+usuario_l=psy-ab.3...67255.6725
>> 5.0.67893.1.1.0.0.0.0.124.124.0j1.1.00...1c.1.64.psy-ab.
>> .0.0.00.j2KMiqZqnOA
>>
>>
>>
>>> --
>>> MrIX
>>> Linux user number 412793.
>>> http://counter.li.org/
>>>
>>> las grandes obras,
>>> las sueÃ±an los santos locos,
>>> las realizan los luchadores natos,
>>> las aprovechan los felices cuerdo,
>>> y las critican los inÃºtiles crÃ³nicos,
>>>
>>>
>> Saludos,
>>
>> --
>>
>> Walter O. Dari
>>
>> http://swcomputacion.com/
>> http://swcomputacion.com/sistemas/
>> https://facebook.com/swcomputacion/
>> https://facebook.com/sistemasSW/
>>
>>
>
>
> --
>
>
> Erick.
>
>
> ---
> IRC :   zerick
> Blog: http://zerick.me
> About :  http://about.me/zerick
> Linux User ID :  549567
>

Hace la siguiente prueba

entra con una  clave y ejecuta

echo $UID

luego con la otra y lo mismo

echo $UID

y compara

si son el  mismo ID es el mismo usuario si son diferentes es lo contrario



-- 
MrIX
Linux user number 412793.
http://counter.li.org/

las grandes obras,
las sueñan los santos locos,
las realizan los luchadores natos,
las aprovechan los felices cuerdo,
y las critican los inútiles crónicos,

Re: acceso por ssh permite dos claves distintas...

2017-11-21 Por tema Erick Ocrospoma

Hola,

Solo se me ocurren 2 escenarios:

1) Que el servidor en cuestion este autenticado con LDAP/ActiveDirectory, y
que tengas un usuario con el mismo nombre en ambos lados.

2) Que tengas el sudoers modificado y que este apuntando a otro usuario
(una especie de alias).

Puedes revisar tu /var/log/auth.log para que tengas mejor detalle.

2017-11-21 9:03 GMT-05:00 Walter O. Dari <wlin...@gmail.com>:

> El 20/11/17 a las 22:03, Cristian Mitchell escribió:
>
>>
>>
>> El 20 de noviembre de 2017, 18:38, Walter O. Dari<wlin...@gmail.com
>> <mailto:wlin...@gmail.com>> escribiÃ³:
>>
>> Hola gente, es raro lo que me pasÃ³.
>>
>> Tengo un servidor (debian wheezy) al cual accedo normalmente desde
>> mi equipo de escritorio mediante ssh sin necesidad de contraseÃ±a ya
>> que valida por "key", mi equipo estÃ¡ dentro de authorized_keys en
>> el servidor.
>>
>> Hoy tuve que ingresar desde una notebook que no estÃ¡ registrada en
>> ese servidor por lo que me pide contraseÃ±a. Inmediatamente despuÃ©s
>> de ingresarla y apretar [Enter] me doy cuenta que habÃa puesto una
>> vieja, la sorpresa fue que ingresÃ© al servidor sin problemas.
>>
>> Me desconectÃ© y volvÃ a ingresar y nuevamente me aceptÃ³ la
>> contraseÃ±a vieja.
>>
>> VolvÃ a desconectarme y probÃ© ingresar nuevamente, esta vez con la
>> contraseÃ±a actual y tambiÃ©n me permitiÃ³ el ingreso.
>>
>> Ante esta situaciÃ³n, nuevamente me desconectÃ© y probÃ© con una
>> contraseÃ±a inventada y me rechazÃ³.
>>
>> Es como que "recuerda" contraseÃ±as anteriores. Seguramente es una
>> falla del ssh, no ?
>>
>> Saludos,
>>
>> --
>> Walter O. Dari
>>
>> http://swcomputacion.com/
>> http://swcomputacion.com/sistemas/ <http://swcomputacion.com/sist
>> emas/>
>> https://facebook.com/swcomputacion/
>> <https://facebook.com/swcomputacion/>
>> https://facebook.com/sistemasSW/ <https://facebook.com/sistemasSW/>
>>
>>
>> En cualquier caso eso depende del linux
>> es un tema de pam
>> empezar por /etc/shadow
>>
>
> Estas son 3 líneas de distintos usuarios del shadow del servidor.
> La primera responde al usuario en cuestión que permite ingresar con la
> clave vigente y una anterior.
> Puede ser que en esa línea, más larga que las de los dos usuarios
> siguientes, figuren las dos claves (o 3) por la longitud que tiene ?
>
> user1:$6$AhJci8V7$X6ryudeX8LZUl.J9t32S/1C/DrDqO2/DQexGvBiewz
> Ibekjl9B1Gyna50AsMgSVi/dg.h2RmN8zqLQLML8gNC0:16456:0:9:7:::
> user2:$1$y5c69jJc$y8bl3oxIYjDOvW1XH9rXE/:14174:0:9:7:::
> user3:$1$zY4VlxPh$eH/w.lgbCGltnlm/vKL0s.:14174:0:9:7:::
>
> Estuve buscando en Google pero no obtuve resultados, a lo mejor está mal
> planteada la búsqueda...
>
> https://www.google.com.ar/search?ei=EDAUWqzADcKHwQS5jaZA=
> etc%2Fshadow+mas+de+una+clave+para+un+usuario=etc%2Fshado
> w+mas+de+una+clave+para+un+usuario_l=psy-ab.3...67255.
> 67255.0.67893.1.1.0.0.0.0.124.124.0j1.1.00...1c.1.64.
> psy-ab..0.0.00.j2KMiqZqnOA
>
>
>
>> --
>> MrIX
>> Linux user number 412793.
>> http://counter.li.org/
>>
>> las grandes obras,
>> las sueÃ±an los santos locos,
>> las realizan los luchadores natos,
>> las aprovechan los felices cuerdo,
>> y las critican los inÃºtiles crÃ³nicos,
>>
>>
> Saludos,
>
> --
>
> Walter O. Dari
>
> http://swcomputacion.com/
> http://swcomputacion.com/sistemas/
> https://facebook.com/swcomputacion/
> https://facebook.com/sistemasSW/
>
>


-- 


Erick.


---
IRC :   zerick
Blog: http://zerick.me
About :  http://about.me/zerick
Linux User ID :  549567

Re: acceso por ssh permite dos claves distintas...

2017-11-21 Por tema Walter O. Dari

El 20/11/17 a las 22:03, Cristian Mitchell escribió:

El 20 de noviembre de 2017, 18:38, Walter O. Dari<wlin...@gmail.com
<mailto:wlin...@gmail.com>> escribiÃ³:

Hola gente, es raro lo que me pasÃ³.

Tengo un servidor (debian wheezy) al cual accedo normalmente desde
mi equipo de escritorio mediante ssh sin necesidad de contraseÃ±a ya
que valida por "key", mi equipo estÃ¡ dentro de authorized_keys en
el servidor.

Hoy tuve que ingresar desde una notebook que no estÃ¡ registrada en
ese servidor por lo que me pide contraseÃ±a. Inmediatamente despuÃ©s
de ingresarla y apretar [Enter] me doy cuenta que habÃa puesto una
vieja, la sorpresa fue que ingresÃ© al servidor sin problemas.

VolvÃ a desconectarme y probÃ© ingresar nuevamente, esta vez con la
contraseÃ±a actual y tambiÃ©n me permitiÃ³ el ingreso.

Es como que "recuerda" contraseÃ±as anteriores. Seguramente es una
falla del ssh, no ?

Saludos,

Walter O. Dari

http://swcomputacion.com/
http://swcomputacion.com/sistemas/ <http://swcomputacion.com/sistemas/>
https://facebook.com/swcomputacion/
<https://facebook.com/swcomputacion/>
https://facebook.com/sistemasSW/ <https://facebook.com/sistemasSW/>

En cualquier caso eso depende del linux
es un tema de pam
empezar por /etc/shadow

Estas son 3 líneas de distintos usuarios del shadow del servidor.
La primera responde al usuario en cuestión que permite ingresar con la
clave vigente y una anterior.
Puede ser que en esa línea, más larga que las de los dos usuarios
siguientes, figuren las dos claves (o 3) por la longitud que tiene ?

user1:$6$AhJci8V7$X6ryudeX8LZUl.J9t32S/1C/DrDqO2/DQexGvBiewzIbekjl9B1Gyna50AsMgSVi/dg.h2RmN8zqLQLML8gNC0:16456:0:9:7:::
user2:$1$y5c69jJc$y8bl3oxIYjDOvW1XH9rXE/:14174:0:9:7:::
user3:$1$zY4VlxPh$eH/w.lgbCGltnlm/vKL0s.:14174:0:9:7:::

Estuve buscando en Google pero no obtuve resultados, a lo mejor está mal
planteada la búsqueda...

https://www.google.com.ar/search?ei=EDAUWqzADcKHwQS5jaZA=etc%2Fshadow+mas+de+una+clave+para+un+usuario=etc%2Fshadow+mas+de+una+clave+para+un+usuario_l=psy-ab.3...67255.67255.0.67893.1.1.0.0.0.0.124.124.0j1.1.00...1c.1.64.psy-ab..0.0.00.j2KMiqZqnOA

--
MrIX
Linux user number 412793.
http://counter.li.org/

las grandes obras,
las sueÃ±an los santos locos,
las realizan los luchadores natos,
las aprovechan los felices cuerdo,
y las critican los inÃºtiles crÃ³nicos,

Saludos,

Walter O. Dari

http://swcomputacion.com/
http://swcomputacion.com/sistemas/
https://facebook.com/swcomputacion/
https://facebook.com/sistemasSW/

Re: acceso por ssh permite dos claves distintas...

2017-11-20 Por tema Cristian Mitchell

El 20 de noviembre de 2017, 18:38, Walter O. Dari<wlin...@gmail.com>
escribió:

> Hola gente, es raro lo que me pasó.
>
> Tengo un servidor (debian wheezy) al cual accedo normalmente desde mi
> equipo de escritorio mediante ssh sin necesidad de contraseña ya que valida
> por "key", mi equipo está dentro de authorized_keys en el servidor.
>
> Hoy tuve que ingresar desde una notebook que no está registrada en ese
> servidor por lo que me pide contraseña. Inmediatamente después de
> ingresarla y apretar [Enter] me doy cuenta que había puesto una vieja, la
> sorpresa fue que ingresé al servidor sin problemas.
>
> Me desconecté y volví a ingresar y nuevamente me aceptó la contraseña
> vieja.
>
> Volví a desconectarme y probé ingresar nuevamente, esta vez con la
> contraseña actual y también me permitió el ingreso.
>
> Ante esta situación, nuevamente me desconecté y probé con una contraseña
> inventada y me rechazó.
>
> Es como que "recuerda" contraseñas anteriores. Seguramente es una falla
> del ssh, no ?
>
> Saludos,
>
> --
>
> Walter O. Dari
>
> http://swcomputacion.com/
> http://swcomputacion.com/sistemas/
> https://facebook.com/swcomputacion/
> https://facebook.com/sistemasSW/
>
>
En cualquier caso eso depende del linux
es un tema de pam
empezar por /etc/shadow

-- 
MrIX
Linux user number 412793.
http://counter.li.org/

las grandes obras,
las sueñan los santos locos,
las realizan los luchadores natos,
las aprovechan los felices cuerdo,
y las critican los inútiles crónicos,

acceso por ssh permite dos claves distintas...

2017-11-20 Por tema Walter O. Dari


Hola gente, es raro lo que me pasó.

Tengo un servidor (debian wheezy) al cual accedo normalmente desde mi 
equipo de escritorio mediante ssh sin necesidad de contraseña ya que 
valida por "key", mi equipo está dentro de authorized_keys en el servidor.


Hoy tuve que ingresar desde una notebook que no está registrada en ese 
servidor por lo que me pide contraseña. Inmediatamente después de 
ingresarla y apretar [Enter] me doy cuenta que había puesto una vieja, 
la sorpresa fue que ingresé al servidor sin problemas.


Me desconecté y volví a ingresar y nuevamente me aceptó la contraseña vieja.

Volví a desconectarme y probé ingresar nuevamente, esta vez con la 
contraseña actual y también me permitió el ingreso.


Ante esta situación, nuevamente me desconecté y probé con una contraseña 
inventada y me rechazó.


Es como que "recuerda" contraseñas anteriores. Seguramente es una falla 
del ssh, no ?


Saludos,

--

Walter O. Dari

http://swcomputacion.com/
http://swcomputacion.com/sistemas/
https://facebook.com/swcomputacion/
https://facebook.com/sistemasSW/

1 2 3 4 5 6 7 8 9 10 >

1 - 100 de 1918 matches

Mail list logo