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

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

Re: ssh no conecta (Bullseye en ambos equipos)

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...

Re: ssh no conecta (Bullseye en ambos equipos)

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

Re: ssh no conecta (Bullseye en ambos equipos)

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

Re: ssh no conecta (Bullseye en ambos equipos)

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

Re: ssh no conecta (Bullseye en ambos equipos)

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ó:

Re: ssh no conecta (Bullseye en ambos equipos)

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

Re: ssh no conecta (Bullseye en ambos equipos)

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

Re: ssh no conecta (Bullseye en ambos equipos)

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

Re: ssh no conecta (Bullseye en ambos equipos)

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

Re: ssh no conecta (Bullseye en ambos equipos)

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

Re: ssh no conecta (Bullseye en ambos equipos)

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

Re: ssh no conecta (Bullseye en ambos equipos)

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 > >

Re: ssh no conecta (Bullseye en ambos equipos)

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ó:

Re: ssh no conecta (Bullseye en ambos equipos)

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

Re: ssh no conecta (Bullseye en ambos equipos)

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

Re: ssh no conecta (Bullseye en ambos equipos)

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

Re: ssh no conecta (Bullseye en ambos equipos)

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 > > escribió: > > > > Hola gente: > > > > Me quiero conectar a un equipo de la

Re: ssh no conecta (Bullseye en ambos equipos)

Hola... El 15/5/21 a las 13:12, OddieX escribió: 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

Re: ssh no conecta (Bullseye en ambos equipos)

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

Re: ssh access with all ports close.

On 12/10/2020 6:40 AM, latin...@vcn.bc.ca wrote: latincom writes: I am not able to access my server at home using ssh, but i can see in logs, that someone can access my home server! What, exactly, are you seeing? Copy and paste examples. -- John Hasler jhas...@newsguy.com Elmwood, WI USA

Re: ssh tunnelling testing [solved]

On Mi, 09 dec 20, 10:58:48, Gary Dale wrote: > > My ISP has confirmed this seems to be a generic issue with that > modem/router. While I suspect that a firmware update could fix it, I can't > find any way to upgrade the firmware, which is another good reason for > having an inner and outer

Re: ssh access with all ports close.

> latincom writes: >> I am not able to access my server at home using ssh, but i can see in >> logs, that someone can access my home server! > > What, exactly, are you seeing? Copy and paste examples. > -- > John Hasler > jhas...@newsguy.com > Elmwood, WI USA > Dec 9 20:48:58 xxx sshd[4945]:

Re: ssh access with all ports close.

On 2020-12-09 16:33, latin...@vcn.bc.ca wrote: I had a Buster server at home, but the owner of the house close all ports in the router, i can not access it anymore; i rented a server without root access, and transfer the server. There are many vendors who can rent a Debian virtual private

Re: ssh access with all ports close.

latincom writes: > I am not able to access my server at home using ssh, but i can see in > logs, that someone can access my home server! What, exactly, are you seeing? Copy and paste examples. -- John Hasler jhas...@newsguy.com Elmwood, WI USA

Re: ssh tunnelling testing [solved]

On 2020-12-07 16:02, Gary Dale wrote: On 2020-12-07 14:23, john doe wrote: On 12/7/2020 8:11 PM, Gary Dale wrote: On 2020-12-07 14:03, john doe wrote: On 12/7/2020 7:54 PM, Gary Dale wrote: On 2020-12-07 13:24, john doe wrote: On 12/7/2020 6:38 PM, Gary Dale wrote: (actually through

Re: ssh tunnelling testing [solved]

On Lu, 07 dec 20, 14:11:01, Gary Dale wrote: > > The thing is the forwarding setup is the same for port 22 as it is for port > 80. I know that the port 80 forwarding is working so why isn't the port 22 > forwarding? > > I still don't know the answer to that one, but when I changed the external >

Re: ssh tunnelling testing

On 2020-12-07 13:55, der.hans wrote: Am 07. Dec, 2020 schwätzte Gary Dale so: moin moin, First off, try one or more -v to your ssh command to get more verbosity. The -v will show you the step in building the connection that failed. Also, try -G to see what configuration will be used without

Re: ssh tunnelling testing [solved]

On 2020-12-07 14:23, john doe wrote: On 12/7/2020 8:11 PM, Gary Dale wrote: On 2020-12-07 14:03, john doe wrote: On 12/7/2020 7:54 PM, Gary Dale wrote: On 2020-12-07 13:24, john doe wrote: On 12/7/2020 6:38 PM, Gary Dale wrote: (actually through the /etc/hosts file using the server's

Re: ssh tunnelling testing [solved]

On 2020-12-07 14:03, john doe wrote: On 12/7/2020 7:54 PM, Gary Dale wrote: On 2020-12-07 13:24, john doe wrote: On 12/7/2020 6:38 PM, Gary Dale wrote: (actually through the /etc/hosts file using the server's name). I've set up port forwarding on both my routers (I have an inner network

Re: ssh tunnelling testing

On 2020-12-07 13:24, john doe wrote: On 12/7/2020 6:38 PM, Gary Dale wrote: I'm running Debian/Buster on various servers, including my home server. I'm trying to set up an ssh tunnel that I can use post-pandemic in case I need to access my home network remotely. I'm already doing this to

Re: ssh tunnelling testing [solved]

On 12/7/2020 8:23 PM, john doe wrote: On 12/7/2020 8:11 PM, Gary Dale wrote: On 2020-12-07 14:03, john doe wrote: On 12/7/2020 7:54 PM, Gary Dale wrote: On 2020-12-07 13:24, john doe wrote: On 12/7/2020 6:38 PM, Gary Dale wrote: (actually through the /etc/hosts file using the server's

Re: ssh tunnelling testing [solved]

On Mon, 7 Dec 2020 20:23:28 +0100 john doe wrote: > On 12/7/2020 8:11 PM, Gary Dale wrote: > > On 2020-12-07 14:03, john doe wrote: > >> On 12/7/2020 7:54 PM, Gary Dale wrote: > >>> On 2020-12-07 13:24, john doe wrote: > On 12/7/2020 6:38 PM, Gary Dale wrote: > >>> > >

Re: ssh tunnelling testing [solved]

On 12/7/2020 8:11 PM, Gary Dale wrote: On 2020-12-07 14:03, john doe wrote: On 12/7/2020 7:54 PM, Gary Dale wrote: On 2020-12-07 13:24, john doe wrote: On 12/7/2020 6:38 PM, Gary Dale wrote: (actually through the /etc/hosts file using the server's name). I've set up port forwarding on

Re: ssh tunnelling testing

Am 07. Dec, 2020 schwätzte Gary Dale so: moin moin, First off, try one or more -v to your ssh command to get more verbosity. The -v will show you the step in building the connection that failed. Also, try -G to see what configuration will be used without actually opening a connection. I'm

Re: ssh tunnelling testing

On 12/7/2020 7:54 PM, Gary Dale wrote: On 2020-12-07 13:24, john doe wrote: On 12/7/2020 6:38 PM, Gary Dale wrote: (actually through the /etc/hosts file using the server's name). I've set up port forwarding on both my routers (I have an inner network and an outer one, using the outer

Re: ssh tunnelling testing

On 12/7/2020 6:38 PM, Gary Dale wrote: I'm running Debian/Buster on various servers, including my home server. I'm trying to set up an ssh tunnel that I can use post-pandemic in case I need to access my home network remotely. I'm already doing this to various remote servers so I thought this

Re: ssh session times out annoyingly fast, why?

On 9/29/20 06:53, Michael Stone wrote: > On Tue, Sep 29, 2020 at 08:44:18AM -0400, Gene Heskett wrote: >> This is likely quite true Michael, but it also is only a hint as to how >> to fix it for the OP. > > It was already fixed, serveraliveinterval/clientaliveinterval is the > right answer. I

Re: ssh session times out annoyingly fast, why?

On Tue, Sep 29, 2020 at 11:13:59AM -0400, Stefan Monnier wrote: In general it's kind of dumb on modern hardware to expire sessions that are still exchanging TCP keepalives unless you're under extreme pressure from a DoS attack or somesuch. Indeed, I'd be *very* surprised if a connection was

Re: ssh session times out annoyingly fast, why?

> In general it's kind of dumb on modern hardware to expire sessions > that are still exchanging TCP keepalives unless you're under extreme > pressure from a DoS attack or somesuch. Indeed, I'd be *very* surprised if a connection was dropped despite exchange of TCP keepalives. It seems much more

Re: ssh session times out annoyingly fast, why?

On Tue, Sep 29, 2020 at 10:44:13AM -0400, Michael Stone wrote: > On Tue, Sep 29, 2020 at 04:34:06PM +0200, to...@tuxteam.de wrote: > >Setting the socket option to keep alive "fixed" that. > > You were lucky. ssh does that by default, so if ssh sessions are > getting killed these days it's because

Re: ssh session times out annoyingly fast, why?

On Tue, Sep 29, 2020 at 04:34:06PM +0200, to...@tuxteam.de wrote: Setting the socket option to keep alive "fixed" that. You were lucky. ssh does that by default, so if ssh sessions are getting killed these days it's because the firewall ignores tcp keepalives when calculating timeouts. If

Re: ssh session times out annoyingly fast, why?

On Tue, Sep 29, 2020 at 04:22:32PM +0200, to...@tuxteam.de wrote: On Tue, Sep 29, 2020 at 08:18:54AM -0400, Michael Stone wrote: On Wed, Sep 23, 2020 at 03:48:56PM -0400, Greg Wooledge wrote: >The normal reason people need to use ServerAlive or ClientAlive is NAT. >If your connection from ssh

Re: ssh session times out annoyingly fast, why?

On Tue, Sep 29, 2020 at 04:22:32PM +0200, to...@tuxteam.de wrote: Following up on myself: I had exactly this case with an (outsourced) data centre: they had NATs between different realms (you might ask "why, oh, why?" and you'd be right). The application server and the database server were

Re: ssh session times out annoyingly fast, why?

On Tue, Sep 29, 2020 at 08:18:54AM -0400, Michael Stone wrote: > On Wed, Sep 23, 2020 at 03:48:56PM -0400, Greg Wooledge wrote: > >The normal reason people need to use ServerAlive or ClientAlive is NAT. > >If your connection from ssh client to ssh server goes through a NAT > >router, the router

Re: ssh session times out annoyingly fast, why?

On Tue, Sep 29, 2020 at 08:44:18AM -0400, Gene Heskett wrote: This is likely quite true Michael, but it also is only a hint as to how to fix it for the OP. It was already fixed, serveraliveinterval/clientaliveinterval is the right answer. I guess I can review: these options simply have the

Re: ssh session times out annoyingly fast, why?

On Tuesday 29 September 2020 08:18:54 Michael Stone wrote: > On Wed, Sep 23, 2020 at 03:48:56PM -0400, Greg Wooledge wrote: > >The normal reason people need to use ServerAlive or ClientAlive is > > NAT. If your connection from ssh client to ssh server goes through a > > NAT router, the router may

Re: ssh session times out annoyingly fast, why?

On Wed, Sep 23, 2020 at 03:48:56PM -0400, Greg Wooledge wrote: The normal reason people need to use ServerAlive or ClientAlive is NAT. If your connection from ssh client to ssh server goes through a NAT router, the router may keep track of activity on that connection, and drop the translation

Re: ssh session times out annoyingly fast, why?

On Sat, Sep 26, 2020 at 01:16:19PM -0800, Britton Kerin wrote: > Looks like NAT was the culprit, because top kept it alive. Internet has bogus > advice on this one because it suggests ServerAliveInterval 1200 or something > which I guess is larger than most firewall timeout. > > Thanks for all

Re: ssh session times out annoyingly fast, why?

On Wed, Sep 23, 2020 at 11:49 AM Greg Wooledge wrote: > > On Wed, Sep 23, 2020 at 10:30:15AM +0300, Anssi Saari wrote: > > Britton Kerin writes: > > > I'm using ssh from a debian box to a rasberry pi (sorta debian also :). > > > > > > For some reason ssh sessions seem to time out pretty quickly.

Re: ssh session times out annoyingly fast, why?

On Wed, Sep 23, 2020 at 10:30:15AM +0300, Anssi Saari wrote: > Britton Kerin writes: > > I'm using ssh from a debian box to a rasberry pi (sorta debian also :). > > > > For some reason ssh sessions seem to time out pretty quickly. How quickly, exactly? What is the actual message/behavior you

Re: ssh session times out annoyingly fast, why?

Britton Kerin writes: > I'm using ssh from a debian box to a rasberry pi (sorta debian also :). > > For some reason ssh sessions seem to time out pretty quickly. I've > tried setting ClientAliveInterval and ClientAliveCountMax and also > ServerAliveInterval and ServerAliveCountMax, but it

Re: ssh session times out annoyingly fast, why?

On 2020-09-21 19:38, Britton Kerin wrote: I'm using ssh from a debian box to a rasberry pi (sorta debian also :). For some reason ssh sessions seem to time out pretty quickly. I've tried setting ClientAliveInterval and ClientAliveCountMax and also ServerAliveInterval and ServerAliveCountMax,

(solved) Re: ssh fingerprint mismatch for one single client

> Yes. Given the data you've provided, I retract my first hunch: it seems > your student is seeing a different host: > > - either DNS resolves to a different IP address -- then you'd see >different IP addresses for your server as viewed from your student's >workstation wrt the "rest of

Re: ssh session times out annoyingly fast, why?

On 22/09/2020 00:38, Britton Kerin wrote: > I'm using ssh from a debian box to a rasberry pi (sorta debian also :). > > For some reason ssh sessions seem to time out pretty quickly. I've > tried setting ClientAliveInterval and ClientAliveCountMax and also > ServerAliveInterval and

Re: ssh session times out annoyingly fast, why?

First, you should be sure it is not a network issue. You could open a terminal and run, for example, top program. This avoid any timeout configured. If this does not work, you should follow for a network issue, otherwise we can see sshd's config file. Toni Mas Missatge de Britton Kerin del dia

Re: ssh session times out annoyingly fast, why?

have you tried "ssh -Y" option On 9/21/20 4:38 PM, Britton Kerin wrote: I'm using ssh from a debian box to a rasberry pi (sorta debian also :). For some reason ssh sessions seem to time out pretty quickly. I've tried setting ClientAliveInterval and ClientAliveCountMax and also

Re: ssh fingerprint mismatch for one single client

On Sun, Sep 20, 2020 at 01:59:41PM -0300, Beco wrote: > Thank you all so much for thid new batch of input Mick, LARAC, David, Tomas > and Reco > Bellow I'll try to answer in a brief way all at once: > > > > > On Sun, 20 Sep 2020 at 00:34, mick crane wrote: > > Is this Putty or something with

Re: ssh fingerprint mismatch for one single client

Le 20/09/2020 à 18:59, Beco a écrit : > I mean the numbers are completely different. > PUTTY: not only different, but it appears to get a ED25519 which is not > on the server. > SSH powershell: It gets ECDSA, which is the algorithm accepted, but a > completely different hex code. > > If I run on

Re: ssh fingerprint mismatch for one single client

On Sun, Sep 20, 2020 at 01:59:41PM -0300, Beco wrote: > I mean the numbers are completely different. > PUTTY: not only different, but it appears to get a ED25519 which is not on > the server. > SSH powershell: It gets ECDSA, which is the algorithm accepted, but a > completely different hex code.

Re: ssh fingerprint mismatch for one single client

On Sun, 20 Sep 2020 at 13:59, Beco wrote: > I also asked him to bring his notebook to a neighbor to try to connect > from there. We'll see his reply soon. > > > > Update: He went to his neighbor with his notebook in hand, tried there and he got the correct fingerprint and connected to the

Re: ssh fingerprint mismatch for one single client

Thank you all so much for thid new batch of input Mick, LARAC, David, Tomas and Reco Bellow I'll try to answer in a brief way all at once: On Sun, 20 Sep 2020 at 00:34, mick crane wrote: > Is this Putty or something with keys on student's PC ? No keys on PUTTY. Log in with password. > If

Re: ssh fingerprint mismatch for one single client

Hi. On Sun, Sep 20, 2020 at 10:40:35AM +0200, to...@tuxteam.de wrote: > On Sat, Sep 19, 2020 at 06:28:29PM -0300, Beco wrote: > > Dear linuxers, > > > > I've a server and one of my students is getting a wrong fingerprint when > > trying to connect via SSH. > > Lots of wild guessing and

Re: ssh fingerprint mismatch for one single client

On Sat, Sep 19, 2020 at 06:28:29PM -0300, Beco wrote: > Dear linuxers, > > I've a server and one of my students is getting a wrong fingerprint when > trying to connect via SSH. Lots of wild guessing and we still don't know the problem. There are different fingerprints involved, so we don't know

Re: ssh fingerprint mismatch for one single client

On 2020-09-19 15:42, Beco wrote: On Sat, 19 Sep 2020 at 18:55, mick crane wrote: Student can connect via the mobile network but not through the ISP router? Might that be the port for ssh on the router ? Yes, student can connect via mobile. And, somewhat "yes", student can kind of connect

Re: ssh fingerprint mismatch for one single client

On 2020-09-19 23:42, Beco wrote: On Sat, 19 Sep 2020 at 18:55, mick crane wrote: Just wild guess. Student can connect via the mobile network but not through the ISP router? Might that be the port for ssh on the router ? mick Hello Mick, Thanks for the interest. Yes, student can connect

Re: ssh fingerprint mismatch for one single client

On Sat, 19 Sep 2020 at 18:55, mick crane wrote: > > Just wild guess. > Student can connect via the mobile network but not through the ISP > router? > Might that be the port for ssh on the router ? > > mick > > -- > Key ID4BFEBB31 > > Hello Mick, Thanks for the interest. Yes, student can

Re: ssh fingerprint mismatch for one single client

On Sat, 19 Sep 2020 at 18:46, Lucas Castro wrote: > > Check if he's really reaching the right server. > > ping the server from his computer and check with tcpdump on server side. > > If not reaching the server, try traceroute to track where is going on. > > > Local address or Internet address

Re: ssh fingerprint mismatch for one single client

On 2020-09-19 22:28, Beco wrote: Dear linuxers, I've a server and one of my students is getting a wrong fingerprint when trying to connect via SSH. After a lot of debug, we are still unable to pinpoint why. The server didn't change IP or keys, and other students still log in ok with the

Re: ssh fingerprint mismatch for one single client

On 9/19/20 6:28 PM, Beco wrote: Dear linuxers, I've a server and one of my students is getting a wrong fingerprint when trying to connect via SSH. After a lot of debug, we are still unable to pinpoint why. The server didn't change IP or keys, and other students still log in ok with the

Re: ssh key used for login

Am Samstag, 8. August 2020, 02:26:20 CEST schrieb Kushal Kumaran: > Rainer Dorsch writes: > > Hi, > > > > can anybody tell if there is a way to find out the ssh key (out of the > > ones > > listed in authorized keys) was used for login to the current session? > > See the

Re: ssh key used for login

If what you use is a certificate based authentication, you can add user identity to the certificate with -I . Any auth attempt will make that identity logged automatically. Then you just have to get it from syslogs. Le sam. 8 août 2020 à 02:26, Kushal Kumaran a écrit : > Rainer Dorsch

Re: ssh key used for login

Rainer Dorsch writes: > Hi, > > can anybody tell if there is a way to find out the ssh key (out of the ones > listed in authorized keys) was used for login to the current session? > See the environment="NAME=value" part in the authorized_keys(5) manpage. You can have each entry in

Re: ssh key used for login

Am Freitag, 7. August 2020, 17:47:31 CEST schrieb john doe: > On 8/7/2020 5:07 PM, Rainer Dorsch wrote: > > Hi, > > > > can anybody tell if there is a way to find out the ssh key (out of the > > ones > > listed in authorized keys) was used for login to the current session? > > Try to increase

Re: ssh key used for login

On Fri, Aug 07, 2020 at 07:09:34PM +0200, Rainer Dorsch wrote: > Am Freitag, 7. August 2020, 17:47:31 CEST schrieb john doe: > > On 8/7/2020 5:07 PM, Rainer Dorsch wrote: > > > Hi, > > > > > > can anybody tell if there is a way to find out the ssh key (out of the > > > ones > > > listed in

Re: ssh key used for login

On 8/7/2020 5:07 PM, Rainer Dorsch wrote: Hi, can anybody tell if there is a way to find out the ssh key (out of the ones listed in authorized keys) was used for login to the current session? Try to increase the log verbosity to 'debug[1|2|3]'. -- John Doe

Re: SSH - channel xx: open failed: connect failed: Connection refused

Merci Erwann pour le retour. Le 01/08/2019 à 15:25, Erwann Le Bras a écrit : > > bonjour > > j'ai exactement le même problème depuis la montée en "Buster" de mon > serveur Debian. > avant, ça fonctionnait bien, avec une config identique. > > Je soupçonne une modif à faire dans la config de SSHD,

Re: SSH - channel xx: open failed: connect failed: Connection refused

bonjour j'ai exactement le même problème depuis la montée en "Buster" de mon serveur Debian. avant, ça fonctionnait bien, avec une config identique. Je soupçonne une modif à faire dans la config de SSHD, mais je n'ai pas encore cherché pourquoi. cordialement Le 24/07/2019 à 13:21, G2PC a

Re: SSH Tunneling

On Sat, Jun 29, 2019 at 04:45:33PM -0300, Caio Ferreira wrote: Lista Caio, Continuando os meus estudos para a LPIC 202-450, eu estou tendo problema com SSH Forwarding. Eu fiz o seguinte até agora # ESTACAO $ w3m http://192.168.0.8:80 It works ! # SERVIDOR (192.168.0.8) $ sudo vi

Re: SSH Tunneling

Prezado Helio Sim, eu reinicializei o serviço do ssh, sudo systemctl restart sshd.service. Como é somente para estudos para a a prova LPIC, tanto a estação quanto o servidor estão na mesma rede, consequentemente não existe o problema de firewall que possa interromper a comunicação. Desde já, eu

Re: SSH Tunneling

Prezado PM China Por enquanto eu estou fazendo somente teste para a prova LPIC 202-450, que alias um dos itens é implementar um servidor HTTPS. Eu poderia implementar para o banco de dados MySQL/MariaDB. Desde já, eu agradeço pela atenção. .''`. Caio Abreu Ferreira : :' :

Re: SSH Tunneling

Reiniciou o sshd no servidor? ./helio On Sat, Jun 29, 2019, 21:46 Caio Ferreira wrote: > Lista > > Continuando os meus estudos para a LPIC 202-450, eu estou tendo problema > com SSH Forwarding. > > Eu fiz o seguinte até agora > > # ESTACAO > $ w3m http://192.168.0.8:80 >It works ! > > #

Re: ssh local port forwarding stopped working

I would test port status with nmap -P0 -p 22 You want the response to be "open" Bruce On 5/28/19 12:17 PM, Gary Dale wrote: I'm running Debian/Testing on an AMD64 machine. I follow what I believe is a fairly conventional way of connecting to remote machines. Firstly I establish an SSH

Re: ssh local port forwarding stopped working

My first guess would be that port(s) 5900 and/or 5902 have been blocked. Next possibility is that for those credentials a remote user/pwd lookup is being done unexpectedly, the lookup needs to timeout because the credentials are invalid. Is the ID really present locally? On Tue, May 28, 2019,

Re: ssh policy change in new stretch??

Hi. On Thu, Mar 07, 2019 at 11:12:06PM +, Long Wind wrote: > i run command below and it work in early debian: > >  ssh zhou@192.168.1.3 > but new stretch says: > > ssh: connect to host 192.168.1.3 port 22: Connection refused > what should i do? Thanks! Start ssh server on

Re: ssh policy change in new stretch??

On 08/03/2019 12:12, Long Wind wrote: i run command below and it work in early debian:  ssh zhou@192.168.1.3 but new stretch says: ssh: connect to host 192.168.1.3 port 22: Connection refused what should i do? Thanks! Has the server also been upgraded to stretch? Is sshd running on the

Re: ssh policy change in new stretch??

Long Wind wrote: > i run command below and it work in early debian: > > ssh zhou@192.168.1.3 > but new stretch says: > > ssh: connect to host 192.168.1.3 port 22: Connection refused > what should i do? Thanks! Run ssh -v zhou@192.168.1.3 or ssh -vv zhou@192.168.1.3 or ssh -vvv

Re: ssh trouble

Greg Wooledge wrote: > On Tue, Dec 18, 2018 at 10:00:12PM +, Glenn English wrote: >> Hmmm. When I search the web to find out what KexAlgorithms means, I >> find I've been there before (the 76 year old memory is less than >> optimal). Looking more promising. Thanks, Marc. > > Key Exchange

Re: ssh trouble [Solved]

Adding the diffie-hellman line to the config worked, but then the router complained that there wasn't a matching cipher. I suspected that if I fixed that, the router'd complain about something else, so I gave up and fixed things by copying the working /etc/ssh config dir from the laptop to the

Re: ssh trouble

On Tue, Dec 18, 2018 at 10:00:12PM +, Glenn English wrote: > Hmmm. When I search the web to find out what KexAlgorithms means, I > find I've been there before (the 76 year old memory is less than > optimal). Looking more promising. Thanks, Marc. Key Exchange Algorithms. Should be documented

Re: ssh trouble

On Tue, Dec 18, 2018 at 9:18 PM Marc Auslander wrote: > Newer versions of ssh deprecate diffie-hellman-group1-sha1 > Putting KexAlgorithms +diffie-hellman-group1-sha1 in config for the host > works for me. There is also a way to do it on the ssh command line. I'll look into this, but one

Re: ssh trouble

Glenn English wrote: 4 boxes on the same network; an RPi3 running Raspian Stretch, a laptop and a desktop running Buster, and a Cisco router running IOS 12.4 (note upper case 'I' :-). I have an expect script to get into the router. It's the same on all the hosts. The problem is that the RPi

Re: SSH & X11 forwarding

Am 23. Nov, 2018 schwätzte Martin so: moin moin, please don't 'xhost +', that should not be needed. The application being tunneled comes from localhost, so you shouldn't need any xhost adjustment. ciao, der.hans Hi list members, I have not used X11 over ssh for years now. But today is the

Re: SSH & X11 forwarding

Hi. On Fri, Nov 23, 2018 at 02:48:09PM +0100, Martin wrote: > Hi list members, > > I have not used X11 over ssh for years now. But today is the day! And it does > not work > The remote console tells me 'Xt error: Can't open display: :0'. What does it exactly say while logging you

Re: SSH & X11 forwarding

Le 23-11-2018, à 14:48:09 +0100, Martin a écrit : Hi list members, I have not used X11 over ssh for years now. But today is the day! And it does not work The remote console tells me 'Xt error: Can't open display: :0'. X11Forwarding is enabled on client and server, 'xhost +' on the client,

Re: SSH & X11 forwarding

Am Freitag, 23. November 2018, 14:48:09 CET schrieb Martin: Hi Martin, did you try ssh -X -l yourusername 192.168.what_ip.whatever? This should work by default. Any graphical application should then show on your client (as fas as you have linux on it at all). Running this from Windows, you

Re: ssh

On Mon, Nov 19, 2018 at 12:12:50PM -0500, Michael Stone wrote: On Mon, Nov 19, 2018 at 09:43:29AM -0500, Jim Popovitch wrote: On Mon, 2018-11-19 at 08:38 -0500, Michael Stone wrote: On Mon, Nov 19, 2018 at 08:32:09AM -0500, Greg Wooledge wrote: If you're only going to login to the account

Re: ssh

On Mon, 2018-11-19 at 12:12 -0500, Michael Stone wrote: > On Mon, Nov 19, 2018 at 09:43:29AM -0500, Jim Popovitch wrote: > > On Mon, 2018-11-19 at 08:38 -0500, Michael Stone wrote: > > > On Mon, Nov 19, 2018 at 08:32:09AM -0500, Greg Wooledge wrote: > > > > If you're only going to login to the

Re: ssh

On Mon, Nov 19, 2018 at 09:43:29AM -0500, Jim Popovitch wrote: On Mon, 2018-11-19 at 08:38 -0500, Michael Stone wrote: On Mon, Nov 19, 2018 at 08:32:09AM -0500, Greg Wooledge wrote: > If you're only going to login to the account using ssh keys, you > don't need to give it a valid password hash

Re: ssh

On Mon, 2018-11-19 at 08:38 -0500, Michael Stone wrote: > On Mon, Nov 19, 2018 at 08:32:09AM -0500, Greg Wooledge wrote: > > If you're only going to login to the account using ssh keys, you > > don't need to give it a valid password hash at all.  Just put a > > string of rubbish (English words

<    1   2   3   4   5   6   7   8   9   10   >