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
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
eb12u2
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-
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
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
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 "pub
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 $pubkey
/.../.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
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" pai
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
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: Hav
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 sig
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 wan
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 e
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
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, pr
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
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
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
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 s
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 norm
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
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,
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/syste
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
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
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.
--
Jonatha
icorn:/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 miss
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]:
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
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:
> &g
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
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
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
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 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,
>
>
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 wa
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.
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 u
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 t
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
> pr
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)
me
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
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 ha
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
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
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/inter
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
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]:
d 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.
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
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-
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
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 instructi
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
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
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
&
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.)
>>
* 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
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
&g
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 c
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
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
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
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.
T
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 typ
Nicolas George 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/bugrepor
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 /
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
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
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 peo
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
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.
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/troubleshoo
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 alwa
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
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
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
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 norm
ssword. 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 remot
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.
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.
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.
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
Ron Leach 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
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/s
s again.Nick
On Tue, Feb 23, 2016 at 3:26 PM, Reco wrote:
> Hi.
>
> On Tue, 23 Feb 2016 14:52:59 -0600
> Nicholas Geovanis wrote:
>
> > Debian 8 jessie.
> > The goal is to block SSH logins with multiple incorrect password tries.
> > I've
Hi.
On Tue, 23 Feb 2016 14:52:59 -0600
Nicholas Geovanis 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:
>
> authoptional pam_echo.so Before s
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
t /etc/ssh/sshd_config because other
changes to the file are read.
To be sure, as you can see at my last e-mail, I passed the -f command line
option to run sshd.
The DenyUsers option is not working as well. I tried it with user1 and it
does not block the user.
Below follow my /etc/pam.d/sshd, if yo
On Wed, 2015-11-11 at 20:20 -0200, Paulo Roberto wrote:
> The option AllowUsers of /etc/ssh/sshd_config stopped working.
I did a small check, and it still works here, as expected... anything
special with your PAM? Are you sure that you checked on the right hosts
with the right sshd_config in place?
On Thu, Nov 12, 2015 at 07:25:49PM +0900, Joel Rees wrote:
> 2015/11/12 7:20 "Paulo Roberto" :
> >
> > Dear list,
> >
> > I need some help.
> >
> >
> > After upgrading the openssh-server package to the version:
> >
> > ii openssh-server1:6.9p1-2+b1
> amd64 secur
ed as expected.
>
> OpenSSH_6.7, LibreSSL 2.0
>
> Could it be a BUG?
>
> Below follow the sshd debug and my /etc/ssh/sshd_config
>
> Thanks in advance for your time and help.
>
>
> # /usr/sbin/sshd -D -f /etc/ssh/sshd_config -d
> debug1: sshd v
.
Any user can log through ssh even not present in this option.
Before the upgrade everything worked fine.
I tested the same sshd_config file in my OpenBSD box and there everything
worked as expected.
OpenSSH_6.7, LibreSSL 2.0
Could it be a BUG?
Below follow the sshd debug and my /etc/ssh
On Fri, Dec 19, 2014 at 11:01:28PM -0700, Bob Proulx wrote:
> Chris Bannister wrote:
> > What about:
> >
> > sudo /etc/init.d/ssh -vvv restart
>
> Sorry but the /etc/init.d/ssh doesn't take any -v options.
Arrrghhh! of course, what was I thinking. :(
--
"If you're not careful, the newspap
Very little is logged to the screen.
> > ,
> > |harry > sudo /etc/init.d/ssh restart
> > | Restarting ssh (via systemctl): ssh.service
> > `
> >
> > Can I get more verbose output?
The sshd is a system daemon. Look for information in the system
On Thu, Dec 18, 2014 at 12:13:47PM -0500, Harry Putnam wrote:
> Setup: very new install of gentoo
>
> When I restart ssh like so:
>
>sudo /etc/init.d/ssh restart
>
> I see very little output. Should it be more verbose?
>
> ,
> |harry > sudo /etc/init.d/ssh restart
> | Restarting s
ice
`
Can I get more verbose output?
I have no idea. Anyway, if you really want to know if ssh really
restarted, I guess the easier is this:
PID1=$(echo $(ps -A |grep sshd)|cut -f1 -d' ')
service ssh restart
[ $PID1 == $(echo $(ps -A |grep sshd)|cut -f1 -d' ') ] &&
On Thu Dec 18, 2014 at 12:13:47 -0500, Harry Putnam wrote:
> Setup: very new install of gentoo
I suggest you ask for assistance on the gentoo mailing lists
in the future.
> I see very little output. Should it be more verbose?
No.
> Can I get more verbose output?
Yes.
systemctl statu
Harry Putnam writes:
> Setup: very new install of gentoo
TYPE ALERT:
Setup: not so new install of debian (jessie)
>
> When I restart ssh like so:
>
>sudo /etc/init.d/ssh restart
>
> I see very little output. Should it be more verbose?
>
> ,
> |harry > sudo /etc/init.d/ssh restart
1 - 100 of 456 matches
Mail list logo