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

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

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

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

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

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

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

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

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

ages 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

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

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

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

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

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

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

Re: Bookworm, fail2ban and sshd

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

Re: Bookworm, fail2ban and sshd

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

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 foun

Re: Bookworm, fail2ban and sshd

md (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 signatur

Re: Bookworm, fail2ban and sshd

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

Bookworm, fail2ban and sshd

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

Re: sshd Match regel

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

Opgelost (maar heel anders) Re: sshd Match regel

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

Re: sshd Match regel

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

Re: sshd Match regel

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

Re: sshd Match regel

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

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.

Re: sshd Match regel

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

sshd Match regel

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

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

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

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

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,

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

ome 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

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

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

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

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 s

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

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

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

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

Re: sshd package systemd misconfiguration?

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

Re: sshd package systemd misconfiguration?

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

Re: sshd package systemd misconfiguration?

upposed 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$ gr

Re: sshd package systemd misconfiguration?

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

Re: sshd package systemd misconfiguration?

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

Re: sshd package systemd misconfiguration?

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

Re: sshd package systemd misconfiguration?

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

Re: sshd package systemd misconfiguration?

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

sshd package systemd misconfiguration?

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

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

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

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

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

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

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

Re: considering a new system and a sshd hybrid drive

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

Re: considering a new system and a sshd hybrid drive

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:

Re: considering a new system and a sshd hybrid drive

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

Re: considering a new system and a sshd hybrid drive

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

Re: considering a new system and a sshd hybrid drive

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.

Re: considering a new system and a sshd hybrid drive

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

Re: considering a new system and a sshd hybrid drive

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

Re: considering a new system and a sshd hybrid drive

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 >

Re: considering a new system and a sshd hybrid drive

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)

Re: considering a new system and a sshd hybrid drive

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

considering a new system and a sshd hybrid drive

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

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

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

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

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.

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

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

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

art 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

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

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

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

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

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

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

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

nit 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

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

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

Address 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) on

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

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

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)

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

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

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: > # ca

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

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

fail2ban : sshd jail ne fonctionne pas (encore)

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

Re: buster VM does not always start sshd

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 >

Re: buster VM does not always start sshd

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

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 ss

Re: buster VM does not always start sshd

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

buster VM does not always start sshd

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

Re: SSH, sshd -d -p 2288

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

Re: sshd fails to start on boot

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

Re: sshd fails to start on boot

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 u

sshd fails to start on boot

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

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.

Re: sshd running in private namespace

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

Re: sshd running in private namespace

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

Re: sshd running in private namespace

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

Re: sshd running in private namespace

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 disrupt

sshd running in private namespace

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

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

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

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

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

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

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

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

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:

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

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

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

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

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

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 hos

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

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,

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

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

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

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

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

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

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

New Deb 8 and no sshd access from other hosts

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

Re: chroot directory, and sshd

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

estion 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

chroot directory, and sshd

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

Re: pam_tally2 with sshd

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

  1   2   3   4   5   6   7   8   9   >