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: Bookworm, fail2ban and sshd

[Charles Curley]

On Fri, 15 Mar 2024 14:59:49 - (UTC)
Curt  wrote:

> I guess it's this old bug:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=770171

Yup, thank you. I added the following stanza to
/etc/fail2ban/jail.d/curley.conf:

[sshd]
backend = systemd

(The "enabled" pair is already given in defaults-debian.conf.)

And running "fail2ban-client -d | grep -i ssh" confirms both that the
server is running, and that the ssh jail is enabled.

Which lead to another problem: I got a warning:

519846]: WARNING 'allowipv6' not defined in 'Definition'. Using default
one: 'auto'

Which would have been fine, except a) I don't like warnings, and 2) I
do not use or want ipv6. So I changed that to a no in fail2ban.local.
And I had to move that stanza to under the [Definition] heading to
quiet the warning.

-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

Re: Bookworm, fail2ban and sshd

[Michael Meckler]

I have fail2ban working for sshd on Bookworm. My jail.local file looks like 
this:

[sshd]

bantime = 2d
enabled  = true
mode = extra
port = 
filter   = sshd[mode=aggressive]
backend  = systemd
journalmatch = _SYSTEMD_UNIT=ssh.service + _COMM=sshd
maxretry = 1
findtime = 300

Re: Bookworm, fail2ban and sshd

[Curt]

On 2024-03-14, Charles Curley  wrote:
> I'm trying to set fail2ban up on bookworm. It refuses to run with the
> default configuration (sshd only), reporting:

I guess it's this old bug:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=770171

> Failed during configuration: Have not found any log file for sshd jail
>
> Near as I can figure, fail2ban expects sshd's log file to be
> /var/log/auth.log. Which does not exist on my target machine.
>
> On a brief inspection, machines that have new installations of bookworm
> do not have /var/log/auth.log. Machines running bullseye or upgraded
> from bullseye to bookworm have it.
>
> Commenting out sshd's "enabled" line (in
> /etc/fail2ban/jail.d/defaults-debian.conf) allows the daemon to start,
> but it isn't doing anything useful.
>


-- 

Re: Bookworm, fail2ban and sshd

[Charles Curley]

On Thu, 14 Mar 2024 22:27:36 +
Andy Smith  wrote:

> I think you want to set "backend = journald" in
> /etc/fail2ban/jail.conf or its usual local override, but I have not
> tested this as I still use rsyslogd.

Thanks, but no cigar. I also tried setting backend to systemd (as noted
in man jail.conf). Also no go.

The man page also suggest specifying the path to the journal. I tried

[DEFAULT]
backend =
systemd[journalpath=/var/log/journal/2284a3a8f11544c5a5c355d3ff3e744d/]

That worked if I disabled sshd, but sshd still doesn't like it.

-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

Re: Bookworm, fail2ban and sshd

[Andy Smith]

Hi,

On Thu, Mar 14, 2024 at 04:01:54PM -0600, Charles Curley wrote:
> I'm trying to set fail2ban up on bookworm. It refuses to run with the
> default configuration (sshd only), reporting:
> 
> Failed during configuration: Have not found any log file for sshd jail

I think you want to set "backend = journald" in
/etc/fail2ban/jail.conf or its usual local override, but I have not
tested this as I still use rsyslogd.

Thanks,
Andy

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

Bookworm, fail2ban and sshd

[Charles Curley]

I'm trying to set fail2ban up on bookworm. It refuses to run with the
default configuration (sshd only), reporting:

Failed during configuration: Have not found any log file for sshd jail

Near as I can figure, fail2ban expects sshd's log file to be
/var/log/auth.log. Which does not exist on my target machine.

On a brief inspection, machines that have new installations of bookworm
do not have /var/log/auth.log. Machines running bullseye or upgraded
from bullseye to bookworm have it.

Commenting out sshd's "enabled" line (in
/etc/fail2ban/jail.d/defaults-debian.conf) allows the daemon to start,
but it isn't doing anything useful.

-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

Re: sshd Match regel

[Richard Lucassen]

On Wed, 21 Feb 2024 16:21:35 +0100
Roland Clobus  wrote:

> On 21/02/2024 16:08, Paul van der Vlis wrote:
> > Wie heeft een tip
> 
> Ik heb nog een (zeer) oude Linksys WRT staan, die kan ik benaderen
> met:
> 
> ssh -oKexAlgorithms=+diffie-hellman-group1-sha1 
> -oHostKeyAlgorithms=+ssh-rsa username@mylocalip
> 
> Ik heb met ssh -v username@mylocalip de waarde voor -oKexAlgorithms 
> gevonden.

Even ter info: onder Debian heb je een package dat openssh-client-ssh1
heet. Enige nadeel is dat-ie de /etc/ssh/ssh_config uitleest en niet
bijvoorbeeld een /etc/ssh/ssh1_config. Even scripten dus met een eigen
config file. Er is ook een scp1 in dat package.

-- 
richard lucassen
http://contact.xaq.nl/

Opgelost (maar heel anders) Re: sshd Match regel

[Gijs Hillenius]

hallo

Het ging om een versie van Curl .. dan sftp://file-server wilde doen met
alleen rsa/dsa. De SSH op dezelfde host ondersteunen ecdsa en zo gewoon.

Allebei MotioneyeOS, voor het laatst opgewaardeed in 2020. Ik zag geen
manier om Curl te vertellen ecdsa te doen. 

Dus ... Ik heb het transport omgedraaid.. ik haal nu de files op vanaf
de file server, dat kan met een cron job.

Re: sshd Match regel

[Roland Clobus]

Hallo Paul,

On 21/02/2024 16:08, Paul van der Vlis wrote:

Wie heeft een tip


Ik heb nog een (zeer) oude Linksys WRT staan, die kan ik benaderen met:

ssh -oKexAlgorithms=+diffie-hellman-group1-sha1 
-oHostKeyAlgorithms=+ssh-rsa username@mylocalip


Ik heb met ssh -v username@mylocalip de waarde voor -oKexAlgorithms 
gevonden.


Met vriendelijke groeten,
Roland Clobus


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: sshd Match regel

[Paul van der Vlis]

Hoi Gijs en anderen,

Op 20-02-2024 om 21:18 schreef Geert Stappers:

On Tue, Feb 20, 2024 at 08:06:22AM +0100, Gijs Hillenius wrote:

On 19 February 2024 18:26 Rik Theys, wrote:


Beste,

On Mon, Feb 19, 2024 at 5:53 PM Gijs Hillenius  wrote:




Iets als, onderaan sshd_config dit:

,
| Match User webcams
| PubkeyAcceptedKeyTypes ssh-rsa,ssh-dss
`

ssh lijkt dat te willen snappen. Desondanks verschijnt dezelfde
foutmelding in auth.log. De clients bevestigen: "unable to exchange
encryption keys."

Als ik op de server doe:

ssh localhost -Q HostKeyAlgorithms


daar zie ik toch ssh-dss en ssh-rsa staan.

Maar ... niet de "oude"?

Wie heeft een tip





De -Q optie geeft een lijst van ondersteunde algorithms, daarom niet
degene die actief zijn? Ik zou eens proberen met een Match op het IP
adres ipv de gebruikersnaam. Mogelijk is de uitwisseling van de
gebruikersnaam pas na het tot stand komen van de encryptie?


Ow! dank voor het meedenken, dat helpt.

Idd, ik zie in de ssh logs niet die username.

Maar

,
| Match Address 192.168.123.42
|   PubkeyAcceptedKeyTypes ssh-rsa,ssh-dss
`

geeft helaas dezelfde melding in de log.




    sudo /usr/sbin/sshd -d


Dat is inderdaad een heel goede tip om ssh problemen te debuggen. Maar 
je moet het op de server draaien, en wellicht op een andere poort omdat 
je jezelf anders buitensluit. En die poort moet uiteraard wel openstaan.


Soms kun je wel even de poort van een andere applicatie gebruiken als je 
die applicatie sluit, bijvoorbeeld poort 80 als je een aanwezige 
webserver sluit.


Groet,
Paul

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

Re: sshd Match regel

[Geert Stappers]

On Tue, Feb 20, 2024 at 08:06:22AM +0100, Gijs Hillenius wrote:
> On 19 February 2024 18:26 Rik Theys, wrote:
> 
> > Beste,
> >
> > On Mon, Feb 19, 2024 at 5:53 PM Gijs Hillenius  wrote:
> >
> >>
> >>
> >> Iets als, onderaan sshd_config dit:
> >>
> >> ,
> >> | Match User webcams
> >> | PubkeyAcceptedKeyTypes ssh-rsa,ssh-dss
> >> `
> >>
> >> ssh lijkt dat te willen snappen. Desondanks verschijnt dezelfde
> >> foutmelding in auth.log. De clients bevestigen: "unable to exchange
> >> encryption keys."
> >>
> >> Als ik op de server doe:
> >>
> >> ssh localhost -Q HostKeyAlgorithms
> >>
> >>
> >> daar zie ik toch ssh-dss en ssh-rsa staan.
> >>
> >> Maar ... niet de "oude"?
> >>
> >> Wie heeft een tip
> >>
> >>
> 
> > De -Q optie geeft een lijst van ondersteunde algorithms, daarom niet
> > degene die actief zijn? Ik zou eens proberen met een Match op het IP
> > adres ipv de gebruikersnaam. Mogelijk is de uitwisseling van de
> > gebruikersnaam pas na het tot stand komen van de encryptie?
> 
> Ow! dank voor het meedenken, dat helpt.
> 
> Idd, ik zie in de ssh logs niet die username.
> 
> Maar
> 
> ,
> | Match Address 192.168.123.42
> |   PubkeyAcceptedKeyTypes ssh-rsa,ssh-dss
> `
> 
> geeft helaas dezelfde melding in de log.
> 


   sudo /usr/sbin/sshd -d



Voor een beter bericht heb ik nu geen tijd.




Groeten
Geert Stappers
-- 
Silence is hard to parse

Re: sshd Match regel

[Gijs Hillenius]

On 19 February 2024 18:26 Rik Theys, wrote:

> Beste,
>
> On Mon, Feb 19, 2024 at 5:53 PM Gijs Hillenius  wrote:
>
>>
>>
>> Iets als, onderaan sshd_config dit:
>>
>> ,
>> | Match User webcams
>> | PubkeyAcceptedKeyTypes ssh-rsa,ssh-dss
>> `
>>
>> ssh lijkt dat te willen snappen. Desondanks verschijnt dezelfde
>> foutmelding in auth.log. De clients bevestigen: "unable to exchange
>> encryption keys."
>>
>> Als ik op de server doe:
>>
>> ssh localhost -Q HostKeyAlgorithms
>>
>>
>> daar zie ik toch ssh-dss en ssh-rsa staan.
>>
>> Maar ... niet de "oude"?
>>
>> Wie heeft een tip
>>
>>

> De -Q optie geeft een lijst van ondersteunde algorithms, daarom niet
> degene die actief zijn? Ik zou eens proberen met een Match op het IP
> adres ipv de gebruikersnaam. Mogelijk is de uitwisseling van de
> gebruikersnaam pas na het tot stand komen van de encryptie?

Ow! dank voor het meedenken, dat helpt.

Idd, ik zie in de ssh logs niet die username.

Maar

,
| Match Address 192.168.123.42
|   PubkeyAcceptedKeyTypes ssh-rsa,ssh-dss
`

geeft helaas dezelfde melding in de log.

Re: sshd Match regel

[Rik Theys]

Beste,

On Mon, Feb 19, 2024 at 5:53 PM Gijs Hillenius  wrote:

>
>
> Iets als, onderaan sshd_config dit:
>
> ,
> | Match User webcams
> | PubkeyAcceptedKeyTypes ssh-rsa,ssh-dss
> `
>
> ssh lijkt dat te willen snappen. Desondanks verschijnt dezelfde
> foutmelding in auth.log. De clients bevestigen: "unable to exchange
> encryption keys."
>
> Als ik op de server doe:
>
> ssh localhost -Q HostKeyAlgorithms
>
>
> daar zie ik toch ssh-dss en ssh-rsa staan.
>
> Maar ... niet de "oude"?
>
> Wie heeft een tip
>
>
> De -Q optie geeft een lijst van ondersteunde algorithms, daarom niet
degene die actief zijn?
Ik zou eens proberen met een Match op het IP adres ipv de gebruikersnaam.
Mogelijk is de uitwisseling van de gebruikersnaam pas na het tot stand
komen van de encryptie?

Mvg,
Rik

sshd Match regel

[Gijs Hillenius]

Hoi

Ik heb sinds een inbraak in 2019 enige simpele (zelfgebouwde) embedded
webcameraatjes draaien. Put, koe, inderdaad. Maar dat terzijde.

Nou blijken die cameraatjes sinds enige tijd alweer hun filmpjes niet te
kopieren naar de file server op zolder.

Op die server Debian stable, draait openssh 1:9.2p1-2+deb12u2, en de
logs laten zien:

no matching host key type found. Their offer: ssh-rsa,ssh-dss [preauth]

ssh dus te oud, op die webcammetjes. Updaten van die cammetjes dat
blijkt een heel gedoe.. en... nou leek het me voor de korte termijn een
oplossing om op de ssh server voor de webcammetjes een uitzondering te
maken.

Iets als, onderaan sshd_config dit:

,
| Match User webcams
| PubkeyAcceptedKeyTypes ssh-rsa,ssh-dss
`

ssh lijkt dat te willen snappen. Desondanks verschijnt dezelfde
foutmelding in auth.log. De clients bevestigen: "unable to exchange
encryption keys."

Als ik op de server doe:

ssh localhost -Q HostKeyAlgorithms
ssh-ed25519
ssh-ed25519-cert-...@openssh.com
sk-ssh-ed25...@openssh.com
sk-ssh-ed25519-cert-...@openssh.com
ecdsa-sha2-nistp256
ecdsa-sha2-nistp256-cert-...@openssh.com
ecdsa-sha2-nistp384
ecdsa-sha2-nistp384-cert-...@openssh.com
ecdsa-sha2-nistp521
ecdsa-sha2-nistp521-cert-...@openssh.com
sk-ecdsa-sha2-nistp...@openssh.com
sk-ecdsa-sha2-nistp256-cert-...@openssh.com
webauthn-sk-ecdsa-sha2-nistp...@openssh.com
ssh-dss
ssh-dss-cert-...@openssh.com
ssh-rsa
ssh-rsa-cert-...@openssh.com
rsa-sha2-256
rsa-sha2-256-cert-...@openssh.com
rsa-sha2-512
rsa-sha2-512-cert-...@openssh.com

ssh localhost -Q sig
ssh-ed25519
sk-ssh-ed25...@openssh.com
ecdsa-sha2-nistp256
ecdsa-sha2-nistp384
ecdsa-sha2-nistp521
sk-ecdsa-sha2-nistp...@openssh.com
webauthn-sk-ecdsa-sha2-nistp...@openssh.com
ssh-dss
ssh-rsa
rsa-sha2-256
rsa-sha2-512


daar zie ik toch ssh-dss en ssh-rsa staan.

Maar ... niet de "oude"?

Wie heeft een tip


Dank

G

Re: latest upgrade to systemd 252.12-1 error about invalid attributes /var/log/journal and slow sshd connections

[Jeffrey Walton]

On Sat, Jul 15, 2023 at 1:09 PM David Mehler  wrote:
>
>  [...]
>
> "2.  "I noticed that when I change UsePAM yes to UsePAM no then this
> issue is resolved."
>
> BINGO! I flipped that UsePAM setting to no and the problem has gone away.

If you need a datapoint about UsePAM... I've been setting it to 'no'
for years on the BSDs, Debian, Fedora, Hurd, Red Hat and Ubuntu. But I
also disable all password authentication, and require public key
authentication.

$ cat /etc/ssh/sshd_config.d/10-pubkey_auth.conf
# Disable passwords
PasswordAuthentication no
ChallengeResponseAuthentication no
KerberosAuthentication no
KerberosOrLocalPasswd no
GSSAPIAuthentication no
UsePAM no

# Enable public key
PubkeyAuthentication yes

Jeff

Re: latest upgrade to systemd 252.12-1 error about invalid attributes /var/log/journal and slow sshd connections

[Gareth Evans]

On Sat 15 Jul 2023, at 17:52, David Mehler  wrote:
[...]
> Regarding the original issue of the systemd upgrade and the invalid
> attributes [...] here is the output that I've got:
>
[...]
> Cannot set file attributes for '/var/log/journal', maybe due to
> incompatibility in specified attributes, previous=0x0008,
> current=0x0008, expected=0x0088, ignoring.
> Cannot set file attributes for
> '/var/log/journal/390b00d843d3401094a8fd44f1b7de82', maybe due to
> incompatibility in specified attributes, previous=0x0008,
> current=0x0008, expected=0x0088, ignoring.
> Obsolete conffile /etc/systemd/resolved.conf has been modified by you.
> Saving as /etc/systemd/resolved.conf.dpkg-bak ...

User "seth" at

https://bbs.archlinux.org/viewtopic.php?id=272893

suggests "The error itself is harmless; systemd tries to set an attribute on a 
filesystem that doesn't support it" which seems to go along with it being 
ignored.  

and later:

"0x0080 is FS_NOCOW_FL - what is not a thing on directories.
Edit except for apparently btrfs - what also seems the only supported FS here. 
Otherwise you get an error [...]"

User j1simon suggests in

https://bbs.archlinux.org/viewtopic.php?pid=2013787#p2013787

that the errors are present at boot.

(I presume journalctl -b is how that output was obtained) 

I use ZFS and can't find any similar errors in boot log 

$ sudo journalctl -b|grep incompat
$

so I wonder if ZFS supports it on directories too.  

man ioctl_iflags:

"FS_NOCOW_FL 'C' (since Linux 2.6.39)
  The *file* will not be subject to copy-on-write updates.
  This flag has an effect only on filesystems that support
  copy-on-write semantics, such as Btrfs.  See chattr(1) and
  btrfs(5)."

https://man7.org/linux/man-pages/man2/ioctl_iflags.2.html

The reporter in the first link above is asked if the bug has been reported to 
systemd developers.  In another bug report re the same error (if in a slightly 
different context) on F2FS, systemd developer Lennart Poettering says "[...] 
this is a bug in the filesystem - They should not just eat up requests to set 
flags, but return an error. Please ping the f2fs maintainers."

https://github.com/systemd/systemd/issues/26318

It looks like the same bug/issue on ext4 to me, and I imagine safe to ignore.

Best wishes,
Gareth

Re: latest upgrade to systemd 252.12-1 error about invalid attributes /var/log/journal and slow sshd connections

[David Mehler]

Hello,

Thanks. The ssh issue has been solved.


"The same symptoms appear in an answer to

https://superuser.com/questions/166359/why-is-my-ssh-login-slow

which includes various solutions, some more permanent/apparently
likely to help you than others.

Just out of interest, is the su command (on the ssh server machine)
also affected by authentication delays?  This apparently suggests a
PAM issue."

In answer yes su on the ssh machine also has these delays. It is
looking like a pam issue.


"1.  "I found that PAM was reading the file /var/log/btmp, which had
become huge as a result of people trying to brute-force my server.
This was leading to login times of a minute. Clearing this file solved
the problem."

I did check for /var/log/btmp and it is a nice lovely 25MB in size. I
did clear it, restarted sshd and this did not clear up the problem,
still had the delays.

"2.  "I noticed that when I change UsePAM yes to UsePAM no then this
issue is resolved."

BINGO! I flipped that UsePAM setting to no and the problem has gone away.

Regarding the original issue of the systemd upgrade and the invalid
attributes (this sshd was a nice side venture but wasn't sure if it
was connected or not) here is the output that I've got:

Setting up systemd (252.11-1~deb12u1) ...
Installing new version of config file /etc/systemd/journald.conf ...
Installing new version of config file /etc/systemd/logind.conf ...
Installing new version of config file /etc/systemd/networkd.conf ...
Installing new version of config file /etc/systemd/pstore.conf ...
Installing new version of config file /etc/systemd/sleep.conf ...
Installing new version of config file /etc/systemd/system.conf ...
Installing new version of config file /etc/systemd/user.conf ...
Cannot set file attributes for '/var/log/journal', maybe due to
incompatibility in specified attributes, previous=0x0008,
current=0x0008, expected=0x0088, ignoring.
Cannot set file attributes for
'/var/log/journal/390b00d843d3401094a8fd44f1b7de82', maybe due to
incompatibility in specified attributes, previous=0x0008,
current=0x0008, expected=0x0088, ignoring.
Obsolete conffile /etc/systemd/resolved.conf has been modified by you.
Saving as /etc/systemd/resolved.conf.dpkg-bak ...

Thanks.
Dave.


On 7/15/23, Gareth Evans  wrote:
> On Sat 15 Jul 2023, at 13:09, Gareth Evans  wrote:
>>
>> 2.  "I noticed that when I change UsePAM yes to UsePAM no then this
>> issue is resolved."
>>
>> There may be security (or other) issues with (2).
>
> See, for example:
>
> https://unix.stackexchange.com/questions/673153/sshd-what-are-the-practical-effects-of-setting-usepam-no
>
>

Re: latest upgrade to systemd 252.12-1 error about invalid attributes /var/log/journal and slow sshd connections

[Gareth Evans]

On Sat 15 Jul 2023, at 13:09, Gareth Evans  wrote:
>
> 2.  "I noticed that when I change UsePAM yes to UsePAM no then this 
> issue is resolved."
>
> There may be security (or other) issues with (2).  

See, for example:

https://unix.stackexchange.com/questions/673153/sshd-what-are-the-practical-effects-of-setting-usepam-no

Re: latest upgrade to systemd 252.12-1 error about invalid attributes /var/log/journal and slow sshd connections

[Gareth Evans]

On Wed 12 Jul 2023, at 18:29, Gareth Evans  wrote:

>> On 12 Jul 2023, at 15:12, David Mehler  wrote:
>> [sshd login takes a long time]

> [...] 
> Does
> 
> ssh -vvv ...
> 
> (at client) shed any light?

Replying to an off-list message from David in which he stated ssh -vvv waits 
after

> debug1: Entering interactive session.
> debug1: pledge: network

The same symptoms appear in an answer to

https://superuser.com/questions/166359/why-is-my-ssh-login-slow

which includes various solutions, some more permanent/apparently likely to help 
you than others.

Just out of interest, is the su command (on the ssh server machine) also 
affected by authentication delays?  This apparently suggests a PAM issue.

If you start a new ssh server on a different port and enable debugging:

$ sudo /usr/sbin/sshd -ddd -p1234

then at what point does it hang when you ssh from the other machine?  Don't 
forget to specify target port (with -p1234)

If PAM-related, then answers at the above link suggest:

1.  "I found that PAM was reading the file /var/log/btmp, which had become huge 
as a result of people trying to brute-force my server. This was leading to 
login times of a minute. Clearing this file solved the problem."

2.  "I noticed that when I change UsePAM yes to UsePAM no then this issue is 
resolved."

There may be security (or other) issues with (2).  To avoid the risk of locking 
yourself out of VPS I would

Copy /etc/ssh/sshd_config elsewhere 
Amend the copy to include UsePAM no

$ sudo /var/sbin/sshd -f /path/to/sshd_config_copy -ddd -p1235 

(NB use new port number if previous command still running)

then see if you can ssh to it.

If the issue is not solved by either of the above, please give any sshd debug 
output that seems relevant for a few lines before/after the wait.

To view the systemd journal, see 

man journalctl

You may however like to install rsyslog to get /var/log/syslog back.  Not sure 
if it's retro-active though.

HTH
Gareth

Re: latest upgrade to systemd 252.12-1 error about invalid attributes /var/log/journal and slow sshd connections

[Gareth Evans]

> On 12 Jul 2023, at 15:12, David Mehler  wrote:
> 
> Hello,
> 
> I'm running Debian 12 on a vps. I just upgraded it and am now
> apparently running the latest systemd version 252.12-1. I saw an error
> about invalid attributes on /var/log/journal then it said ignoring.
> I've seen others with this error but only in reference as far as I can
> tell to the btrfs filesystem which I'm not using. I've got a single
> drive running ext4. I'm also seeing very slow like over a minute
> connection times between when I authenticate via sshd and I get a
> terminal prompt which is also since this upgrade. The initial server
> connection goes as normal, it gets my public key then a good long
> delay and then I finally get my terminal prompt.
> 
> Any comments on either of these appreciated.

Hi Dave,

Can you specify the journal error messages?

This suggests ssh login delay may be a DNS issue

https://superuser.com/questions/166359/why-is-my-ssh-login-slow

Does

ssh -vvv ...

(at client) shed any light?

Thanks,
Gareth

> Thanks.
> Dave.
> 

latest upgrade to systemd 252.12-1 error about invalid attributes /var/log/journal and slow sshd connections

[David Mehler]

Hello,

I'm running Debian 12 on a vps. I just upgraded it and am now
apparently running the latest systemd version 252.12-1. I saw an error
about invalid attributes on /var/log/journal then it said ignoring.
I've seen others with this error but only in reference as far as I can
tell to the btrfs filesystem which I'm not using. I've got a single
drive running ext4. I'm also seeing very slow like over a minute
connection times between when I authenticate via sshd and I get a
terminal prompt which is also since this upgrade. The initial server
connection goes as normal, it gets my public key then a good long
delay and then I finally get my terminal prompt.

Any comments on either of these appreciated.
Thanks.
Dave.

Re: sshd package systemd misconfiguration?

[Michael]

On Friday, 16 September 2022 13:25:06 CEST, Greg Wooledge wrote:

I did find this paragraph in systemd.exec(5):


me, too. if i run into a problem, the first thing i do is to read. and, 
yes: i do read even man pages! ;)




Maybe you can find a workaround there, and/or contribute your workaround
when you file your bug report.


i did, see my initial post. and since the issue is known, as it seems to be 
fixed in bookworm, i don't see any reason to file a bug.




Personally, I've never configured sshd to use socket activation, nor do I
see any advantage in doing so.


me neither, hence my irritation. and i now deactivated socket activation 
and went back to the good old daemon. yes, we all have our daemons! ;)


i just had a problem with ssh(d), and i wanted to know what caused it. now 
that i know, i can sleep a lot better. :)




Back in the old days, [...]


yeah, i miss them, too... sometimes...

greetings...

Re: sshd package systemd misconfiguration?

[Michael]

On Friday, 16 September 2022 14:10:01 CEST, Frank wrote:

Apparently this has already been 'fixed' for bookworm. [...]


so, this issue is known and 'they' did something about it.



Maybe file a bug report to have this added for bullseye?


since this issue is known, 'they' should be aware of it, too...

greetings...

Re: sshd package systemd misconfiguration?

[David Wright]

On Fri 16 Sep 2022 at 09:17:10 (+0200), Michael wrote:
> On Thursday, 15 September 2022 13:01:45 CEST, Greg Wooledge wrote:
> 
> of course the first thing i did was to check if all the files from the
> package were as they should be, and everything was fine!
> 
> > It's supposed to be created as needed.  There should be two lines in
> > the unit file:
> > 
> > unicorn:/lib/systemd/system$ grep RuntimeDirectory ssh@.service
> > RuntimeDirectory=sshd
> > RuntimeDirectoryMode=0755
> > unicorn:/lib/systemd/system$ grep RuntimeDirectory ssh.service
> > RuntimeDirectory=sshd
> > RuntimeDirectoryMode=0755
> 
> i never questioned that! my problem wasn't based on these lines are
> missing or in some way altered. my problem resulted in these lines
> being there as they are! ;)
> 
> > That should cause the /run/sshd directory to be created when the service
> > is started, and removed when it's stopped.
> 
> you got it! :)
> 
> having 'RuntimeDirectory=sshd' in ssh.service is totally fine! that
> is, b/c sshd runs as a daemon, and each new connection is handled by
> that exact daemon. so the /run/sshd directory stays there no matter
> how many connections to the host exist or being terminated, etc.
> 
> with ssh@.service it is completely different. for each connection
> there is a dedicated sshd process being started, and each one of them
> has the same /run/sshd directory assigned. and that's the problem if
> you have more than one connection to a given host. as soon as the
> first connection is terminated, the /run/sshd directory disappears,
> and the other sshd's might run into problems.

The rationale for having ssh@.service appears to be laid out in
https://bugzilla.redhat.com/show_bug.cgi?id=963268
and
http://0pointer.de/blog/projects/inetd.html
(not that I appreciate some of the points being made there).

> but i still don't understand, why this scenario prevents me from
> contacting a host with the formerly mentioned error message in the log
> file...

> > On Thu 15 Sep 2022 at 12:02:21 (+0200), Michael wrote:
> > > so i started digging, and to my surprise i found out that on the
> > > affected servers sshd was configured to be invoked by ssh.socket (via
> > > ssh@.service with the -i option), wheras on all other hosts sshd was
> > > running as a daemon (via ssh.service whith the -D option).
> > > 
> > > so, my first question is: why?

I don't think you've yet confirmed what's in your /etc/systemd tree
on the different hosts. Mine all show:

$ find /etc/systemd/ -name \*ssh\* -ls | squeeze-whitespace 
 1700765 0 lrwxrwxrwx 1 root root 31 Apr 16 20:31 
/etc/systemd/system/sshd.service -> /lib/systemd/system/ssh.service
 1700799 0 lrwxrwxrwx 1 root root 31 Apr 16 20:31 
/etc/systemd/system/multi-user.target.wants/ssh.service -> 
/lib/systemd/system/ssh.service
 1702117 0 lrwxrwxrwx 1 root root 42 Apr 16 20:56 
/etc/systemd/user/sockets.target.wants/gpg-agent-ssh.socket -> 
/usr/lib/systemd/user/gpg-agent-ssh.socket
$ 

with no trace of the @ version, below.

$ diff -u /lib/systemd/system/ssh*service
--- /lib/systemd/system/ssh.service 2022-07-01 17:37:41.0 -0500
+++ /lib/systemd/system/ssh@.service2022-07-01 17:37:41.0 -0500
@@ -1,22 +1,11 @@
 [Unit]
-Description=OpenBSD Secure Shell server
+Description=OpenBSD Secure Shell server per-connection daemon
 Documentation=man:sshd(8) man:sshd_config(5)
-After=network.target auditd.service
-ConditionPathExists=!/etc/ssh/sshd_not_to_be_run
+After=auditd.service
 
 [Service]
 EnvironmentFile=-/etc/default/ssh
-ExecStartPre=/usr/sbin/sshd -t
-ExecStart=/usr/sbin/sshd -D $SSHD_OPTS
-ExecReload=/usr/sbin/sshd -t
-ExecReload=/bin/kill -HUP $MAINPID
-KillMode=process
-Restart=on-failure
-RestartPreventExitStatus=255
-Type=notify
+ExecStart=-/usr/sbin/sshd -i $SSHD_OPTS   ←
+StandardInput=socket  ←
 RuntimeDirectory=sshd
 RuntimeDirectoryMode=0755
-
-[Install]
-WantedBy=multi-user.target
-Alias=sshd.service
$ 

Cheers,
David.

Re: sshd package systemd misconfiguration?

[Frank]

Op 16-09-2022 om 09:17 schreef Michael:

with ssh@.service it is completely different. for each connection there
is a dedicated sshd process being started, and each one of them has the
same /run/sshd directory assigned. and that's the problem if you have
more than one connection to a given host. as soon as the first
connection is terminated, the /run/sshd directory disappears, and the
other sshd's might run into problems.


Apparently this has already been 'fixed' for bookworm. That is, the
service section of the ssh@.service file currently includes
RuntimeDirectoryPreserve=yes.

Maybe file a bug report to have this added for bullseye?

Regards,
Frank

Re: sshd package systemd misconfiguration?

[Greg Wooledge]

On Fri, Sep 16, 2022 at 09:17:10AM +0200, Michael wrote:
> On Thursday, 15 September 2022 13:01:45 CEST, Greg Wooledge wrote:
> > unicorn:/lib/systemd/system$ grep RuntimeDirectory ssh@.service
> > RuntimeDirectory=sshd
> > RuntimeDirectoryMode=0755

> with ssh@.service it is completely different. for each connection there is a
> dedicated sshd process being started, and each one of them has the same
> /run/sshd directory assigned. and that's the problem if you have more than
> one connection to a given host. as soon as the first connection is
> terminated, the /run/sshd directory disappears, and the other sshd's might
> run into problems.

OK then.  This is a bit beyond my experience level, and should probably
be filed as a bug against Debian.

I did find this paragraph in systemd.exec(5):

   Use RuntimeDirectory= to manage one or more runtime directories for
   the unit and bind their lifetime to the daemon runtime. This is
   particularly useful for unprivileged daemons that cannot create
   runtime directories in /run/ due to lack of privileges, and to make
   sure the runtime directory is cleaned up automatically after use.
   For runtime directories that require more complex or different
   configuration or lifetime guarantees, please consider using
   tmpfiles.d(5).

Maybe you can find a workaround there, and/or contribute your workaround
when you file your bug report.

Personally, I've never configured sshd to use socket activation, nor do I
see any advantage in doing so.  Back in the old days, we were always
warned *not* to do that, because the startup time could be extremely long
due to entropy exhaustion.  Yeah, I know, entropy is handled differently
by the kernel now.  Still, I don't see any reason to move away from the
tried-and-tested single daemon model.

Re: sshd package systemd misconfiguration?

[Jonathan Dowland]

I've been hit by this too. Likewise I haven't deliberately
configured sshd for socket activation nor tampered with
unit files. In my case the host was a newly imaged raspberry
pi using the images linked from the Debian Wiki. I haven't
done any further investigation.

--

Jonathan Dowland
https://jmtd.net

Re: sshd package systemd misconfiguration?

[Michael]

On Thursday, 15 September 2022 13:01:45 CEST, Greg Wooledge wrote:

of course the first thing i did was to check if all the files from the 
package were as they should be, and everything was fine!




It's supposed to be created as needed.  There should be two lines in
the unit file:

unicorn:/lib/systemd/system$ grep RuntimeDirectory ssh@.service
RuntimeDirectory=sshd
RuntimeDirectoryMode=0755
unicorn:/lib/systemd/system$ grep RuntimeDirectory ssh.service
RuntimeDirectory=sshd
RuntimeDirectoryMode=0755



i never questioned that! my problem wasn't based on these lines are missing 
or in some way altered. my problem resulted in these lines being there as 
they are! ;)




That should cause the /run/sshd directory to be created when the service
is started, and removed when it's stopped.


you got it! :)

having 'RuntimeDirectory=sshd' in ssh.service is totally fine! that is, b/c 
sshd runs as a daemon, and each new connection is handled by that exact 
daemon. so the /run/sshd directory stays there no matter how many 
connections to the host exist or being terminated, etc.


with ssh@.service it is completely different. for each connection there is 
a dedicated sshd process being started, and each one of them has the same 
/run/sshd directory assigned. and that's the problem if you have more than 
one connection to a given host. as soon as the first connection is 
terminated, the /run/sshd directory disappears, and the other sshd's might 
run into problems.


but i still don't understand, why this scenario prevents me from contacting 
a host with the formerly mentioned error message in the log file...


greetings...

Re: sshd package systemd misconfiguration?

[Greg Wooledge]

On Thu, Sep 15, 2022 at 12:02:21PM +0200, Michael wrote:
> i recently had problems to reach some of my host with ssh. as it turned out,
> it was b/c sshd refused the connection due to a missing /run/sshd directory.
> 
> the logfile entry:
> Aug 28 00:10:08 mail sshd[151893]: fatal: Missing privilege separation
> directory: /run/sshd
> 
> so i started digging, and to my surprise i found out that on the affected
> servers sshd was configured to be invoked by ssh.socket (via ssh@.service
> with the -i option), wheras on all other hosts sshd was running as a daemon
> (via ssh.service whith the -D option).
> 
> so, my first question is: why?

I'm afraid only you can answer that one.

> now that i know the problem, i have essentially three choices (assuming not
> to change the invocation via ssh.socket):
> 1: create /run/sshd whenever it disappears
> 2: prevent /run/sshd from being deleted
> 3: make each ssh@.service session use its own directory

It's supposed to be created as needed.  There should be two lines in
the unit file:

unicorn:/lib/systemd/system$ grep RuntimeDirectory ssh@.service
RuntimeDirectory=sshd
RuntimeDirectoryMode=0755
unicorn:/lib/systemd/system$ grep RuntimeDirectory ssh.service
RuntimeDirectory=sshd
RuntimeDirectoryMode=0755

That should cause the /run/sshd directory to be created when the service
is started, and removed when it's stopped.

It's possible that someone has created a local override file on your
system which suppresses this, or that someone has actually edited the
unit file in /lib.  The latter should never happen, as a package upgrade
will replace the file and destroy the edits.

If the former has happened, you should see ssh.* files or directories
under /etc/systemd/system/.  If you have anything there which isn't
a symlink named sshd.service pointing to /lib/systemd/system/ssh.service
please show it to us -- "ls -l" output on the file, plus the file's
contents.

If your /lib/systemd/system/ssh@.service doesn't contain the two lines
I showed, then you might start by reinstalling the package, or perhaps
by noting the timestamp on the file, which should tell you when it was
modified.  Perhaps that will jog your memory about someone who might
have changed it.  Or maybe the file is simply corrupted by file system
damage, which should be obvious in a text editor.

sshd package systemd misconfiguration?

[Michael]

hey,

i recently had problems to reach some of my host with ssh. as it turned 
out, it was b/c sshd refused the connection due to a missing /run/sshd 
directory.


the logfile entry:
Aug 28 00:10:08 mail sshd[151893]: fatal: Missing privilege separation 
directory: /run/sshd


so i started digging, and to my surprise i found out that on the affected 
servers sshd was configured to be invoked by ssh.socket (via ssh@.service 
with the -i option), wheras on all other hosts sshd was running as a daemon 
(via ssh.service whith the -D option).


so, my first question is: why?

all servers run debian 11 (bullseye), updated from debian 10 (buster), and 
i cannot remember changing this, i.e. enabling ssh.socket. why would i?


now that i know the problem, i have essentially three choices (assuming not 
to change the invocation via ssh.socket):

1: create /run/sshd whenever it disappears
2: prevent /run/sshd from being deleted
3: make each ssh@.service session use its own directory

1: that's what i started with to monitor what was wrong, and to be able to 
use ssh but this is not a solution rather than a mitigation.


2: i added a drop-in at /etc/systemd/system/ssh@.service.d/ with 
'RuntimeDirectoryPreserve=yes', and it works,


3: first, i also added a drop in at /etc/systemd/system/ssh@.servide.d/ 
with 'RuntimeDirectory=sshd.%i', but it just added the new directory to the 
already defined 'sshd', resulting again in the deletion of /run/sshd. so i 
copied /usr/lib/systemd/system/ssh@.service to /etc/systemd/system/ and 
changed 'RuntimeDirectory=sshd' to 'RuntimeDirectory=sshd.%i', and it 
works.


is it safe to say, that this issue is a misconfiguration? should the 
package maintainer be notified? or did i miss something?


greetings...

Re: debian10/11 ssh from ipv6 address not in /etc/hosts.allow = sshd segfault segfault

[raf]

On Thu, Aug 19, 2021 at 04:25:34PM +, Andy Smith  
wrote:

> Hello,
> 
> On Tue, Aug 17, 2021 at 11:17:05AM +1000, raf wrote:
> > I just noticed many many sshd segfaults listed in
> > /var/log/kern.log. There are two versions. They look
> > like this:
> > 
> >   sshd[1086]: segfault at 7fff615eaec8 ip
> >   7ff2a586f42f sp 7fff615eaed0 error 6 in
> >   libwrap.so.0.7.6[7ff2a586e000+5000]
> > 
> >   sshd[1094]: segfault at 7ffcd3ff6f08 ip
> >   7f18d4f5dac7 sp 7ffcd3ff6ed0 error 6 in
> >   libc-2.31.so[7f18d4f2a000+14b000]
> 
> I think you should report this as a bug against openssh source
> package and see if you get any assistance. As the segfaults happen
> inside libwrap and libc it could end up being a bug in either of
> those instead, or in how sshd uses them, but let's see.
>
> Using "reportbug openssh-server" is probably the easiest.

> Cheers,
> Andy

Thanks. I did that already. I just posted it to the list as well
in case it helped others while waiting for a fix.

cheers,
raf

Re: debian10/11 ssh from ipv6 address not in /etc/hosts.allow = sshd segfault segfault

[Andy Smith]

Hello,

On Tue, Aug 17, 2021 at 11:17:05AM +1000, raf wrote:
> I just noticed many many sshd segfaults listed in
> /var/log/kern.log. There are two versions. They look
> like this:
> 
>   sshd[1086]: segfault at 7fff615eaec8 ip
>   7ff2a586f42f sp 7fff615eaed0 error 6 in
>   libwrap.so.0.7.6[7ff2a586e000+5000]
> 
>   sshd[1094]: segfault at 7ffcd3ff6f08 ip
>   7f18d4f5dac7 sp 7ffcd3ff6ed0 error 6 in
>   libc-2.31.so[7f18d4f2a000+14b000]

I think you should report this as a bug against openssh source
package and see if you get any assistance. As the segfaults happen
inside libwrap and libc it could end up being a bug in either of
those instead, or in how sshd uses them, but let's see.

Using "reportbug openssh-server" is probably the easiest.

Cheers,
Andy

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

debian10/11 ssh from ipv6 address not in /etc/hosts.allow = sshd segfault segfault

[raf]

Hi,

I just noticed many many sshd segfaults listed in
/var/log/kern.log. There are two versions. They look
like this:

  sshd[1086]: segfault at 7fff615eaec8 ip
  7ff2a586f42f sp 7fff615eaed0 error 6 in
  libwrap.so.0.7.6[7ff2a586e000+5000]

  sshd[1094]: segfault at 7ffcd3ff6f08 ip
  7f18d4f5dac7 sp 7ffcd3ff6ed0 error 6 in
  libc-2.31.so[7f18d4f2a000+14b000]

The hex addresses are different each time, but the rest
is the same.

It happens every time there's an incoming ssh
connection attempt via IPv6 when the IPv6 address isn't
listed in /ertc/hosts.allow. There are many because
it's a cronned backup.

I am using /etc/hosts.allow for sshd and have a mixture
of IPv4 and IPv6 addresses in it.

When I added the IPv6 address in question to
/etc/hosts.allow, the segfaults stopped and the
connections worked.

This started 2 days before I upgraded to debian11 and
there was a different version number for libc (so it's
not new), but it's still happening with debian11.

It might be a bug in libwrap0 (whose version number
didn't change much), or in how openssh-server is using
it.

cheers,
raf

Re: considering a new system and a sshd hybrid drive

[shirish शिरीष]

at bottom :-

On 30/12/2019, Alexander V. Makartsev  wrote:
> On 29.12.2019 15:49, shirish शिरीष wrote:
>> Hi all,
>>
>> I read Alexander's reply with interest at [1] .
>>
>> @Alexander, thank you for taking time to answer my question/s . Maybe
>> you can CC me the next time :)
>>
>> What was also interesting in your answer was the use of dark marketing
>> practises used by some manufacturers to disguise TLC (3-bit NAND)
>> memory chips as MLC ones but haven't shared either literature or any
>> tools to tell them apart.
>>
> Worst offender of this trickery is Samsung. You have to carefully read
> through full specifications for each device that available on official
> web sites, which are often hidden behind very long page scrolls and many
> clicks.
> Basically, if it says "4-bit" it means drive was build with QLC NAND
> type. And if it says "3-bit" it means TLC NAND type. And if it says
> "2-bit" it means MLC NAND type.
> And if some information is not available on official web site of some
> manufacturer, personally I'd search for another SSD elsewhere.
> There are also utilities that can view exact specifications of SSD, but
> I don't know if similar programs exist for Linux. [1]
> These kinds of utilities rely on internal database of known devices
> (nand chips, controllers, SSDs), so they can't simply identify any and
> all SSDs as is.
> If you have identified exact NAND chip and its manufacturer you can look
> up specifications for chips alone to see their, for an example, write
> endurance, which varies and could be different for each NAND type. [2]
>
>> You shared something called TBW or DWPD ratings for SSD but again
>> didn't share anything about that. Any links or literature which will
>> help me find a bit more about them and perhaps what you have used it
>> for ?  My workload varies, sometimes it is compiling, sometimes it is
>> running some tests, sometimes doing gaming and sometimes just browsing
>> and using multimedia (movies etc.) . So my idea and stress would be
>> general system improvements and response times. Also my budget is not
>> that great, at the most I could afford is either a 500 GB to 1 TB
> There is a good article to read about this. [3]
>>
>> I have also been reading about multi-actuator heads [2] in traditional
>> HDD's but guessing they will be probably be priced and used by
>> enterprise more rather than the enthusiast class at least in the
>> beginning. I also have read blackbaze hdd failures to get some ideas
>> about what's good or not even though their use-case scenario is far
>> bigger than mine.[3]
>>
>> For e.g. for me the question would be how to deal with backups and
>> crashes if a time comes, as checking 4 TB hdd's is also insane, at
>> least in my puny setup.
>>
>> Looking forward to know more.
>>
>> 1. https://lists.debian.org/debian-user/2019/12/msg00726.html
>> 2.
>> https://blog.seagate.com/craftsman-ship/multi-actuator-technology-a-new-performance-breakthrough/
>> 3. https://www.backblaze.com/blog/hard-drive-reliability-stats-q1-2016/
>>
> Personally, I use self-hosted NAS with RAID1 build from 2x 4TB NAS grade
> HDDs. Because I like to keep my data private and I like the idea of
> giving up storage space of one HDD drive as insurance for data safety.
> From my personal experience over many years, I can see how HDDs could
> fail in many different ways, long before SMART will mark them as "Failed".
> But it is very unlikely (and unfortunate) to buy a brand new HDD that
> will fail during it's warranty period, and if it worked fine before
> chances are high it will continue to work for many years after warranty
> period expires.
> Fun fact: I still have my ~20 years old 3.5" Fujitsu 20GB IDE HDD that
> is still alive and kicking. :)
>
> [1] http://aezay.dk/aezay/ssdz/
> [2] https://en.wikipedia.org/wiki/Flash_memory#Write_endurance
> [3]
> https://techcommunity.microsoft.com/t5/Storage-at-Microsoft/Understanding-SSD-endurance-drive-writes-per-day-DWPD-terabytes/ba-p/426024
>
> --
> With kindest regards, Alexander.
>
> ⢀⣴⠾⠻⢶⣦⠀
> ⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
> ⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org
> ⠈⠳⣄
>

Hi all,

I was looking at debian-user December thread and missed Alexander's
further reply at [1]
The ssd-z utility [2]  he shared seems interesting. Sadly, I would
missed it as I'm not subscribed to the list.

It took me sometime but remembered usb-modeswitch [3] and
usb-modeswitch-data [3] which basically did and does something similar
for usb modems. IIRC, the data package has details on low-level
hardware stuff (IRQ addresses and such) so that the user can just fill
in the details and just run it. The usb-modeswitch package was cool as
I was able to query the device and share the details of my hardware
with the maintainer in 2009 ish.

I remember as did use MTS Blaze and do have a Reliance Jio dongle
which behaves similarly as well (although don't use it as much
nowadays.) This is strictly to be used while travelling.

1. 

Re: considering a new system and a sshd hybrid drive

[Gene Heskett]

On Monday 30 December 2019 11:38:27 Alexander V. Makartsev wrote:

> On 30.12.2019 20:18, Gene Heskett wrote:
> > On Monday 30 December 2019 05:16:51 Alexander V. Makartsev wrote:
> >> On 29.12.2019 16:56, Gene Heskett wrote:
> >>> On Sunday 29 December 2019 04:42:20 Alexander V. Makartsev wrote:
>  On 29.12.2019 12:37, shirish शिरीष wrote:
> > Dear all,
> >
> > Last year I had read some articles when I was looking to build a
> > system there seemed to problems with hybrid drives. Does anybody
> > know how things stand/look today and if anybody had any good/bad
> > experience with them ?  IIRC, the issues were more to do with
> > the firmware rather than the hardware, is it the same or have
> > things improved ? which package I should be looking at if I'm
> > looking for solutions ?
> >
> >
> > I am ok with using either a stable or an alpha/debian-installer
> > snapshot if people have had good experience.
> >
> > Just so people have an idea about what hybrid drives are all
> > about, here are couple of links
> >
> > https://www.seagate.com/in/en/do-more/how-to-choose-between-hdd-
> >st or age-for-your-laptop-master-dm/
> >
> > https://www.howtogeek.com/195262/hybrid-hard-drives-explained-wh
> >y- yo u-might-want-one-instead-of-an-ssd/
> 
>  I strongly suggest against hybrid drives. It's just added
>  complexity and therefore more ways and parts to fail with time.
>  If you considering to buy hybrid HDD, chances are high you simply
>  want faster performance for your system. I don't see why to
>  choose slightly better solution (hybrid) over fastest one (SSDs).
>  For a system disk and\or laptop upgrade, I'd stick with plain
>  MLC-based (2 bit) NAND 250GB+ SSD (or NVMe if your system allows
>  it), because they have the best reliability+performance+price
>  ratings. Try to avoid TLC-based SSDs because they have much lower
>  reliability and performance in comparison to MLC-based SSDs, but
>  also much cheaper. And completely avoid QLC-based SSDs, which are
>  cheap, but slow and unreliable, similar to USB flash drives.
>  Backup your data (obvious), monitor health of your SSDs using
>  S.M.A.R.T. and you'll be just fine.
>  Also, watch out for manufacturers who use dark marketing
>  practices, offering MLC-based (3-bit) NAND in advertisement,
>  which is non-sense, but in reality they should be called
>  TLC-based (3-bit) NAND, and also avoid manufacturers who is
>  hiding real TBW or DWPD ratings of their SSD products and offer
>  only useless MTBF rating. By using TBW or DWPD ratings you can
>  calculate how long SSD will last in your estimated work-load.
> >>>
> >>> So how does one tell what sort of a drive I've bought half a dozen
> >>> of for under a 50 dollar bill for a 240 gig with a sata interface
> >>> actually is? ADATA's on sale usually.
> >>>
> >>> I've so far used them for a couple years, either on a std sata
> >>> cable, as the only drive in a cnc machine or on a usb-3 to sata
> >>> adapter. I've had zero drive failures and one adapter cable
> >>> failure, with the 2 latest installed as swap and work drives for
> >>> compiling both kernels and makeing deb's of linuxcnc on an rpi4.
> >>> Cuts a kernel build time by several hours, but I have noted they
> >>> do get a lot slower if the file being copied is several gigabytes.
> >>> Giving an 2Gb rpi4 a 10 Gb swap to play in is plumb amazing. Using
> >>> 197 megs to build the rs-274 interpreter of linuxcnc there was no
> >>> slowdown while doing it.
> >>>
> >>> There may be better choices out there, and I'd like to be able to
> >>> tell the difference, but these so far have been more that good
> >>> enough for "the girls I go with".
> >>>
> >>> Cheers, Gene Heskett
> >>
> >> You have to read through specifications that are available on
> >> official web site of the manufacturer.
> >> In addition to what I described in my previous email for OP, ADATA
> >> is also takes an opportunity to trick their customers, for an
> >> example they sell "Ultimate SU650" model which, according to their
> >> web site filter [1] could be either TLC or MLC type, and you still
> >> can't tell exact NAND type by reading specifications table [2] or
> >> the sticker on the device itself.
> >> Obviously, there is no way to see if manufacturers are lying about
> >> their specifications before you actually buy the specific model of
> >> SSD. And after you bought it, you can check the internals of it
> >> with SSD-Z utility. [3]
> >> I don't know if similar utility exists for Linux, though.
> >>
> >> [1] https://www.adata.com/en/Solid-State-Drives/25/
> >> [2] https://www.adata.com/en/specification/503
> >> [3] http://aezay.dk/aezay/ssdz/
> >
> > Thank you Alexander, interesting links, particularly the last one.
> > I've not even tried to snoop thru these as so far they Just Work.
> >
> > Is 

Re: considering a new system and a sshd hybrid drive

[Alexander V. Makartsev]

On 30.12.2019 20:18, Gene Heskett wrote:
> On Monday 30 December 2019 05:16:51 Alexander V. Makartsev wrote:
>
>> On 29.12.2019 16:56, Gene Heskett wrote:
>>> On Sunday 29 December 2019 04:42:20 Alexander V. Makartsev wrote:
 On 29.12.2019 12:37, shirish शिरीष wrote:
> Dear all,
>
> Last year I had read some articles when I was looking to build a
> system there seemed to problems with hybrid drives. Does anybody
> know how things stand/look today and if anybody had any good/bad
> experience with them ?  IIRC, the issues were more to do with the
> firmware rather than the hardware, is it the same or have things
> improved ? which package I should be looking at if I'm looking for
> solutions ?
>
>
> I am ok with using either a stable or an alpha/debian-installer
> snapshot if people have had good experience.
>
> Just so people have an idea about what hybrid drives are all
> about, here are couple of links
>
> https://www.seagate.com/in/en/do-more/how-to-choose-between-hdd-st
> or age-for-your-laptop-master-dm/
>
> https://www.howtogeek.com/195262/hybrid-hard-drives-explained-why-
> yo u-might-want-one-instead-of-an-ssd/
 I strongly suggest against hybrid drives. It's just added
 complexity and therefore more ways and parts to fail with time.
 If you considering to buy hybrid HDD, chances are high you simply
 want faster performance for your system. I don't see why to choose
 slightly better solution (hybrid) over fastest one (SSDs).
 For a system disk and\or laptop upgrade, I'd stick with plain
 MLC-based (2 bit) NAND 250GB+ SSD (or NVMe if your system allows
 it), because they have the best reliability+performance+price
 ratings. Try to avoid TLC-based SSDs because they have much lower
 reliability and performance in comparison to MLC-based SSDs, but
 also much cheaper. And completely avoid QLC-based SSDs, which are
 cheap, but slow and unreliable, similar to USB flash drives.
 Backup your data (obvious), monitor health of your SSDs using
 S.M.A.R.T. and you'll be just fine.
 Also, watch out for manufacturers who use dark marketing practices,
 offering MLC-based (3-bit) NAND in advertisement, which is
 non-sense, but in reality they should be called TLC-based (3-bit)
 NAND, and also avoid manufacturers who is hiding real TBW or DWPD
 ratings of their SSD products and offer only useless MTBF rating.
 By using TBW or DWPD ratings you can calculate how long SSD will
 last in your estimated work-load.
>>> So how does one tell what sort of a drive I've bought half a dozen
>>> of for under a 50 dollar bill for a 240 gig with a sata interface
>>> actually is? ADATA's on sale usually.
>>>
>>> I've so far used them for a couple years, either on a std sata
>>> cable, as the only drive in a cnc machine or on a usb-3 to sata
>>> adapter. I've had zero drive failures and one adapter cable failure,
>>> with the 2 latest installed as swap and work drives for compiling
>>> both kernels and makeing deb's of linuxcnc on an rpi4. Cuts a kernel
>>> build time by several hours, but I have noted they do get a lot
>>> slower if the file being copied is several gigabytes. Giving an 2Gb
>>> rpi4 a 10 Gb swap to play in is plumb amazing. Using 197 megs to
>>> build the rs-274 interpreter of linuxcnc there was no slowdown while
>>> doing it.
>>>
>>> There may be better choices out there, and I'd like to be able to
>>> tell the difference, but these so far have been more that good
>>> enough for "the girls I go with".
>>>
>>> Cheers, Gene Heskett
>> You have to read through specifications that are available on official
>> web site of the manufacturer.
>> In addition to what I described in my previous email for OP, ADATA is
>> also takes an opportunity to trick their customers, for an example
>> they sell "Ultimate SU650" model which, according to their web site
>> filter [1] could be either TLC or MLC type, and you still can't tell
>> exact NAND type by reading specifications table [2] or the sticker on
>> the device itself.
>> Obviously, there is no way to see if manufacturers are lying about
>> their specifications before you actually buy the specific model of
>> SSD. And after you bought it, you can check the internals of it with
>> SSD-Z utility. [3]
>> I don't know if similar utility exists for Linux, though.
>>
>> [1] https://www.adata.com/en/Solid-State-Drives/25/
>> [2] https://www.adata.com/en/specification/503
>> [3] http://aezay.dk/aezay/ssdz/
> Thank you Alexander, interesting links, particularly the last one. I've 
> not even tried to snoop thru these as so far they Just Work.
>
> Is smartctl growing any knowledge of these yet? I've not been aware of 
> any updates to it in a year or so.
I don't think so. This information is quite the low-level stuff, far
beyond simple S.M.A.R.T. manipulations, so I'd expect such functionality
more from projects 

Re: considering a new system and a sshd hybrid drive

[Gene Heskett]

On Monday 30 December 2019 05:16:51 Alexander V. Makartsev wrote:

> On 29.12.2019 16:56, Gene Heskett wrote:
> > On Sunday 29 December 2019 04:42:20 Alexander V. Makartsev wrote:
> >> On 29.12.2019 12:37, shirish शिरीष wrote:
> >>> Dear all,
> >>>
> >>> Last year I had read some articles when I was looking to build a
> >>> system there seemed to problems with hybrid drives. Does anybody
> >>> know how things stand/look today and if anybody had any good/bad
> >>> experience with them ?  IIRC, the issues were more to do with the
> >>> firmware rather than the hardware, is it the same or have things
> >>> improved ? which package I should be looking at if I'm looking for
> >>> solutions ?
> >>>
> >>>
> >>> I am ok with using either a stable or an alpha/debian-installer
> >>> snapshot if people have had good experience.
> >>>
> >>> Just so people have an idea about what hybrid drives are all
> >>> about, here are couple of links
> >>>
> >>> https://www.seagate.com/in/en/do-more/how-to-choose-between-hdd-st
> >>>or age-for-your-laptop-master-dm/
> >>>
> >>> https://www.howtogeek.com/195262/hybrid-hard-drives-explained-why-
> >>>yo u-might-want-one-instead-of-an-ssd/
> >>
> >> I strongly suggest against hybrid drives. It's just added
> >> complexity and therefore more ways and parts to fail with time.
> >> If you considering to buy hybrid HDD, chances are high you simply
> >> want faster performance for your system. I don't see why to choose
> >> slightly better solution (hybrid) over fastest one (SSDs).
> >> For a system disk and\or laptop upgrade, I'd stick with plain
> >> MLC-based (2 bit) NAND 250GB+ SSD (or NVMe if your system allows
> >> it), because they have the best reliability+performance+price
> >> ratings. Try to avoid TLC-based SSDs because they have much lower
> >> reliability and performance in comparison to MLC-based SSDs, but
> >> also much cheaper. And completely avoid QLC-based SSDs, which are
> >> cheap, but slow and unreliable, similar to USB flash drives.
> >> Backup your data (obvious), monitor health of your SSDs using
> >> S.M.A.R.T. and you'll be just fine.
> >> Also, watch out for manufacturers who use dark marketing practices,
> >> offering MLC-based (3-bit) NAND in advertisement, which is
> >> non-sense, but in reality they should be called TLC-based (3-bit)
> >> NAND, and also avoid manufacturers who is hiding real TBW or DWPD
> >> ratings of their SSD products and offer only useless MTBF rating.
> >> By using TBW or DWPD ratings you can calculate how long SSD will
> >> last in your estimated work-load.
> >
> > So how does one tell what sort of a drive I've bought half a dozen
> > of for under a 50 dollar bill for a 240 gig with a sata interface
> > actually is? ADATA's on sale usually.
> >
> > I've so far used them for a couple years, either on a std sata
> > cable, as the only drive in a cnc machine or on a usb-3 to sata
> > adapter. I've had zero drive failures and one adapter cable failure,
> > with the 2 latest installed as swap and work drives for compiling
> > both kernels and makeing deb's of linuxcnc on an rpi4. Cuts a kernel
> > build time by several hours, but I have noted they do get a lot
> > slower if the file being copied is several gigabytes. Giving an 2Gb
> > rpi4 a 10 Gb swap to play in is plumb amazing. Using 197 megs to
> > build the rs-274 interpreter of linuxcnc there was no slowdown while
> > doing it.
> >
> > There may be better choices out there, and I'd like to be able to
> > tell the difference, but these so far have been more that good
> > enough for "the girls I go with".
> >
> > Cheers, Gene Heskett
>
> You have to read through specifications that are available on official
> web site of the manufacturer.
> In addition to what I described in my previous email for OP, ADATA is
> also takes an opportunity to trick their customers, for an example
> they sell "Ultimate SU650" model which, according to their web site
> filter [1] could be either TLC or MLC type, and you still can't tell
> exact NAND type by reading specifications table [2] or the sticker on
> the device itself.
> Obviously, there is no way to see if manufacturers are lying about
> their specifications before you actually buy the specific model of
> SSD. And after you bought it, you can check the internals of it with
> SSD-Z utility. [3]
> I don't know if similar utility exists for Linux, though.
>
> [1] https://www.adata.com/en/Solid-State-Drives/25/
> [2] https://www.adata.com/en/specification/503
> [3] http://aezay.dk/aezay/ssdz/

Thank you Alexander, interesting links, particularly the last one. I've 
not even tried to snoop thru these as so far they Just Work.

Is smartctl growing any knowledge of these yet? I've not been aware of 
any updates to it in a year or so.

What os does this SSDZ work on?

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)
If we desire respect for 

Re: considering a new system and a sshd hybrid drive

[Alexander V. Makartsev]

On 29.12.2019 16:56, Gene Heskett wrote:
> On Sunday 29 December 2019 04:42:20 Alexander V. Makartsev wrote:
>
>> On 29.12.2019 12:37, shirish शिरीष wrote:
>>> Dear all,
>>>
>>> Last year I had read some articles when I was looking to build a
>>> system there seemed to problems with hybrid drives. Does anybody
>>> know how things stand/look today and if anybody had any good/bad
>>> experience with them ?  IIRC, the issues were more to do with the
>>> firmware rather than the hardware, is it the same or have things
>>> improved ? which package I should be looking at if I'm looking for
>>> solutions ?
>>>
>>>
>>> I am ok with using either a stable or an alpha/debian-installer
>>> snapshot if people have had good experience.
>>>
>>> Just so people have an idea about what hybrid drives are all about,
>>> here are couple of links
>>>
>>> https://www.seagate.com/in/en/do-more/how-to-choose-between-hdd-stor
>>> age-for-your-laptop-master-dm/
>>>
>>> https://www.howtogeek.com/195262/hybrid-hard-drives-explained-why-yo
>>> u-might-want-one-instead-of-an-ssd/
>> I strongly suggest against hybrid drives. It's just added complexity
>> and therefore more ways and parts to fail with time.
>> If you considering to buy hybrid HDD, chances are high you simply want
>> faster performance for your system. I don't see why to choose slightly
>> better solution (hybrid) over fastest one (SSDs).
>> For a system disk and\or laptop upgrade, I'd stick with plain
>> MLC-based (2 bit) NAND 250GB+ SSD (or NVMe if your system allows it),
>> because they have the best reliability+performance+price ratings. Try
>> to avoid TLC-based SSDs because they have much lower reliability and
>> performance in comparison to MLC-based SSDs, but also much cheaper.
>> And completely avoid QLC-based SSDs, which are cheap, but slow and
>> unreliable, similar to USB flash drives.
>> Backup your data (obvious), monitor health of your SSDs using
>> S.M.A.R.T. and you'll be just fine.
>> Also, watch out for manufacturers who use dark marketing practices,
>> offering MLC-based (3-bit) NAND in advertisement, which is non-sense,
>> but in reality they should be called TLC-based (3-bit) NAND, and also
>> avoid manufacturers who is hiding real TBW or DWPD ratings of their
>> SSD products and offer only useless MTBF rating.
>> By using TBW or DWPD ratings you can calculate how long SSD will last
>> in your estimated work-load.
> So how does one tell what sort of a drive I've bought half a dozen of for 
> under a 50 dollar bill for a 240 gig with a sata interface actually is? 
> ADATA's on sale usually.
>
> I've so far used them for a couple years, either on a std sata cable, as 
> the only drive in a cnc machine or on a usb-3 to sata adapter. I've had 
> zero drive failures and one adapter cable failure, with the 2 latest 
> installed as swap and work drives for compiling both kernels and makeing 
> deb's of linuxcnc on an rpi4. Cuts a kernel build time by several hours, 
> but I have noted they do get a lot slower if the file being copied is 
> several gigabytes. Giving an 2Gb rpi4 a 10 Gb swap to play in is plumb 
> amazing. Using 197 megs to build the rs-274 interpreter of linuxcnc 
> there was no slowdown while doing it.
>
> There may be better choices out there, and I'd like to be able to tell 
> the difference, but these so far have been more that good enough 
> for "the girls I go with".
>
> Cheers, Gene Heskett
You have to read through specifications that are available on official
web site of the manufacturer.
In addition to what I described in my previous email for OP, ADATA is
also takes an opportunity to trick their customers, for an example they
sell "Ultimate SU650" model which, according to their web site filter
[1] could be either TLC or MLC type, and you still can't tell exact NAND
type by reading specifications table [2] or the sticker on the device
itself.
Obviously, there is no way to see if manufacturers are lying about their
specifications before you actually buy the specific model of SSD. And
after you bought it, you can check the internals of it with SSD-Z
utility. [3]
I don't know if similar utility exists for Linux, though.

[1] https://www.adata.com/en/Solid-State-Drives/25/
[2] https://www.adata.com/en/specification/503
[3] http://aezay.dk/aezay/ssdz/

-- 
With kindest regards, Alexander.

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

Re: considering a new system and a sshd hybrid drive

[Alexander V. Makartsev]

On 29.12.2019 15:49, shirish शिरीष wrote:
> Hi all,
>
> I read Alexander's reply with interest at [1] .
>
> @Alexander, thank you for taking time to answer my question/s . Maybe
> you can CC me the next time :)
>
> What was also interesting in your answer was the use of dark marketing
> practises used by some manufacturers to disguise TLC (3-bit NAND)
> memory chips as MLC ones but haven't shared either literature or any
> tools to tell them apart.
>
Worst offender of this trickery is Samsung. You have to carefully read
through full specifications for each device that available on official
web sites, which are often hidden behind very long page scrolls and many
clicks.
Basically, if it says "4-bit" it means drive was build with QLC NAND
type. And if it says "3-bit" it means TLC NAND type. And if it says
"2-bit" it means MLC NAND type.
And if some information is not available on official web site of some
manufacturer, personally I'd search for another SSD elsewhere.
There are also utilities that can view exact specifications of SSD, but
I don't know if similar programs exist for Linux. [1]
These kinds of utilities rely on internal database of known devices
(nand chips, controllers, SSDs), so they can't simply identify any and
all SSDs as is.
If you have identified exact NAND chip and its manufacturer you can look
up specifications for chips alone to see their, for an example, write
endurance, which varies and could be different for each NAND type. [2]

> You shared something called TBW or DWPD ratings for SSD but again
> didn't share anything about that. Any links or literature which will
> help me find a bit more about them and perhaps what you have used it
> for ?  My workload varies, sometimes it is compiling, sometimes it is
> running some tests, sometimes doing gaming and sometimes just browsing
> and using multimedia (movies etc.) . So my idea and stress would be
> general system improvements and response times. Also my budget is not
> that great, at the most I could afford is either a 500 GB to 1 TB
There is a good article to read about this. [3]
>
> I have also been reading about multi-actuator heads [2] in traditional
> HDD's but guessing they will be probably be priced and used by
> enterprise more rather than the enthusiast class at least in the
> beginning. I also have read blackbaze hdd failures to get some ideas
> about what's good or not even though their use-case scenario is far
> bigger than mine.[3]
>
> For e.g. for me the question would be how to deal with backups and
> crashes if a time comes, as checking 4 TB hdd's is also insane, at
> least in my puny setup.
>
> Looking forward to know more.
>
> 1. https://lists.debian.org/debian-user/2019/12/msg00726.html
> 2. 
> https://blog.seagate.com/craftsman-ship/multi-actuator-technology-a-new-performance-breakthrough/
> 3. https://www.backblaze.com/blog/hard-drive-reliability-stats-q1-2016/
>
Personally, I use self-hosted NAS with RAID1 build from 2x 4TB NAS grade
HDDs. Because I like to keep my data private and I like the idea of
giving up storage space of one HDD drive as insurance for data safety.
>From my personal experience over many years, I can see how HDDs could
fail in many different ways, long before SMART will mark them as "Failed".
But it is very unlikely (and unfortunate) to buy a brand new HDD that
will fail during it's warranty period, and if it worked fine before
chances are high it will continue to work for many years after warranty
period expires.
Fun fact: I still have my ~20 years old 3.5" Fujitsu 20GB IDE HDD that
is still alive and kicking. :)

[1] http://aezay.dk/aezay/ssdz/
[2] https://en.wikipedia.org/wiki/Flash_memory#Write_endurance
[3]
https://techcommunity.microsoft.com/t5/Storage-at-Microsoft/Understanding-SSD-endurance-drive-writes-per-day-DWPD-terabytes/ba-p/426024

-- 
With kindest regards, Alexander.

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

Re: considering a new system and a sshd hybrid drive

[Gene Heskett]

On Sunday 29 December 2019 04:42:20 Alexander V. Makartsev wrote:

> On 29.12.2019 12:37, shirish शिरीष wrote:
> > Dear all,
> >
> > Last year I had read some articles when I was looking to build a
> > system there seemed to problems with hybrid drives. Does anybody
> > know how things stand/look today and if anybody had any good/bad
> > experience with them ?  IIRC, the issues were more to do with the
> > firmware rather than the hardware, is it the same or have things
> > improved ? which package I should be looking at if I'm looking for
> > solutions ?
> >
> >
> > I am ok with using either a stable or an alpha/debian-installer
> > snapshot if people have had good experience.
> >
> > Just so people have an idea about what hybrid drives are all about,
> > here are couple of links
> >
> > https://www.seagate.com/in/en/do-more/how-to-choose-between-hdd-stor
> >age-for-your-laptop-master-dm/
> >
> > https://www.howtogeek.com/195262/hybrid-hard-drives-explained-why-yo
> >u-might-want-one-instead-of-an-ssd/
>
> I strongly suggest against hybrid drives. It's just added complexity
> and therefore more ways and parts to fail with time.
> If you considering to buy hybrid HDD, chances are high you simply want
> faster performance for your system. I don't see why to choose slightly
> better solution (hybrid) over fastest one (SSDs).
> For a system disk and\or laptop upgrade, I'd stick with plain
> MLC-based (2 bit) NAND 250GB+ SSD (or NVMe if your system allows it),
> because they have the best reliability+performance+price ratings. Try
> to avoid TLC-based SSDs because they have much lower reliability and
> performance in comparison to MLC-based SSDs, but also much cheaper.
> And completely avoid QLC-based SSDs, which are cheap, but slow and
> unreliable, similar to USB flash drives.
> Backup your data (obvious), monitor health of your SSDs using
> S.M.A.R.T. and you'll be just fine.
> Also, watch out for manufacturers who use dark marketing practices,
> offering MLC-based (3-bit) NAND in advertisement, which is non-sense,
> but in reality they should be called TLC-based (3-bit) NAND, and also
> avoid manufacturers who is hiding real TBW or DWPD ratings of their
> SSD products and offer only useless MTBF rating.
> By using TBW or DWPD ratings you can calculate how long SSD will last
> in your estimated work-load.

So how does one tell what sort of a drive I've bought half a dozen of for 
under a 50 dollar bill for a 240 gig with a sata interface actually is? 
ADATA's on sale usually.

I've so far used them for a couple years, either on a std sata cable, as 
the only drive in a cnc machine or on a usb-3 to sata adapter. I've had 
zero drive failures and one adapter cable failure, with the 2 latest 
installed as swap and work drives for compiling both kernels and makeing 
deb's of linuxcnc on an rpi4. Cuts a kernel build time by several hours, 
but I have noted they do get a lot slower if the file being copied is 
several gigabytes. Giving an 2Gb rpi4 a 10 Gb swap to play in is plumb 
amazing. Using 197 megs to build the rs-274 interpreter of linuxcnc 
there was no slowdown while doing it.

There may be better choices out there, and I'd like to be able to tell 
the difference, but these so far have been more that good enough 
for "the girls I go with".

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)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 

Re: considering a new system and a sshd hybrid drive

[shirish शिरीष]

at bottom :-

On 29/12/2019, shirish शिरीष  wrote:
> Hi all,
>
> I read Alexander's reply with interest at [1] .
>
> @Alexander, thank you for taking time to answer my question/s . Maybe
> you can CC me the next time :)
>
> What was also interesting in your answer was the use of dark marketing
> practises used by some manufacturers to disguise TLC (3-bit NAND)
> memory chips as MLC ones but haven't shared either literature or any
> tools to tell them apart.
>
> I do remember and have seen similar USB pendrives who claim to have
> 16/32 GB but when you use them, they don't work at least with USB 2.0
> . I have been told by some people that for such 'big drives' usually
> usb 3.0/3.1 is good but as don't have access to such ports it's
> neither here or there. Anyways, most places even airports usually have
> usb 2.0 ports rather than usb 3.0/3.1 but that's a different argument
> or point altogether (the whole usb 2.0/3.0/3.1 stuff.)
>
> You shared something called TBW or DWPD ratings for SSD but again
> didn't share anything about that. Any links or literature which will
> help me find a bit more about them and perhaps what you have used it
> for ?  My workload varies, sometimes it is compiling, sometimes it is
> running some tests, sometimes doing gaming and sometimes just browsing
> and using multimedia (movies etc.) . So my idea and stress would be
> general system improvements and response times. Also my budget is not
> that great, at the most I could afford is either a 500 GB to 1 TB
>
> I have also been reading about multi-actuator heads [2] in traditional
> HDD's but guessing they will be probably be priced and used by
> enterprise more rather than the enthusiast class at least in the
> beginning. I also have read blackbaze hdd failures to get some ideas
> about what's good or not even though their use-case scenario is far
> bigger than mine.[3]
>
> For e.g. for me the question would be how to deal with backups and
> crashes if a time comes, as checking 4 TB hdd's is also insane, at
> least in my puny setup.
>
> Looking forward to know more.
>
> 1. https://lists.debian.org/debian-user/2019/12/msg00726.html
> 2.
> https://blog.seagate.com/craftsman-ship/multi-actuator-technology-a-new-performance-breakthrough/
> 3. https://www.backblaze.com/blog/hard-drive-reliability-stats-q1-2016/
>
> --
>   Regards,
>   Shirish Agarwal  शिरीष अग्रवाल
>   My quotes in this email licensed under CC 3.0
> http://creativecommons.org/licenses/by-nc/3.0/
> http://flossexperiences.wordpress.com
>
> E493 D466 6D67 59F5 1FD0 930F 870E 9A5B 5869 609C
>


3. Meant https://www.backblaze.com/blog/backblaze-hard-drive-stats-q3-2019/

-- 
  Regards,
  Shirish Agarwal  शिरीष अग्रवाल
  My quotes in this email licensed under CC 3.0
http://creativecommons.org/licenses/by-nc/3.0/
http://flossexperiences.wordpress.com

E493 D466 6D67 59F5 1FD0 930F 870E 9A5B 5869 609C

Re: considering a new system and a sshd hybrid drive

[shirish शिरीष]

Hi all,

I read Alexander's reply with interest at [1] .

@Alexander, thank you for taking time to answer my question/s . Maybe
you can CC me the next time :)

What was also interesting in your answer was the use of dark marketing
practises used by some manufacturers to disguise TLC (3-bit NAND)
memory chips as MLC ones but haven't shared either literature or any
tools to tell them apart.

I do remember and have seen similar USB pendrives who claim to have
16/32 GB but when you use them, they don't work at least with USB 2.0
. I have been told by some people that for such 'big drives' usually
usb 3.0/3.1 is good but as don't have access to such ports it's
neither here or there. Anyways, most places even airports usually have
usb 2.0 ports rather than usb 3.0/3.1 but that's a different argument
or point altogether (the whole usb 2.0/3.0/3.1 stuff.)

You shared something called TBW or DWPD ratings for SSD but again
didn't share anything about that. Any links or literature which will
help me find a bit more about them and perhaps what you have used it
for ?  My workload varies, sometimes it is compiling, sometimes it is
running some tests, sometimes doing gaming and sometimes just browsing
and using multimedia (movies etc.) . So my idea and stress would be
general system improvements and response times. Also my budget is not
that great, at the most I could afford is either a 500 GB to 1 TB

I have also been reading about multi-actuator heads [2] in traditional
HDD's but guessing they will be probably be priced and used by
enterprise more rather than the enthusiast class at least in the
beginning. I also have read blackbaze hdd failures to get some ideas
about what's good or not even though their use-case scenario is far
bigger than mine.[3]

For e.g. for me the question would be how to deal with backups and
crashes if a time comes, as checking 4 TB hdd's is also insane, at
least in my puny setup.

Looking forward to know more.

1. https://lists.debian.org/debian-user/2019/12/msg00726.html
2. 
https://blog.seagate.com/craftsman-ship/multi-actuator-technology-a-new-performance-breakthrough/
3. https://www.backblaze.com/blog/hard-drive-reliability-stats-q1-2016/

-- 
  Regards,
  Shirish Agarwal  शिरीष अग्रवाल
  My quotes in this email licensed under CC 3.0
http://creativecommons.org/licenses/by-nc/3.0/
http://flossexperiences.wordpress.com

E493 D466 6D67 59F5 1FD0 930F 870E 9A5B 5869 609C

Re: considering a new system and a sshd hybrid drive

[Alexander V. Makartsev]

On 29.12.2019 12:37, shirish शिरीष wrote:
> Dear all,
>
> Last year I had read some articles when I was looking to build a
> system there seemed to problems with hybrid drives. Does anybody know
> how things stand/look today and if anybody had any good/bad experience
> with them ?  IIRC, the issues were more to do with the firmware rather
> than the hardware, is it the same or have things improved ? which
> package I should be looking at if I'm looking for solutions ?
>
>
> I am ok with using either a stable or an alpha/debian-installer
> snapshot if people have had good experience.
>
> Just so people have an idea about what hybrid drives are all about,
> here are couple of links
>
> https://www.seagate.com/in/en/do-more/how-to-choose-between-hdd-storage-for-your-laptop-master-dm/
>
> https://www.howtogeek.com/195262/hybrid-hard-drives-explained-why-you-might-want-one-instead-of-an-ssd/
>
I strongly suggest against hybrid drives. It's just added complexity and
therefore more ways and parts to fail with time.
If you considering to buy hybrid HDD, chances are high you simply want
faster performance for your system. I don't see why to choose slightly
better solution (hybrid) over fastest one (SSDs).
For a system disk and\or laptop upgrade, I'd stick with plain MLC-based
(2 bit) NAND 250GB+ SSD (or NVMe if your system allows it), because they
have the best reliability+performance+price ratings. Try to avoid
TLC-based SSDs because they have much lower reliability and performance
in comparison to MLC-based SSDs, but also much cheaper. And completely
avoid QLC-based SSDs, which are cheap, but slow and unreliable, similar
to USB flash drives.
Backup your data (obvious), monitor health of your SSDs using S.M.A.R.T.
and you'll be just fine.
Also, watch out for manufacturers who use dark marketing practices,
offering MLC-based (3-bit) NAND in advertisement, which is non-sense,
but in reality they should be called TLC-based (3-bit) NAND, and also
avoid manufacturers who is hiding real TBW or DWPD ratings of their SSD
products and offer only useless MTBF rating.
By using TBW or DWPD ratings you can calculate how long SSD will last in
your estimated work-load.


-- 
With kindest regards, Alexander.

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

considering a new system and a sshd hybrid drive

[shirish शिरीष]

Dear all,

Last year I had read some articles when I was looking to build a
system there seemed to problems with hybrid drives. Does anybody know
how things stand/look today and if anybody had any good/bad experience
with them ?  IIRC, the issues were more to do with the firmware rather
than the hardware, is it the same or have things improved ? which
package I should be looking at if I'm looking for solutions ?


I am ok with using either a stable or an alpha/debian-installer
snapshot if people have had good experience.

Just so people have an idea about what hybrid drives are all about,
here are couple of links

https://www.seagate.com/in/en/do-more/how-to-choose-between-hdd-storage-for-your-laptop-master-dm/

https://www.howtogeek.com/195262/hybrid-hard-drives-explained-why-you-might-want-one-instead-of-an-ssd/

-- 
  Regards,
  Shirish Agarwal  शिरीष अग्रवाल
  My quotes in this email licensed under CC 3.0
http://creativecommons.org/licenses/by-nc/3.0/
http://flossexperiences.wordpress.com

E493 D466 6D67 59F5 1FD0 930F 870E 9A5B 5869 609C

Re: sshd fails to bind to port to IP on boot

[yoda woya]

solved issue ... thank u

On Fri, Sep 27, 2019 at 11:55 AM Greg Wooledge  wrote:

> On Fri, Sep 27, 2019 at 11:44:25AM -0400, yoda woya wrote:
> > The public interface is listed defined as
> >
> > # The public network interface
> > allow-hotplug eno1
> > iface eno1 inet static
> > address x.x.x.x
> >
> >
> > But I have that same configuration on another server and it works fine.
>
> Replace allow-hotplug with auto.
>
>

Re: sshd fails to bind to port to IP on boot

[Greg Wooledge]

On Fri, Sep 27, 2019 at 11:44:25AM -0400, yoda woya wrote:
> The public interface is listed defined as
> 
> # The public network interface
> allow-hotplug eno1
> iface eno1 inet static
> address x.x.x.x
> 
> 
> But I have that same configuration on another server and it works fine.

Replace allow-hotplug with auto.

Re: sshd fails to bind to port to IP on boot

[Reco]

Hi.

Please do not top-post.

On Fri, Sep 27, 2019 at 11:51:08AM -0400, yoda woya wrote:
> How can I use to solve the problem:
> 
> "ssh.service has "After=network.target", and network.target only waits
> for interfaces marked as "auto" to come up."

You have this in your /etc/network/interfaces:

The public interface is listed defined as

# The public network interface
allow-hotplug eno1
iface eno1 inet static
address x.x.x.x

What Greg is telling you is that you should have this instead:

The public interface is listed defined as

# The public network interface
auto eno1
iface eno1 inet static
address x.x.x.x

Reco

Re: sshd fails to bind to port to IP on boot

[yoda woya]

How can I use to solve the problem:

"ssh.service has "After=network.target", and network.target only waits
for interfaces marked as "auto" to come up."



On Fri, Sep 27, 2019 at 11:26 AM Greg Wooledge  wrote:

> On Fri, Sep 27, 2019 at 11:16:51AM -0400, yoda woya wrote:
> > Below is the error I get.  However the service works at boot if
> > InternetAddress is commented out or set to 0.0.0.0.  The service works
> > manually ( /etc/init.d/ssh start)
> > -- Subject: A start job for unit ssh.service has begun execution
> > -- A start job for unit ssh.service has begun execution.
> > Sep 27 10:52:31 nat6pub sshd[690]: error: Bind to port 2022 on x.x.x.x
> > failed: Cannot assign requested address.
> > Sep 27 10:52:31 nat6pub sshd[690]: fatal: Cannot bind any address.
> > Sep 27 10:52:31 nat6pub systemd[1]: ssh.service: Main process exited,
> > code=exited, status=255/EXCEPTION
>
> Sounds like the x.x.x.x address doesn't exist at the time ssh.service
> is trying to run.  The most likely reasons for this are that your x.x.x.x
> address is assigned to an interface that's configured later in the boot
> process (e.g. a wireless interface), or that it's assigned to an
> interface which is marked as "allow-hotplug" rather than "auto" in
> /etc/network/interfaces.
>
> ssh.service has "After=network.target", and network.target only waits
> for interfaces marked as "auto" to come up.  If that.
>
>

Re: sshd fails to bind to port to IP on boot

[yoda woya]

The public interface is listed defined as

# The public network interface
allow-hotplug eno1
iface eno1 inet static
address x.x.x.x


But I have that same configuration on another server and it works fine.

On Fri, Sep 27, 2019 at 11:42 AM yoda woya  wrote:

> # The public network interface
> allow-hotplug eno1
> iface eno1 inet static
> address 128.59.176.101
>
> On Fri, Sep 27, 2019 at 11:25 AM Dan Ritter  wrote:
>
>> yoda woya wrote:
>> > Below is the error I get.  However the service works at boot if
>> > InternetAddress is commented out or set to 0.0.0.0.  The service works
>> > manually ( /etc/init.d/ssh start)
>> > -- Subject: A start job for unit ssh.service has begun execution
>> > -- A start job for unit ssh.service has begun execution.
>> > Sep 27 10:52:31 nat6pub sshd[690]: error: Bind to port 2022 on x.x.x.x
>> > failed: Cannot assign requested address.
>>
>>
>> Do you have an existing interface with x.x.x.x assigned to it?
>>
>> -dsr-
>>
>

Re: sshd fails to bind to port to IP on boot

[yoda woya]

# The public network interface
allow-hotplug eno1
iface eno1 inet static
address 128.59.176.101

On Fri, Sep 27, 2019 at 11:25 AM Dan Ritter  wrote:

> yoda woya wrote:
> > Below is the error I get.  However the service works at boot if
> > InternetAddress is commented out or set to 0.0.0.0.  The service works
> > manually ( /etc/init.d/ssh start)
> > -- Subject: A start job for unit ssh.service has begun execution
> > -- A start job for unit ssh.service has begun execution.
> > Sep 27 10:52:31 nat6pub sshd[690]: error: Bind to port 2022 on x.x.x.x
> > failed: Cannot assign requested address.
>
>
> Do you have an existing interface with x.x.x.x assigned to it?
>
> -dsr-
>

Re: sshd fails to bind to port to IP on boot

[Greg Wooledge]

On Fri, Sep 27, 2019 at 11:16:51AM -0400, yoda woya wrote:
> Below is the error I get.  However the service works at boot if
> InternetAddress is commented out or set to 0.0.0.0.  The service works
> manually ( /etc/init.d/ssh start)
> -- Subject: A start job for unit ssh.service has begun execution
> -- A start job for unit ssh.service has begun execution.
> Sep 27 10:52:31 nat6pub sshd[690]: error: Bind to port 2022 on x.x.x.x
> failed: Cannot assign requested address.
> Sep 27 10:52:31 nat6pub sshd[690]: fatal: Cannot bind any address.
> Sep 27 10:52:31 nat6pub systemd[1]: ssh.service: Main process exited,
> code=exited, status=255/EXCEPTION

Sounds like the x.x.x.x address doesn't exist at the time ssh.service
is trying to run.  The most likely reasons for this are that your x.x.x.x
address is assigned to an interface that's configured later in the boot
process (e.g. a wireless interface), or that it's assigned to an
interface which is marked as "allow-hotplug" rather than "auto" in
/etc/network/interfaces.

ssh.service has "After=network.target", and network.target only waits
for interfaces marked as "auto" to come up.  If that.

Re: sshd fails to bind to port to IP on boot

[Dan Ritter]

yoda woya wrote: 
> Below is the error I get.  However the service works at boot if
> InternetAddress is commented out or set to 0.0.0.0.  The service works
> manually ( /etc/init.d/ssh start)
> -- Subject: A start job for unit ssh.service has begun execution
> -- A start job for unit ssh.service has begun execution.
> Sep 27 10:52:31 nat6pub sshd[690]: error: Bind to port 2022 on x.x.x.x
> failed: Cannot assign requested address.


Do you have an existing interface with x.x.x.x assigned to it?

-dsr-

Re: sshd fails to bind to port to IP on boot

[yoda woya]

Below is the error I get.  However the service works at boot if
InternetAddress is commented out or set to 0.0.0.0.  The service works
manually ( /etc/init.d/ssh start)
-- Subject: A start job for unit ssh.service has begun execution
-- A start job for unit ssh.service has begun execution.
Sep 27 10:52:31 nat6pub sshd[690]: error: Bind to port 2022 on x.x.x.x
failed: Cannot assign requested address.
Sep 27 10:52:31 nat6pub sshd[690]: fatal: Cannot bind any address.
Sep 27 10:52:31 nat6pub systemd[1]: ssh.service: Main process exited,
code=exited, status=255/EXCEPTION
-- An ExecStart= process belonging to unit ssh.service has exited.
Sep 27 10:52:31 nat6pub systemd[1]: ssh.service: Failed with result
'exit-code'.
-- The unit ssh.service has entered the 'failed' state with result
'exit-code'.
-- Subject: A start job for unit ssh.service has failed
-- A start job for unit ssh.service has finished with a failure.
-- Subject: A start job for unit ssh.service has begun execution
-- A start job for unit ssh.service has begun execution.
-- Subject: A start job for unit ssh.service has finished successfully
-- A start job for unit ssh.service has finished successfully.


On Thu, Sep 26, 2019 at 6:23 PM Roberto C. Sánchez 
wrote:

> On Thu, Sep 26, 2019 at 05:34:02PM -0400, yoda woya wrote:
> >when I use this, the binding fails:
> >Port 2022
> >#AddressFamily any
> >ListenAddress x.x.x.x
> >#ListenAddress ::
> >but if I do , it binds it to the ip on boot
> >Port 2022
> >#AddressFamily any
> >#ListenAddress x.x.x
> >#ListenAddress ::
> >How can i fix this.  I want sshd to run only on this one IP
>
> What is the exact error message when it fails?
>
> Regards,
>
> -Roberto
> --
> Roberto C. Sánchez
>
>

Re: sshd fails to bind to port to IP on boot

[tomas]

On Thu, Sep 26, 2019 at 05:34:02PM -0400, yoda woya wrote:
> when I use this, the binding fails:
> Port 2022
> #AddressFamily any
> ListenAddress x.x.x.x
> #ListenAddress ::
> 
> but if I do , it binds it to the ip on boot
> Port 2022
> #AddressFamily any
> #ListenAddress x.x.x
> #ListenAddress ::
> 
> 
> How can i fix this.  I want sshd to run only on this one IP

Are you sure that specific interface is up at the time sshd
starts?

To double check that, you could try to restart sshd manually
(check with your init's system's instructions) once the machine
is up: does it then succeed in binding?

Cheers
-- t


signature.asc
Description: Digital signature

Re: sshd fails to bind to port to IP on boot

[Roberto C . Sánchez]

On Thu, Sep 26, 2019 at 05:34:02PM -0400, yoda woya wrote:
>when I use this, the binding fails:
>Port 2022
>#AddressFamily any
>ListenAddress x.x.x.x
>#ListenAddress ::
>but if I do , it binds it to the ip on boot
>Port 2022
>#AddressFamily any
>#ListenAddress x.x.x
>#ListenAddress ::
>    How can i fix this.  I want sshd to run only on this one IP

What is the exact error message when it fails?

Regards,

-Roberto
-- 
Roberto C. Sánchez

sshd fails to bind to port to IP on boot

[yoda woya]

when I use this, the binding fails:
Port 2022
#AddressFamily any
ListenAddress x.x.x.x
#ListenAddress ::

but if I do , it binds it to the ip on boot
Port 2022
#AddressFamily any
#ListenAddress x.x.x
#ListenAddress ::


How can i fix this.  I want sshd to run only on this one IP

Re: fail2ban : sshd jail ne fonctionne pas (encore)

[Pierre Malard]

Ok, logique.

Regarde quand même le /var/log/syslog quand tu démarre Fail2Ban…

> Le 11 juil. 2019 à 19:11, Belaïd  a écrit :
> 
> Salut,
> 
> Comme les serveurs sont identiques,  pourquoi ne pas mettre la config des 
> jails dans le même dossier ?  À ta place Je ferai ça dans 
> /etc/fail2ban/jail.d/
> 
> Le jeu. 11 juil. 2019 17:06, fab  <mailto:regnier@free.fr>> a écrit :
> salut la liste,
> 
> Soient 2 serveurs quasi-identiques sur stretch à jour. fail2ban
> fonctionne correctement sur le serveur B mais pas sur le serveur A. Pour
> l'instant je n'ai paramétré qu'une seule prison sshd.
> 
> 
> serveur A:
> # cat defaults-debian.conf
> [sshd]
> port = 
> enabled = true
> maxretry = 2
> 
> serveur B:
> # cat ../jail.local
> [sshd]
> port = 
> enabled = true
> maxretry = 2
> 
> Les /etc/ssh/ssd_confid des 2 serveurs sont identiques.
> 
> Serveur A et B:
> # iptables -S
> -P INPUT ACCEPT
> -P FORWARD ACCEPT
> -P OUTPUT ACCEPT
> -N f2b-sshd
> -A INPUT -p tcp -m multiport --dports  -j f2b-sshd
> -A f2b-sshd -j RETURN
> 
> 
> /var/log/fail2ban.log des Serveurs A et B sont identiques:
> 
>   Stopping all jails
>   Jail 'sshd' stopped
>   Exiting Fail2ban
>   Changed logging target to /var/log/fail2ban.log for Fail2ban v0.9.6
>   Connected to fail2ban persistent database
> '/var/lib/fail2ban/fail2ban.sqlite3'
>   Creating new jail 'sshd'
>   Jail 'sshd' uses pyinotify {}
>   Initiated 'pyinotify' backend
>   Set jail log file encoding to UTF-8
>   Set maxRetry = 2
>   Added logfile = /var/log/auth.log
>   Set findtime = 600
>   Set banTime = 600
>   Set maxlines = 10
>   Jail sshd is not a JournalFilter instance
>   Jail 'sshd' started
> 
> /etc/hosts.allow sur les 2 serveurs sont les même.
> 
> Bref, c'est tout pareil (à priori).
> 
> Quand je fais un ssh toto@serveurB: et que je rentre un mauvais mot
> de passe, fail2ban me bannit: OK.
> 
> Dans le auth.log du serveur B, j'ai :
> pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0
> tty=ssh ruser= rhost=11.22.33.44  user=toto
> Failed password for toto from 11.22.33.44 port 40664 ssh2
> 
> Quand je fais un ssh toto@serveurA: et que je rentre un mauvais mot
> de passe, fail2ban ne me bannit pas et je n'ai rien dans fail2ban.log.
> 
> Dans le auth.log du serveur A, j'ai :
> pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0
> tty=ssh ruser= rhost=11.22.33.44  user=toto
> Failed password for toto from 11.22.33.44 port 41342 ssh2
> Failed password for toto from 11.22.33.44 port 41342 ssh2
> Failed password for toto from 11.22.33.44 port 41342 ssh2
> Connection closed by 11.22.33.44 port 41342 [preauth]
> PAM 2 more authentication failures; logname= uid=0 euid=0 tty=ssh ruser=
> rhost=11.22.33.44  user=toto
> 
> Tout se passe comme si je n'avais pas démarré fail2an sur le serveur A.
> 
> Si vous avez une piste ou une idée, une vanne ou un bon mot je prends!
> 
> merki,
> 
> f.
> 
> 

--
Pierre Malard

  « on ne risque rien à livrer le secret professionnel car
 on ne livre pas la façon de s’en servir »
  Jean Cocteau - « Le secret professionnel » - 1922

   |\  _,,,---,,_
   /,`.-'`'-.  ;-;;,_
  |,4-  ) )-,_. ,\ (  `'-'
 '---''(_/--'  `-'\_)   πr

perl -e '$_=q#: 3|\ 5_,3-3,2_: 3/,`.'"'"'`'"'"' 5-.  ;-;;,_:  |,A-  ) )-,_. ,\ 
(  `'"'"'-'"'"': '"'"'-3'"'"'2(_/--'"'"'  `-'"'"'\_): 
24πr::#;y#:#\n#;s#(\D)(\d+)#$1x$2#ge;print'
- --> Ce message n’engage que son auteur <--



signature.asc
Description: Message signed with OpenPGP

Re: fail2ban : sshd jail ne fonctionne pas (encore)

[Belaïd]

Salut,

Comme les serveurs sont identiques,  pourquoi ne pas mettre la config des
jails dans le même dossier ?  À ta place Je ferai ça dans
/etc/fail2ban/jail.d/

Le jeu. 11 juil. 2019 17:06, fab  a écrit :

> salut la liste,
>
> Soient 2 serveurs quasi-identiques sur stretch à jour. fail2ban
> fonctionne correctement sur le serveur B mais pas sur le serveur A. Pour
> l'instant je n'ai paramétré qu'une seule prison sshd.
>
>
> serveur A:
> # cat defaults-debian.conf
> [sshd]
> port = 
> enabled = true
> maxretry = 2
>
> serveur B:
> # cat ../jail.local
> [sshd]
> port = 
> enabled = true
> maxretry = 2
>
> Les /etc/ssh/ssd_confid des 2 serveurs sont identiques.
>
> Serveur A et B:
> # iptables -S
> -P INPUT ACCEPT
> -P FORWARD ACCEPT
> -P OUTPUT ACCEPT
> -N f2b-sshd
> -A INPUT -p tcp -m multiport --dports  -j f2b-sshd
> -A f2b-sshd -j RETURN
>
>
> /var/log/fail2ban.log des Serveurs A et B sont identiques:
>
>   Stopping all jails
>   Jail 'sshd' stopped
>   Exiting Fail2ban
>   Changed logging target to /var/log/fail2ban.log for Fail2ban v0.9.6
>   Connected to fail2ban persistent database
> '/var/lib/fail2ban/fail2ban.sqlite3'
>   Creating new jail 'sshd'
>   Jail 'sshd' uses pyinotify {}
>   Initiated 'pyinotify' backend
>   Set jail log file encoding to UTF-8
>   Set maxRetry = 2
>   Added logfile = /var/log/auth.log
>   Set findtime = 600
>   Set banTime = 600
>   Set maxlines = 10
>   Jail sshd is not a JournalFilter instance
>   Jail 'sshd' started
>
> /etc/hosts.allow sur les 2 serveurs sont les même.
>
> Bref, c'est tout pareil (à priori).
>
> Quand je fais un ssh toto@serveurB: et que je rentre un mauvais mot
> de passe, fail2ban me bannit: OK.
>
> Dans le auth.log du serveur B, j'ai :
> pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0
> tty=ssh ruser= rhost=11.22.33.44  user=toto
> Failed password for toto from 11.22.33.44 port 40664 ssh2
>
> Quand je fais un ssh toto@serveurA: et que je rentre un mauvais mot
> de passe, fail2ban ne me bannit pas et je n'ai rien dans fail2ban.log.
>
> Dans le auth.log du serveur A, j'ai :
> pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0
> tty=ssh ruser= rhost=11.22.33.44  user=toto
> Failed password for toto from 11.22.33.44 port 41342 ssh2
> Failed password for toto from 11.22.33.44 port 41342 ssh2
> Failed password for toto from 11.22.33.44 port 41342 ssh2
> Connection closed by 11.22.33.44 port 41342 [preauth]
> PAM 2 more authentication failures; logname= uid=0 euid=0 tty=ssh ruser=
> rhost=11.22.33.44  user=toto
>
> Tout se passe comme si je n'avais pas démarré fail2an sur le serveur A.
>
> Si vous avez une piste ou une idée, une vanne ou un bon mot je prends!
>
> merki,
>
> f.
>
>
>

Re: fail2ban : sshd jail ne fonctionne pas (encore)

[Pierre Malard]

Salut,

En supposant bien entendu que tu as installé le paquet Fail2Ban de Debian et 
pas un source venant du site du développeur…

Ça n’a peut-être rien à voir mais « Fail2Ban » préfère maintenant la 
déclaration des déclarations de taules (« jail ») dans un répertoire spécifique 
(« /etc/fail2ban/jail.d »). SI tu as déclaré une configuration dans le 
/etc/fail2ban/jail.local et qu’il en existe une spécifique à SSH dans le 
/etc/fail2ban/jail.d/, je ne sais pas lequel « aura raison ».

Une autre piste pour suivre le lancement de Fail2Ban c’est de suivre son 
lancement dans le fichier log /var/log/syslog. Avant de voir le comportement 
une fois lancé, il est bon de savoir s’il n’y a pas eu un problème … au 
lancement. C’est là que le lancement est suivit. Avant de voir le comportement 
une fois lancé, il est bon de savoir s’il n’y a pas eu un problème … au 
lancement.
À ce jeu, je me suis rendu compte que certains services n’écrivent pas par 
défaut leurs logs dans les fichiers déclarés par défaut dans Fail2Ban. Tout ça 
se trouve dans les fichiers « /etc/fail2ban/path-….conf ».

Sinon, pour savoir si Fail2Ban tourne, un simple :
# ps -ef | grep fail2ban
suffit.

> Le 11 juil. 2019 à 17:06, fab  a écrit :
> 
> salut la liste,
> 
> Soient 2 serveurs quasi-identiques sur stretch à jour. fail2ban
> fonctionne correctement sur le serveur B mais pas sur le serveur A. Pour 
> l'instant je n'ai paramétré qu'une seule prison sshd.
> 
> 
> serveur A:
> # cat defaults-debian.conf
> [sshd]
> port = 
> enabled = true
> maxretry = 2
> 
> serveur B:
> # cat ../jail.local
> [sshd]
> port = 
> enabled = true
> maxretry = 2
> 
> Les /etc/ssh/ssd_confid des 2 serveurs sont identiques.
> 
> Serveur A et B:
> # iptables -S
> -P INPUT ACCEPT
> -P FORWARD ACCEPT
> -P OUTPUT ACCEPT
> -N f2b-sshd
> -A INPUT -p tcp -m multiport --dports  -j f2b-sshd
> -A f2b-sshd -j RETURN
> 
> 
> /var/log/fail2ban.log des Serveurs A et B sont identiques:
> 
> Stopping all jails
> Jail 'sshd' stopped
> Exiting Fail2ban
> Changed logging target to /var/log/fail2ban.log for Fail2ban v0.9.6
> Connected to fail2ban persistent database
> '/var/lib/fail2ban/fail2ban.sqlite3'
> Creating new jail 'sshd'
> Jail 'sshd' uses pyinotify {}
> Initiated 'pyinotify' backend
> Set jail log file encoding to UTF-8
> Set maxRetry = 2
> Added logfile = /var/log/auth.log
> Set findtime = 600
> Set banTime = 600
> Set maxlines = 10
> Jail sshd is not a JournalFilter instance
> Jail 'sshd' started
> 
> /etc/hosts.allow sur les 2 serveurs sont les même.
> 
> Bref, c'est tout pareil (à priori).
> 
> Quand je fais un ssh toto@serveurB: et que je rentre un mauvais mot
> de passe, fail2ban me bannit: OK.
> 
> Dans le auth.log du serveur B, j'ai :
> pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0
> tty=ssh ruser= rhost=11.22.33.44  user=toto
> Failed password for toto from 11.22.33.44 port 40664 ssh2
> 
> Quand je fais un ssh toto@serveurA: et que je rentre un mauvais mot
> de passe, fail2ban ne me bannit pas et je n'ai rien dans fail2ban.log.
> 
> Dans le auth.log du serveur A, j'ai :
> pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0
> tty=ssh ruser= rhost=11.22.33.44  user=toto
> Failed password for toto from 11.22.33.44 port 41342 ssh2
> Failed password for toto from 11.22.33.44 port 41342 ssh2
> Failed password for toto from 11.22.33.44 port 41342 ssh2
> Connection closed by 11.22.33.44 port 41342 [preauth]
> PAM 2 more authentication failures; logname= uid=0 euid=0 tty=ssh ruser=
> rhost=11.22.33.44  user=toto
> 
> Tout se passe comme si je n'avais pas démarré fail2an sur le serveur A.
> 
> Si vous avez une piste ou une idée, une vanne ou un bon mot je prends!
> 
> merki,
> 
> f.
> 
> 

--
Pierre Malard

À propos de nos chers économistes :
«Les habiles, dans notre siècle, se sont décernés a eux-mêmes la
qualification d’homme d’état. [...] ces politiques, ingénieux
a mettre aux fictions profitables un masque de nécessité.»
 Victor Hugo : “Les misérables”, La pléiade, Gallimard, P. 843

   |\  _,,,---,,_
   /,`.-'`'-.  ;-;;,_
  |,4-  ) )-,_. ,\ (  `'-'
 '---''(_/--'  `-'\_)   πr

perl -e '$_=q#: 3|\ 5_,3-3,2_: 3/,`.'"'"'`'"'"' 5-.  ;-;;,_:  |,A-  ) )-,_. ,\ 
(  `'"'"'-'"'"': '"'"'-3'"'"'2(_/--'"'"'  `-'"'"'\_): 
24πr::#;y#:#\n#;s#(\D)(\d+)#$1x$2#ge;print'
- --> Ce message n’engage que son auteur <--



signature.asc
Description: Message signed with OpenPGP

fail2ban : sshd jail ne fonctionne pas (encore)

[fab]

salut la liste,

Soient 2 serveurs quasi-identiques sur stretch à jour. fail2ban
fonctionne correctement sur le serveur B mais pas sur le serveur A. Pour 
l'instant je n'ai paramétré qu'une seule prison sshd.



serveur A:
# cat defaults-debian.conf
[sshd]
port = 
enabled = true
maxretry = 2

serveur B:
# cat ../jail.local
[sshd]
port = 
enabled = true
maxretry = 2

Les /etc/ssh/ssd_confid des 2 serveurs sont identiques.

Serveur A et B:
# iptables -S
-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT
-N f2b-sshd
-A INPUT -p tcp -m multiport --dports  -j f2b-sshd
-A f2b-sshd -j RETURN


/var/log/fail2ban.log des Serveurs A et B sont identiques:

 Stopping all jails
 Jail 'sshd' stopped
 Exiting Fail2ban
 Changed logging target to /var/log/fail2ban.log for Fail2ban v0.9.6
 Connected to fail2ban persistent database
'/var/lib/fail2ban/fail2ban.sqlite3'
 Creating new jail 'sshd'
 Jail 'sshd' uses pyinotify {}
 Initiated 'pyinotify' backend
 Set jail log file encoding to UTF-8
 Set maxRetry = 2
 Added logfile = /var/log/auth.log
 Set findtime = 600
 Set banTime = 600
 Set maxlines = 10
 Jail sshd is not a JournalFilter instance
 Jail 'sshd' started

/etc/hosts.allow sur les 2 serveurs sont les même.

Bref, c'est tout pareil (à priori).

Quand je fais un ssh toto@serveurB: et que je rentre un mauvais mot
de passe, fail2ban me bannit: OK.

Dans le auth.log du serveur B, j'ai :
pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0
tty=ssh ruser= rhost=11.22.33.44  user=toto
Failed password for toto from 11.22.33.44 port 40664 ssh2

Quand je fais un ssh toto@serveurA: et que je rentre un mauvais mot
de passe, fail2ban ne me bannit pas et je n'ai rien dans fail2ban.log.

Dans le auth.log du serveur A, j'ai :
pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0
tty=ssh ruser= rhost=11.22.33.44  user=toto
Failed password for toto from 11.22.33.44 port 41342 ssh2
Failed password for toto from 11.22.33.44 port 41342 ssh2
Failed password for toto from 11.22.33.44 port 41342 ssh2
Connection closed by 11.22.33.44 port 41342 [preauth]
PAM 2 more authentication failures; logname= uid=0 euid=0 tty=ssh ruser=
rhost=11.22.33.44  user=toto

Tout se passe comme si je n'avais pas démarré fail2an sur le serveur A.

Si vous avez une piste ou une idée, une vanne ou un bon mot je prends!

merki,

f.

Re: buster VM does not always start sshd

[Jonas Smedegaard]

Quoting Darac Marjal (2019-05-05 21:13:50)
> 
> On 04/05/2019 19:18, Steve McIntyre wrote:
> > f...@deneb.enyo.de wrote:
> >> I've got a buster VM (upgraded from stretch) which does not launch
> >> sshd (and Unbound) until a login attempt happens on a TTY.  (An
> >> unsuccessful attempt appears to be enough.)
> >>
> >> At that point, both sshd and Unbound start successfully, and network
> >> login is possible.  I don't think I have changed the service
> >> configuration.  There is nothing unusual about the networking setup,
> >> except that it doesn't use DHCP, and there is a static stanza in
> >> /etc/network/interfaces, with a matching auto directive.
> > The most likely cause is lack of randomness at boot. Check your boot
> > messages for "crng init done". This is biting lots of people.
> >
> > If you're running a VM, look into how to share a random device from
> > the host.
> >
> If you can't manage that, consider whether `haveged` provides
> secure-enough entropy gathering for you.

Or the newer alternative jitterentropy-rngd.

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Re: buster VM does not always start sshd

[Darac Marjal]

On 04/05/2019 19:18, Steve McIntyre wrote:
> f...@deneb.enyo.de wrote:
>> I've got a buster VM (upgraded from stretch) which does not launch
>> sshd (and Unbound) until a login attempt happens on a TTY.  (An
>> unsuccessful attempt appears to be enough.)
>>
>> At that point, both sshd and Unbound start successfully, and network
>> login is possible.  I don't think I have changed the service
>> configuration.  There is nothing unusual about the networking setup,
>> except that it doesn't use DHCP, and there is a static stanza in
>> /etc/network/interfaces, with a matching auto directive.
> The most likely cause is lack of randomness at boot. Check your boot
> messages for "crng init done". This is biting lots of people.
>
> If you're running a VM, look into how to share a random device from
> the host.
>
If you can't manage that, consider whether `haveged` provides
secure-enough entropy gathering for you.

Re: buster VM does not always start sshd

[Florian Weimer]

* Steve McIntyre:

> f...@deneb.enyo.de wrote:
>>I've got a buster VM (upgraded from stretch) which does not launch
>>sshd (and Unbound) until a login attempt happens on a TTY.  (An
>>unsuccessful attempt appears to be enough.)
>>
>>At that point, both sshd and Unbound start successfully, and network
>>login is possible.  I don't think I have changed the service
>>configuration.  There is nothing unusual about the networking setup,
>>except that it doesn't use DHCP, and there is a static stanza in
>>/etc/network/interfaces, with a matching auto directive.
>
> The most likely cause is lack of randomness at boot. Check your boot
> messages for "crng init done". This is biting lots of people.
>
> If you're running a VM, look into how to share a random device from
> the host.

Thanks, that's it.  I knew about this problem in theory, but have
never seen it in action.  In my case, the VM had the wrong CPU model
configured (one without RDRAND).

Re: buster VM does not always start sshd

[Steve McIntyre]

f...@deneb.enyo.de wrote:
>I've got a buster VM (upgraded from stretch) which does not launch
>sshd (and Unbound) until a login attempt happens on a TTY.  (An
>unsuccessful attempt appears to be enough.)
>
>At that point, both sshd and Unbound start successfully, and network
>login is possible.  I don't think I have changed the service
>configuration.  There is nothing unusual about the networking setup,
>except that it doesn't use DHCP, and there is a static stanza in
>/etc/network/interfaces, with a matching auto directive.

The most likely cause is lack of randomness at boot. Check your boot
messages for "crng init done". This is biting lots of people.

If you're running a VM, look into how to share a random device from
the host.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
  Armed with "Valor": "Centurion" represents quality of Discipline,
  Honor, Integrity and Loyalty. Now you don't have to be a Caesar to
  concord the digital world while feeling safe and proud.

buster VM does not always start sshd

[Florian Weimer]

I've got a buster VM (upgraded from stretch) which does not launch
sshd (and Unbound) until a login attempt happens on a TTY.  (An
unsuccessful attempt appears to be enough.)

At that point, both sshd and Unbound start successfully, and network
login is possible.  I don't think I have changed the service
configuration.  There is nothing unusual about the networking setup,
except that it doesn't use DHCP, and there is a static stanza in
/etc/network/interfaces, with a matching auto directive.

● ssh.service - OpenBSD Secure Shell server
   Loaded: loaded (/lib/systemd/system/ssh.service; enabled; vendor preset: enab
   Active: active (running) since Sat 2019-05-04 17:47:31 UTC; 8min ago
 Docs: man:sshd(8)
   man:sshd_config(5)
  Process: 684 ExecStartPre=/usr/sbin/sshd -t (code=exited, status=0/SUCCESS)
 Main PID: 694 (sshd)
Tasks: 1 (limit: 1149)
   Memory: 3.1M
   CGroup: /system.slice/ssh.service
   └─694 /usr/sbin/sshd -D

May 04 17:46:20 storage1 systemd[1]: Starting OpenBSD Secure Shell server...
May 04 17:47:31 storage1 sshd[694]: Server listening on 0.0.0.0 port 22.
May 04 17:47:31 storage1 sshd[694]: Server listening on :: port 22.
May 04 17:47:31 storage1 systemd[1]: Started OpenBSD Secure Shell server.
May 04 17:48:04 storage1 sshd[708]: Accepted publickey for fw from 172.17.151.1 
May 04 17:48:04 storage1 sshd[708]: pam_unix(sshd:session): session opened for u

● unbound.service - Unbound DNS server
   Loaded: loaded (/lib/systemd/system/unbound.service; enabled; vendor preset: 
   Active: active (running) since Sat 2019-05-04 17:47:32 UTC; 9min ago
 Docs: man:unbound(8)
  Process: 683 ExecStartPre=/usr/lib/unbound/package-helper chroot_setup (code=e
  Process: 687 ExecStartPre=/usr/lib/unbound/package-helper root_trust_anchor_up
 Main PID: 695 (unbound)
Tasks: 1 (limit: 1149)
   Memory: 8.0M
   CGroup: /system.slice/unbound.service
   └─695 /usr/sbin/unbound -d

May 04 17:46:20 storage1 systemd[1]: Starting Unbound DNS server...
May 04 17:47:32 storage1 package-helper[687]: /var/lib/unbound/root.key has cont
May 04 17:47:32 storage1 package-helper[687]: success: the anchor is ok
May 04 17:47:32 storage1 unbound[695]: [695:0] notice: init module 0: subnet
May 04 17:47:32 storage1 unbound[695]: [695:0] notice: init module 1: validator
May 04 17:47:32 storage1 unbound[695]: [695:0] notice: init module 2: iterator
May 04 17:47:32 storage1 unbound[695]: [695:0] info: start of service (unbound 1
May 04 17:47:32 storage1 systemd[1]: Started Unbound DNS server.

As far as I can tell, the system reaches multi-user.target
successfully, at which point I expect that sshd.service can start as
well:

● multi-user.target - Multi-User System
   Loaded: loaded (/lib/systemd/system/multi-user.target; static; vendor preset:
   Active: active since Sat 2019-05-04 17:34:16 UTC; 22min ago
 Docs: man:systemd.special(7)

May 04 17:34:16 storage1 systemd[1]: Reached target Multi-User System.

Any suggestions how to debug this further?  I don't think this
happened with Debian stretch.

Re: SSH, sshd -d -p 2288

[Geert Stappers]

On Mon, Oct 22, 2018 at 05:03:42PM +0200, Bas Neve wrote:
> Op do 18 okt. 2018 om 17:50 schreef Paul van der Vlis :
> > Op 17-10-18 om 11:01 schreef Paul van der Vlis:
> > > Op 17-10-18 om 08:10 schreef Bas Neve:> Als ik met Putty verbinding maak
> > > met een remote host dan gaat dit
> > >> prima.  Als ik echter met ssh op een debian machine probeer in te loggen
> > >> op diezelde machine dan lukt dit niet. (..)
> > >
> > > Dit zijn best lastige problemen om te debuggen.
> > >
> > > Wat ik in zo'n geval doe, is sshd een tweede keer te starten op een
> > > andere poort (-p), met de debug optie (-d). Verder zelfde sshd_config.
> >
> > /usr/sbin/sshd -d -p 2288

Dat is wat er aan server kant klaar gezet wordt.
Dat is ook de plek waar de debug informatie komt.


> >
> > ssh -p 2288 u...@deserver.nl

Dat is wat je dan aan client kant doet.
Je maakt connectie naar de poort waar debug logging aanstaat.

(Verwacht aan client kant overigens gewoon de oorspronkelijke klacht)


> >
> 
> Helaas zie ik geen informatie in de logging waar ik mee verder kom.

En wat staat er dan wel in de logging?


Ik bedoel:
   Het kan wel zijn dat O.P. het niet ziet,
   maar dat is niet hetzelfde als dat er niets te zien is.


Groeten
Geert Stappers
-- 
Leven en laten leven

Re: sshd fails to start on boot

[john doe]

On 2/25/2018 9:52 PM, mick crane wrote:

hello,
on boot sshd seems to be starting before the network is ready so fails.
How/where do I tell it to start after network is up ?


$ systemctl enable systemd-networkd-wait-online

https://www.freedesktop.org/software/systemd/man/systemd-networkd-wait-online.service.html

--
John Doe

Re: sshd fails to start on boot

[Don Armstrong]

On Sun, 25 Feb 2018, mick crane wrote:
> on boot sshd seems to be starting before the network is ready so
> fails. How/where do I tell it to start after network is up ?
>
> debian testing (buster)

sshd starts after network.target, and listens on 0.0.0.0 and :: by
default, so unless you've modified it to listen on a specific address
which isn't yet up, it shouldn't matter.

Check out what journalctl -xe _SYSTEMD_UNIT=ssh.service; says to see why
it failed to start, and that should tell you what's actually going on.

-- 
Don Armstrong  https://www.donarmstrong.com

Good people are good because they've come to wisdom through failure.
We get very little wisdom from success, you know.
 -- William Saroyan _My Heart's in the Highlands_

sshd fails to start on boot

[mick crane]

hello,
on boot sshd seems to be starting before the network is ready so fails.
How/where do I tell it to start after network is up ?

debian testing (buster)

cheers

mick
--
Key ID  4BFEBB31

Re: sshd running in private namespace

[Nicolas George]

Sven Hartge (2018-01-18):
> This was https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=885325, fixed
> in systemd 236-3. It has migrated to Buster yesterday, so upgrading will
> fix it for you.

I was not expected such a tight race condition between when I checked
this and when I wrote the mail.

Thanks to both Sven for pointing it.

Regards,

-- 
  Nicolas George


signature.asc
Description: Digital signature

Re: sshd running in private namespace

[Sven Joachim]

On 2018-01-18 15:57 +0100, Nicolas George wrote:

> David Wright (2018-01-18):
>> I can't replicate this on stretch. What versions of what are
>> you running?
>
> Sorry, I should have mentioned it: it's Buster, up-to-date by a few
> days.
>
>> Could you give some explicit commands, and where to type them.
>
> ssh box
> mkdir /tmp/dummy
> sudo mount -t tmpfs dummy /tmp/dummy
> dmesg > /tmp/dummy/something
>
> log-in in console
> ls /tmp/dummy
>
> Result: file "something" is not there.

That's bug #885325[1] in systemd, time to upgrade and restart ssh if
necessary.

Cheers,
   Sven


1. https://bugs.debian.org/885325

Re: sshd running in private namespace

[Sven Hartge]

Nicolas George <geo...@nsup.org> wrote:

> I noticed that for some time, sshd is being started in a separate
> filesystem namespace. As a consequence, mounts done from a SSH shell are
> not visible from the main system, and that disrupts my use habits.

This was https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=885325, fixed
in systemd 236-3. It has migrated to Buster yesterday, so upgrading will
fix it for you.

Grüße,
Sven.
-- 
Sigmentation fault. Core dumped.

Re: sshd running in private namespace

[Nicolas George]

David Wright (2018-01-18):
> I can't replicate this on stretch. What versions of what are
> you running?

Sorry, I should have mentioned it: it's Buster, up-to-date by a few
days.

> Could you give some explicit commands, and where to type them.

ssh box
mkdir /tmp/dummy
sudo mount -t tmpfs dummy /tmp/dummy
dmesg > /tmp/dummy/something

log-in in console
ls /tmp/dummy

Result: file "something" is not there.

Regards,

-- 
  Nicolas George


signature.asc
Description: Digital signature

Re: sshd running in private namespace

[David Wright]

On Thu 18 Jan 2018 at 14:59:34 (+0100), Nicolas George wrote:
> Hi.
> 
> I noticed that for some time, sshd is being started in a separate
> filesystem namespace. As a consequence, mounts done from a SSH shell are
> not visible from the main system, and that disrupts my use habits.
> 
> Is it on purpose?
> 
> I have tracked things in the source code to exec_needs_mount_namespace()
> in systemd/src/core/execute.c, but I do not see which condition is true
> for sshd, AFAICS they are all false.
> 
> Have anyone investigated the issue already?

I can't replicate this on stretch. What versions of what are
you running?

Could you give some explicit commands, and where to type them.

Cheers,
David.

sshd running in private namespace

[Nicolas George]

Hi.

I noticed that for some time, sshd is being started in a separate
filesystem namespace. As a consequence, mounts done from a SSH shell are
not visible from the main system, and that disrupts my use habits.

Is it on purpose?

I have tracked things in the source code to exec_needs_mount_namespace()
in systemd/src/core/execute.c, but I do not see which condition is true
for sshd, AFAICS they are all false.

Have anyone investigated the issue already?

Regards,

-- 
  Nicolas George


signature.asc
Description: Digital signature

Re: New Deb 8 and no sshd access from other hosts

[David Wright]

On Wed 30 Mar 2016 at 07:02:46 (-0500), Tom Browder wrote:
> On Saturday, March 26, 2016, David Wright  wrote:
> >
> > A bit early for [SOLVED], I think.
> 
> I respectively disagree, David.

Correct me if I'm wrong, but I make the assumption that putting
[SOLVED] in the subject line is so that people searching for



will find such a tagged post and be able to follow the method therein
to potentially fix their problem.

> > On Sat 26 Mar 2016 at 12:08:37 (-0500), Tom Browder wrote:
> > > On Fri, Mar 25, 2016 at 12:12 PM, Tom Browder  
> > > wrote:
> > > > I have installed Deb on my laptop and reused my old Deb 7 .ssh 
> > > > directory.
> ...
> >
> > Not such a wonderful resource if it is so easily misunderstood. The
> > idea is to fix the permissions, not make your installation less secure.
> 
> I agree.

But it's the first step on your solution post. It would be usual to
edit out false trails and red herrings from a solution.

> > > Base on the comments from jvp, I looked closer at my home directory on
> > > the laptop and, sure enough, the permissions were too loose (first I
> ...

In the snipped section, you would have people set their home directory
permissions to 0700. Debian by default sets them to 0755, which others
might be unwittingly relying on.

> > > Then, in the upper widow, I saw the problem.  Directory '/usr/local',
> > > under which my .ssh directory is actually located, was reported to
> > > have bad permissions:
> > >
> > >   Authentication refused: bad ownership or modes for directory /usr/local
> ...> >
> > >  I checked and they were, surprisingly:
> > >
> > >   # ls -ld /usr/local
> > >   drwxrwsr-x 31 root staff 4096 Mar 24 07:37 /usr/local
> > >
> > > I don't know how that happened, but it must have happened during the
> > > upgrade two days ago when I continued to use my original partition
> > > mounted as '/usr/local' which was not supposed to have been touched.
> ...

If this was a Debian installation, one would expect the ownerships and
permissions as posted.

> > I don't know what happened long before that! When did /usr/local
> > become your home directory?
> 
> See below.
> 
> > > Anyway, as root, I fixed the permissions back to what I think is correct:
> > >
> > >   # chmod 00755 /usr/local
> > >   # ls -ld /usr/local
> > >   drwxr-xr-x 31 root staff 4096 Mar 24 07:37 /usr/local
> >
> > So now the system is degraded a bit more. The correct permissions, in
> > fact the entire contents, are:
> ...
> 
> Who says those permissions are correct? I checked the file system
> standard which says that /usr/local is optional. I provide my own
> /usr/local partion which I save when reinstalling a new OS and see no
> reason to provide setuid or setgid for it.

The last paragraph of section 9.1.2 Site-specific programs in the
Debian Policy Manual.

> When I first started
> administering Unix systems on SGI in 1993, the user home directories
> were in /usr/local/people and I kept using that as I transitioned the
> hosts under my control to Linux systems in 1994.

That is very historical. While you're free to configure your system
any way you choose, it's not sensible to suggest that others should
do this by tagging your post [SOLVED]. AFAICT Linux has never used
/usr/local/ in that way.

> Over the years on my own systems I have found it convenient to keep
> home system resource directories and files (.bashrc, .profile,
> .bash_aliase, .xemacs, .ssh, etc.) in a version-controlled, personal
> directory under /usr/local. I then soft link those back to whatever
> the newly installed system sets as my home directory. It has worked
> fine until the Debian 8 install set the permissions as noted which
> interfered with strict ssh.

Again, you're free to configure your system any way you choose.
However, /usr should effectively be readonly software with, possibly,
configuration files, whereas your .ssh/ directory is not readonly;
for example, known_hosts and authorized_keys get modified on the fly.
So your way of fixing your problem is not a general solution for
anyone because most of the post concerns your highly individually
configured system. That's what made me unhappy about your [SOLVED]
tag. I hope you'll understand.

Cheers,
David.

Re: New Deb 8 and no sshd access from other hosts

[Tom Browder]

On Saturday, March 26, 2016, David Wright  wrote:
>
> A bit early for [SOLVED], I think.

I respectively disagree, David.

> On Sat 26 Mar 2016 at 12:08:37 (-0500), Tom Browder wrote:
> > On Fri, Mar 25, 2016 at 12:12 PM, Tom Browder  wrote:
> > > I have installed Deb on my laptop and reused my old Deb 7 .ssh directory.
...
>
> Not such a wonderful resource if it is so easily misunderstood. The
> idea is to fix the permissions, not make your installation less secure.

I agree.

> > Base on the comments from jvp, I looked closer at my home directory on
> > the laptop and, sure enough, the permissions were too loose (first I
...
> > Then, in the upper widow, I saw the problem.  Directory '/usr/local',
> > under which my .ssh directory is actually located, was reported to
> > have bad permissions:
> >
> >   Authentication refused: bad ownership or modes for directory /usr/local
...> >
> >  I checked and they were, surprisingly:
> >
> >   # ls -ld /usr/local
> >   drwxrwsr-x 31 root staff 4096 Mar 24 07:37 /usr/local
> >
> > I don't know how that happened, but it must have happened during the
> > upgrade two days ago when I continued to use my original partition
> > mounted as '/usr/local' which was not supposed to have been touched.
...
> I don't know what happened long before that! When did /usr/local
> become your home directory?

See below.

> > Anyway, as root, I fixed the permissions back to what I think is correct:
> >
> >   # chmod 00755 /usr/local
> >   # ls -ld /usr/local
> >   drwxr-xr-x 31 root staff 4096 Mar 24 07:37 /usr/local
>
> So now the system is degraded a bit more. The correct permissions, in
> fact the entire contents, are:
...

Who says those permissions are correct? I checked the file system
standard which says that /usr/local is optional. I provide my own
/usr/local partion which I save when reinstalling a new OS and see no
reason to provide setuid or setgid for it. When I first started
administering Unix systems on SGI in 1993, the user home directories
were in /usr/local/people and I kept using that as I transitioned the
hosts under my control to Linux systems in 1994.

Over the years on my own systems I have found it convenient to keep
home system resource directories and files (.bashrc, .profile,
.bash_aliase, .xemacs, .ssh, etc.) in a version-controlled, personal
directory under /usr/local. I then soft link those back to whatever
the newly installed system sets as my home directory. It has worked
fine until the Debian 8 install set the permissions as noted which
interfered with strict ssh.

Anyway, all is well now.

Thanks, David.

Best regards,

-Tom

Re: New Deb 8 and no sshd access from other hosts [SOLVED]

[Andrew McGlashan]

Hi,

On 27/03/2016 10:04 AM, Tom Browder wrote:
> On Saturday, March 26, 2016, Andrew McGlashan
> I usually restrict with known IP addresses (static ones) and sometimes
> with users having to be in a specific group that allows ssh.  Also,
> authorized keys enforced instead of passwords.
> 
> At the moment I'm the sole user, although I'm considering giving limited
> access to a few folks later.  How do you manage the server while
> traveling--some kind of personal VPN?

I have access to a couple of servers via a secure RDP tool [1] that I
can work from, those servers have a static IP and those IPs are in my
allowed list.  Firewall's stop access unless it isn't coming from the
right locations and I also implement hosts.deny and hosts.allow in the mix.

I used to have a static IP HSPA service, I should have kept that as it
gives static IP on a 4G LTE network (actually I think it was only a 3G
network).  In the past I have rebuilt an Oracle database from export
dump files via a Nokia 9000 Communicator's terminal app with a 9600 baud
GSM modem who say's Apple were first to /real/ smart phones ;-)

Have considered port knocking, but never set that up.

There are lots of options I can work with, even an email to my own mail
server, specially crafted to run a script to open up the connecting IP.

Another option would be to setup OpenVPN that shouldn't be too hard,
but I haven't had to do it, yet.

So, right now, it is more simple with the AADS servers being available.

Kind Regards
AndrewM

[1] http://aads-worldwide.com/





signature.asc
Description: OpenPGP digital signature

Re: New Deb 8 and no sshd access from other hosts [SOLVED]

[Tom Browder]

On Saturday, March 26, 2016, Andrew McGlashan <
andrew.mcglas...@affinityvision.com.au
>
wrote:
>
> On 27/03/2016 4:08 AM, Tom Browder wrote:
> > On Fri, Mar 25, 2016 at 12:12 PM, Tom Browder 
> wrote:

...

> > I found this wonderful resource:
> >
> >   http://www.unixlore.net/articles/troubleshooting-ssh-connections.html
>
> That was a JIT find (just in time) only written up 26th March, 2016.


JIT, indeed!  I hadn't noticed the date!  I give my thanks to the
author(s). (I haven't found any attribution there yet.)


> Once you have everything good, make sure that you change StrictModes
> back to default.


Thanks, Andrew. I did but forgot to say so.


> I usually restrict with known IP addresses (static ones) and sometimes
> with users having to be in a specific group that allows ssh.  Also,
> authorized keys enforced instead of passwords.


At the moment I'm the sole user, although I'm considering giving limited
access to a few folks later.  How do you manage the server while
traveling--some kind of personal VPN?

Best regards,

-Tom

Re: New Deb 8 and no sshd access from other hosts [SOLVED]

[Andrew McGlashan]

On 27/03/2016 4:08 AM, Tom Browder wrote:
> On Fri, Mar 25, 2016 at 12:12 PM, Tom Browder  wrote:
>> I have installed Deb on my laptop and reused my old Deb 7 .ssh directory.
>>
>> I can now ssh into the existing remote servers but cannot ssh into my
>> laptop from them (as a normal user)--I always get asked for a
>> password.  So the remote servers recognize my old Deb 7 keys, but
>> apparently my laptop doesn't recognize the other servers' keys.
> ...
> 
> I found this wonderful resource:
> 
>   http://www.unixlore.net/articles/troubleshooting-ssh-connections.html

That was a JIT find (just in time) only written up 26th March, 2016.

Once you have everything good, make sure that you change StrictModes
back to default.

I usually restrict with known IP addresses (static ones) and sometimes
with users having to be in a specific group that allows ssh.  Also,
authorized keys enforced instead of passwords.

Cheers
A.



signature.asc
Description: OpenPGP digital signature

Re: New Deb 8 and no sshd access from other hosts

[David Wright]

A bit early for [SOLVED], I think.

On Sat 26 Mar 2016 at 12:08:37 (-0500), Tom Browder wrote:
> On Fri, Mar 25, 2016 at 12:12 PM, Tom Browder  wrote:
> > I have installed Deb on my laptop and reused my old Deb 7 .ssh directory.
> >
> > I can now ssh into the existing remote servers but cannot ssh into my
> > laptop from them (as a normal user)--I always get asked for a
> > password.  So the remote servers recognize my old Deb 7 keys, but
> > apparently my laptop doesn't recognize the other servers' keys.
> ...
> I found this wonderful resource:
>   http://www.unixlore.net/articles/troubleshooting-ssh-connections.html
> which helped me solve the problem.
> 
> First, in file '/etc/ssh/sshd_config', I changed the line
>   StrictModes yes
> to this
>   StrictModes no
> and restarted the ssh server.  As root:
>   # invoke-rc.d ssh restart
> Then I attempted the ssh login and it worked!

Not such a wonderful resource if it is so easily misunderstood. The
idea is to fix the permissions, not make your installation less secure.

> Base on the comments from jvp, I looked closer at my home directory on
> the laptop and, sure enough, the permissions were too loose (first I
> have ever heard of that, but then again I haven't looked at 'man ssh'
> in many years).  Note that I have for all the years after ssh came
> along been setting the .ssh permissions correctly, but I've never run
> into a problem with the home directory.  In fact, when I was working
> at our office on site (up until the end of 2008), we commonly allowed
> read access between user directories but ssh still worked.
> 
> But after setting the home directory permissions to 00700 and
> restarting ssh, the login still didn't work!

[...]

> Then, in the upper widow, I saw the problem.  Directory '/usr/local',
> under which my .ssh directory is actually located, was reported to
> have bad permissions:
> 
>   Authentication refused: bad ownership or modes for directory /usr/local
> 
>  I checked and they were, surprisingly:
> 
>   # ls -ld /usr/local
>   drwxrwsr-x 31 root staff 4096 Mar 24 07:37 /usr/local
> 
> I don't know how that happened, but it must have happened during the
> upgrade two days ago when I continued to use my original partition
> mounted as '/usr/local' which was not supposed to have been touched.

I don't know what happened long before that! When did /usr/local
become your home directory?

> Anyway, as root, I fixed the permissions back to what I think is correct:
> 
>   # chmod 00755 /usr/local
>   # ls -ld /usr/local
>   drwxr-xr-x 31 root staff 4096 Mar 24 07:37 /usr/local

So now the system is degraded a bit more. The correct permissions, in
fact the entire contents, are:

$ ls -l /usr/
drwxr-xr-x   2 root root  81920 Mar 26 00:59 bin
drwxr-xr-x   2 root root   4096 Apr 26  2015 games
drwxr-xr-x  39 root root  16384 Feb 16 16:55 include
drwxr-xr-x 156 root root  36864 Mar 14 07:16 lib
drwxrwsr-x  10 root staff  4096 Oct 10  2012 local
drwxr-xr-x   2 root root  12288 Mar 14 07:16 sbin
drwxr-xr-x 319 root root  12288 Jan 20 19:22 share
drwxr-xr-x   6 root root   4096 Mar  4 00:39 src
$ ls -l /usr/local/
drwxrwsr-x  2 root staff 4096 Oct 10  2012 bin
drwxrwsr-x  2 root staff 4096 Oct 10  2012 etc
drwxrwsr-x  2 root staff 4096 Oct 10  2012 games
drwxrwsr-x  2 root staff 4096 Oct 10  2012 include
drwxrwsr-x  4 root staff 4096 Dec 15  2014 lib
lrwxrwxrwx  1 root staff9 Oct 10  2012 man -> share/man
drwxrwsr-x  2 root staff 4096 Oct 10  2012 sbin
drwxrwsr-x 10 root staff 4096 Aug 21  2015 share
drwxrwsr-x  2 root staff 4096 Oct 10  2012 src
$

So is this really the case as you said it was earlier:
$ ls -l ~/.ssh/authorized_keys
-rw--- 1 yourname yourname 3136 Jul 28  2015 
/home/yourname/.ssh/authorized_keys
$ grep yourname /etc/passwd
yourname:x:1000:1000:Your Name,,,:/home/yourname:/bin/bash
$

Cheers,
David.

Re: New Deb 8 and no sshd access from other hosts [SOLVED]

[Tom Browder]

On Fri, Mar 25, 2016 at 12:12 PM, Tom Browder <tom.brow...@gmail.com> wrote:
> I have installed Deb on my laptop and reused my old Deb 7 .ssh directory.
>
> I can now ssh into the existing remote servers but cannot ssh into my
> laptop from them (as a normal user)--I always get asked for a
> password.  So the remote servers recognize my old Deb 7 keys, but
> apparently my laptop doesn't recognize the other servers' keys.
...

I found this wonderful resource:

  http://www.unixlore.net/articles/troubleshooting-ssh-connections.html

which helped me solve the problem.

First, in file '/etc/ssh/sshd_config', I changed the line

  StrictModes yes

to this

  StrictModes no

and restarted the ssh server.  As root:

  # invoke-rc.d ssh restart

Then I attempted the ssh login and it worked!

Base on the comments from jvp, I looked closer at my home directory on
the laptop and, sure enough, the permissions were too loose (first I
have ever heard of that, but then again I haven't looked at 'man ssh'
in many years).  Note that I have for all the years after ssh came
along been setting the .ssh permissions correctly, but I've never run
into a problem with the home directory.  In fact, when I was working
at our office on site (up until the end of 2008), we commonly allowed
read access between user directories but ssh still worked.

But after setting the home directory permissions to 00700 and
restarting ssh, the login still didn't work!

Then I looked at the resource page where it showed how to debug the
whole ssh login session.  I used two terminal windows stacked one
above the other.  In the top window, on the laptop (local host) I
became root and executed the following:

  # /usr/sbin/sshd -d -p 

and in the lower window I logged into the remote host and, as my
normal user self, executed the following:

  $ ssh -vv -p  jv2

where 'jv2' is the host name of my laptop.

Then, in the upper widow, I saw the problem.  Directory '/usr/local',
under which my .ssh directory is actually located, was reported to
have bad permissions:

  Authentication refused: bad ownership or modes for directory /usr/local

 I checked and they were, surprisingly:

  # ls -ld /usr/local
  drwxrwsr-x 31 root staff 4096 Mar 24 07:37 /usr/local

I don't know how that happened, but it must have happened during the
upgrade two days ago when I continued to use my original partition
mounted as '/usr/local' which was not supposed to have been touched.

Anyway, as root, I fixed the permissions back to what I think is correct:

  # chmod 00755 /usr/local
  # ls -ld /usr/local
  drwxr-xr-x 31 root staff 4096 Mar 24 07:37 /usr/local

restarted the ssh server, and the login worked as advertised--whew!

Thanks to all who offered help.

Best regards,

-Tom

Re: New Deb 8 and no sshd access from other hosts

[Tom Browder]

On Fri, Mar 25, 2016 at 12:33 PM, Jörg-Volker Peetz  wrote:
> I'd first check file permissions in your .ssh directory (see man ssh).
> If they are o.k.,  I'd call ssh with one or more -v switches.

On, duh, forgot about the '-v' option--I'll work with that and report back.

Thanks, jvp!

-Tom

Re: New Deb 8 and no sshd access from other hosts

[Tom Browder]

On Fri, Mar 25, 2016 at 12:38 PM, David Wright  wrote:
> On Fri 25 Mar 2016 at 12:12:44 (-0500), Tom Browder wrote:
>> I have installed Deb on my laptop and reused my old Deb 7 .ssh directory.
>>
>> I can now ssh into the existing remote servers but cannot ssh into my
>> laptop from them (as a normal user)--I always get asked for a
>> password.  So the remote servers recognize my old Deb 7 keys, but
>> apparently my laptop doesn't recognize the other servers' keys.
...
>> Can anyone suggest where to look next?
>
> What you lost on your laptop is ~/.ssh/authorized_keys which would
> have had the public keys from your ~/.ssh/ on each of the remote hosts.

No, the authorized_keys are still there.

Thanks.

-Tom

Re: New Deb 8 and no sshd access from other hosts

[David Wright]

On Fri 25 Mar 2016 at 12:12:44 (-0500), Tom Browder wrote:
> I have installed Deb on my laptop and reused my old Deb 7 .ssh directory.
> 
> I can now ssh into the existing remote servers but cannot ssh into my
> laptop from them (as a normal user)--I always get asked for a
> password.  So the remote servers recognize my old Deb 7 keys, but
> apparently my laptop doesn't recognize the other servers' keys.
> 
> I have compared files:
> 
>   /etc/ssh/ssh_conf
>   /etc/ssh/sshd_conf
>   /etc/pam.d/ssh/sshd
> 
> between the laptop and the remote server and can see no significant
> difference for a normal user.
> 
> I can also see the host names in the .ssh/known_hosts file.  I do see
> that my laptop host's entries in the remote host's known_hosts are of
> type "EDCSA" while the remote host's entries in the laptop's
> known_hosts file are of type "RSA."
> 
> Can anyone suggest where to look next?

What you lost on your laptop is ~/.ssh/authorized_keys which would
have had the public keys from your ~/.ssh/ on each of the remote hosts.
You can write them back by typing
$ ssh-copy-id -i ~/.ssh/id_rsa.pub your-user-name@laptop
on each of the remote servers in turn.

Now, when you-on-the-remote-host try to contact the laptop with ssh,
the laptop will use the public key (that you just copied) to ascertain
that you-on-the-remote-host know the private key of the pair, and let
you in.

Cheers,
David.

Re: New Deb 8 and no sshd access from other hosts

[Jörg-Volker Peetz]

I'd first check file permissions in your .ssh directory (see man ssh).
If they are o.k.,  I'd call ssh with one or more -v switches.

Regards,
jvp.

Re: New Deb 8 and no sshd access from other hosts

[Tom Browder]

On Fri, Mar 25, 2016 at 12:12 PM, Tom Browder  wrote:
> I have installed Deb on my laptop and reused my old Deb 7 .ssh directory.
...
> that my laptop host's entries in the remote host's known_hosts are of
> type "EDCSA" while the remote host's entries in the laptop's

That should have been "ECDSA."

New Deb 8 and no sshd access from other hosts

[Tom Browder]

I have installed Deb on my laptop and reused my old Deb 7 .ssh directory.

I can now ssh into the existing remote servers but cannot ssh into my
laptop from them (as a normal user)--I always get asked for a
password.  So the remote servers recognize my old Deb 7 keys, but
apparently my laptop doesn't recognize the other servers' keys.

I have compared files:

  /etc/ssh/ssh_conf
  /etc/ssh/sshd_conf
  /etc/pam.d/ssh/sshd

between the laptop and the remote server and can see no significant
difference for a normal user.

I can also see the host names in the .ssh/known_hosts file.  I do see
that my laptop host's entries in the remote host's known_hosts are of
type "EDCSA" while the remote host's entries in the laptop's
known_hosts file are of type "RSA."

Can anyone suggest where to look next?

Thanks.

Best regards,

-Tom

Re: chroot directory, and sshd

[Ron Leach]

On 10/03/2016 21:41, Sven Hartge wrote:

Ron Leach<ronle...@tesco.net>  wrote:


I haven't been able to find
out how to check the permissions on "/", and I'd appreciate a
suggestion how to do that

# ls -ld /
drwxr-xr-x 29 root root 4096 Mar 10 13:07 /



Sven, tks.  I'd used "ls -lg /" but that didn't list "/".

Checked now, and fixed.  For the topic, sshd was - indeed - 
complaining about permissions on "/" not being 755.


Ron

Re: chroot directory, and sshd

[Sven Hartge]

Ron Leach <ronle...@tesco.net> wrote:

> I note that the auth failure does seem to suggest there is something 
> wrong with permissions for "/" itself.  I haven't been able to find 
> out how to check the permissions on "/", and I'd appreciate a 
> suggestion how to do that if - as it seems - that might be what sshd 
> is complaining about.

# ls -ld /
drwxr-xr-x 29 root root 4096 Mar 10 13:07 /

# stat /
  File: '/'
  Size: 4096Blocks: 8  IO Block: 4096   directory
Device: 902h/2306d  Inode: 2   Links: 29
Access: (0755/drwxr-xr-x)  Uid: (0/root)   Gid: (0/root)
Access: 2016-03-10 13:07:10.147435719 +0100
Modify: 2016-03-10 13:07:03.471293214 +0100
Change: 2016-03-10 13:07:03.471293214 +0100
 Birth: -


Grüße,
Sven.
-- 
Sigmentation fault. Core dumped.

chroot directory, and sshd

[Ron Leach]

List, good evening,

AIUI, sshd requires that a chroot directory, and all directories above 
it, including "/", must be owned by root, and not be writable except 
by root.  '755' permissions.


While trying to set up an sftp-only service, and using this stanza in 
/etc/ssh/sshd_config :


Match Group sftp_users
  X11Forwarding no
  AllowTcpForwarding no
  ChrootDirectory /home/sftp
  ForceCommand internal-sftp

sftp login attempts fail after password entry, and
/var/log/auth.log shows :

bad ownership or modes for chroot directory component "/"

I've rechecked ownership and access settings for
/home
/home/sftp
and both these are owned by root, and writable only by root as owner 
(755).


I note that the auth failure does seem to suggest there is something 
wrong with permissions for "/" itself.  I haven't been able to find 
out how to check the permissions on "/", and I'd appreciate a 
suggestion how to do that if - as it seems - that might be what sshd 
is complaining about.


If that isn't the problem, I'm not sure what else could be.  The 
directories below /home/sftp, such as

/home/sftp/mary
are owned by and writable by user mary.  mary is also in the group 
'sftp-users'.


OS is Wheezy, and ssh updates are applied.

I'd be very grateful for any insights,

regards, Ron

Re: pam_tally2 with sshd

[Nicholas Geovanis]

Thanks. My failure was putting the pam_tally2 module *after* the "@include
common-auth" instead of before it. The only working example I have at hand
is a RedHat 5.10 system where pam_tally (not pam_tally2) follows the whole
"system-auth" stack, rather than precedes it. Thanks again.Nick

On Tue, Feb 23, 2016 at 3:26 PM, Reco <recovery...@gmail.com> wrote:

> Hi.
>
> On Tue, 23 Feb 2016 14:52:59 -0600
> Nicholas Geovanis <nickgeova...@gmail.com> wrote:
>
> > Debian 8 jessie.
> > The goal is to block SSH logins with multiple incorrect password tries.
> > I've added these lines to my /etc/pam.d/sshd file:
> >
> > authoptionalpam_echo.so Before sshd pam_tally
> > authrequiredpam_tally2.so file=/var/log/tallylog deny=3 audit
> > onerr=fail
> > authoptionalpam_echo.so After sshd pam_tally
> >
> > I receive the pam_echo lines OK. But no matter what, failed passwords
> never
> > increment the pam_tally2 failure count. "UsePAM yes" is specified in
> > /etc/ssh/sshd_config. This must be the wrong location for pam_tally2.so
> but
> > experiments haven't helped me find the right location. Has someone a
> > working configuration they would share? Many thanks....Nick
>
> A typical run-of-the-mill Jessie system here.
> I just put your pam_tally2 configuration (I skipped pam_echo though)
> into /etc/pam.d/sshd *before* the '@include common-auth' line.
> Created /var/log/tallylog file.
> Tested it with 'ssh -o PreferredAuthentications=password '.
>
> Everything worked as expected - i.e. PAM module
> filled /var/log/tallylog with own blob, and /sbin/pam_tally2 shows
> failed login counter increments.
>
> Reco
>
>