Hey.
On Tue, 2024-04-02 at 01:30 +0100, Colin Watson wrote:
> All the same, I'm aware that some people now depend on having this
> facility in Debian's main openssh package: I get enough occasional
> bug
> reports to convince me that it's still in use.
Being one of those people, and having even
FYI: Ubuntu is apparently also consider to add this:
https://github.com/openssh-gsskex/openssh-gsskex/issues/24#issuecomment-1768955946
Cheers,
Chris.
Package: openssh-client
Version: 1:9.4p1-1
Severity: wishlist
Hey there.
I've recently filed:
https://github.com/openssh-gsskex/openssh-gsskex/issues/24
(not sure whether this is actually the current upstream, if there's
any at all, of Debian's GSSAPI patch).
In short, the problem is, that the
Hey.
I've wondered whether the GSSAPI patch is still maintained at
https://github.com/openssh-gsskex/openssh-gsskex/
or somewhere else?
Reason for asking is that the following doesn't work completely:
When I have set up a user krb keytab (i.e. in order to get krb tickets
without having to
Source: openssh
Version: 1:8.4p1-5
Severity: important
Hey.
This is from https://bugzilla.mindrot.org/show_bug.cgi?id=3307:
Hey there.
I've noted the two errors, with the following setup:
Locally, I have:
OpenSSH_8.4p1 Debian-5, OpenSSL 1.1.1k 25 Mar 2021
from which I connect to some
Package: openssh-server
Version: 1:8.4p1-5
Severity: minor
Hi.
Seems in some version, the homedir of sshd was changed from /var/run/sshd
to /run/sshd.
However, old installations didn't receive that upgrade, would be nice
if this could be done in a future version of the package.
Cheers,
Hey.
Just wondered whether there is some way do finally fix this?
The upstream bug has been closed as wonfix, ... upstream explains in
detail that they're not going to change this in:
https://bugzilla.mindrot.org/show_bug.cgi?id=1346#c12
One "solution" would be obviously to keep
Package: openssh-server
Version: 1:7.5p1-5
Severity: normal
Hi.
There used to be /lib/systemd/system/ssh-session-cleanup.service
which was enabled in /etc/systemd/system/multi-user.target.wants/
automatically.
This former file no longer exists at that path, but it seems
the service wasn't
On Fri, 2017-01-27 at 10:34 +0100, lopiuh wrote:
> * What outcome did you expect instead?
> [...]
> #LoginGraceTime 2m
> PermitRootLogin prohibit-password
> #StrictModes yes
> #MaxAuthTries 6
> #MaxSessions 10
> [...]
No, the outcome shouldn't be that, it should be left just at default
(which
Source: openssh
Severity: normal
Hi.
I've just stumbled (after much searching, since there seems to be no
changelog entry o.O) over commit 18a9bd1867ee6fb9d913515773b322a279759b5d.
Which automagically/silently replaces "without-password" with
"prohibit-password"
for some versions.
First,
On Sun, 2016-07-24 at 01:38 +0200, Michael Biebl wrote:
> It doesn't help for the non-systemd case and people who opt to not
> install recommends by default use a non-standard configuration, so
> it's
> imho ok if those need to also apply additional configuration in case
> of
> SSH. We should
On Sat, 2016-07-23 at 11:29 +0100, Colin Watson wrote:
> While of course I have libpam-systemd installed on all my systems, I
> really don't want to depend on it; besides, the original report had
> people saying that they encountered occasional problems of sessions
> not
> being cleaned up even
Hey Colin.
Not really an issue, but:
>Description=OpenBSD Secure Shell session cleanup
I thought the official name was "OpenSSH", so rather "Open Secure
Shell" (if at all) and not "OpenBSD Secure Shell"?
Cheers,
Chris
smime.p7s
Description: S/MIME cryptographic signature
Package: openssh-client
Version: 1:7.1p1-6
Severity: critical
Tags: security
Justification: root security hole
Hey.
You probably know about this already, but just in case not:
https://lists.mindrot.org/pipermail/openssh-unix-dev/2016-January/034679.html
Cheers,
Chris.
-- System Information:
On Thu, 2016-01-14 at 15:03 +, Colin Watson wrote:
> Yes, I do. Upload coming soon.
Great work :-) As usually the security team and maintainers are pretty
fast in Debian... if now there wouldn't be easy ways for blocking
attacks against secure APT, one could really feel pretty safe :)
On Thu, 2016-01-14 at 16:01 +0100, Yves-Alexis Perez wrote:
> Thanks for the report, yes we're aware of it.
The announcement doesn't read *that* extremely bad (well depends a bit
on whether one connects to untrusted systems), though,... thus maybe
the severity of this can be lowered.
OTOH, since
Hey.
The upstream of that patch is intended to be here:
https://github.com/gss-openssh/openssh-portable
You may want to forward the problem there as well :-)
Chris.
smime.p7s
Description: S/MIME cryptographic signature
On Sat, 2015-12-05 at 14:16 +, Colin Watson wrote:
> I may consider building a separate client-only package with protocol
> 1
> support, but I'd like to see how things go. It seems important for
> the
> general health of the internet that people put pressure on vendors
> and
> sysadmins to
Hi Ben.
On Thu, 2015-12-03 at 09:29 -0500, Benjamin Kaduk wrote:
> That was unintentional, and has been rectified. I am somewhat
> surprised
> that no one thought to pester me about it, as the person who made the
> latest commit to that repository, but it is true that there have been
> more
>
On Thu, 2015-11-12 at 19:21 +1300, martin f krafft wrote:
> also sprach Christoph Anton Mitterer <cales...@scientia.net> [2015-
> 11-12 17:41 +1300]:
> > > Hopeful, I was looking at VerifyHostKeyDNS for relief
> > The default StrictHostKeyChecking isn't secure enough f
On Thu, 2015-11-12 at 17:05 +1300, martin f krafft wrote:
> This makes sense:
>
> fishbowl:~% ssh -v cirrus
> OpenSSH_6.9p1 Debian-2+b1, OpenSSL 1.0.2d 9 Jul 2015
> […]
> debug1: UpdateHostKeys=ask is incompatible with ControlPersist;
> disabling
>
> But when I pass -Snone, I effectively
On Sun, 2015-09-20 at 12:42 +0500, rihad wrote:
> systemd may just be too buggy, since it has another design
> deficiency
This isn't a bug in systemd... o.O
smime.p7s
Description: S/MIME cryptographic signature
On Mon, 2015-08-17 at 12:23 +0200, Laurent Bigonville wrote:
The correct solution is IMVHO is to use libpam-systemd with UsePAM
set
to yes. On other solution is to change the KillMode, but doing so,
you'll probably loose the connection if the ssh service is restarted.
Both doesn't seem to be
On Thu, 2015-07-30 at 10:39 +0200, Uwe Kleine-König wrote:
This doesn't terminate the ssh-command to keep the control socket
open. Then pressing Ctrl-Z and run bg to send the ssh into the
background.
I think that's basically as it should be.
The manpage's documentation is unfortunately
On Thu, 2015-07-30 at 20:50 +0200, Uwe Kleine-König wrote:
My plan was, that this is forwarded by the ssh maintainers as they
for
sure now better than me where and how to report this :-)
The upstream bugtracker would be at https://bugzilla.mindrot.org/
Best wishes,
Chris.
smime.p7s
On Sat, 2015-07-04 at 14:40 -0700, Daniel Kauffman wrote:
If sshd is configured with UsePAM yes, then after installing libpam
-systemd to a remote system and rebooting, ssh sessions are cleanly
terminated, but after purging libpam-systemd and rebooting, ssh
session are not cleanly
On Tue, 2015-06-30 at 13:30 +0200, Vincent Lefevre wrote:
You should learn how terminals work. When using a terminal, the
remote
charmap MUST be the same as the local one (or be a subset), otherwise
the terminal cannot interpret the byte sequences correctly.
Sure... I haven't said that I
Hey
Am 29. Juni 2015 14:25:15 MESZ, schrieb Vincent Lefevre
vinc...@vinc17.net:
I completely disagree that passing XTERM_VERSION is not secure
(this RFE is about this particular variable, and not anything else).
To be honest, I think it's at best naive to assume, that one can
predict whether
On Tue, 2015-06-30 at 01:23 +0200, Vincent Lefevre wrote:
On the other hand, having the wrong charmap on the other side is a
security issue, because remote utilities could send characters that
they think to be printable, but are actually control characters /
escape sequences due to the wrong
On Tue, 2015-06-30 at 04:30 +0200, Vincent Lefevre wrote:
Well but there one knows / must assume at least that this can
happen:
When one remotely accesses a system and processes output from
there, it
must be assumed that there are different locales/etc. and
appropriate
means taken.
We've had the same discussion last time when it was about LC_*.
It's generally a bad idea to change the secure default of not
forwarding/accepting anything.
Due to past errors, we're already in the unfortunate situation that
this is done for an arbitrary number of vars, and regrettably the
I'd be fine with keeping that one in addition.
But I would also like to add that these upstream changes (i.e. removing
the 1Ki groups) is IMHO not enough action.
Looking at the summaries at http://www.keylength.com/, basically all
experts seem to agree that the next few group sizes above 1024
On Wed, 2015-05-27 at 15:38 +0100, Colin Watson wrote:
I've always disagreed with this, which is why the banner default is the
way it is. In particular, I've generally seen very little in the way of
evidence that people actually bother to select the servers they're going
to attack based on
On Wed, 2015-05-27 at 16:58 +0100, Colin Watson wrote:
Nagios is fine if you're running a server farm. It's useless if your
purpose is to perform friendly probing of a large heterogeneous network
most of which consists of desktop-type systems not run by professional
sysadmins.
We have
Control: -1 forcemerge 765632 787002
Me was first ;-P
smime.p7s
Description: S/MIME cryptographic signature
On Wed, 2015-05-27 at 18:29 +0100, Colin Watson wrote:
Like I say, I'm not aware of this being an issue in practice. If you
know real details, then instead of replying to this bug with hypotheses,
please point me at real examples.
As I've said... I (personally) don't feel that concerned about
On Thu, 2015-05-21 at 13:59 +0100, Matthew Vernon wrote:
bits count
1023 36
1535 32
I'd remove at least these completely.
2047 28
This I'd keep probably only with a warning (according to ECRYPT II it's
only safe in the range to aat best 2020-2030
3071 26
Still below Long term
On Tue, 2015-05-12 at 13:45 +0200, Michael Biebl wrote:
(since this was targetted at me, you should have CCed me. I don't get
openssh-server bug mail)
Sorry,... must have dropped out somehow.
A patch for that should be not that complicated and might even be worth
shipping downstream if
On Tue, 2015-05-12 at 10:20 +1000, Matt Black wrote:
I've also found that installing libpam-systemd seems to fix this for
me in my testing. (If I discover it still to be a problem, I'll post
again). However, I'd like to understand why libpam-systemd makes a
difference if anyone has any
On Tue, 2015-05-12 at 10:49 +1000, Matt Black wrote:
Interesting. The important thing here then is my question - WHY does
libpam-systemd make a difference in some cases?
I think Russ mentioned it before already,... it may be simply some
timing issues i.e. libpam-systemd's presence slowing the
Package: openssh-server
Version: 1:6.7p1-6
Severity: wishlist
Hi.
Currently, when the package is installed and hostkeys are created
this is apparently done with setting the key's comment field in a
user@hostname fashion, I guess imply by using ssh-keygen's default.
It may be cosmetically nicer
On Sat, 2015-05-02 at 18:55 -0700, Steven Monai wrote:
I was having this same problem on a new, minimal Jessie installation.
Installing libpam-systemd (and rebooting) fixed it.
I somewhat doubt that this is really a fix.
When I reported the problem in the beginning, I've always had
On Thu, 2015-04-30 at 23:00 +0200, Ferenc Wagner wrote:
By usual means do you mean preseeding late_command with a sed script
editing sshd_config?
No I rather meant by using the installation system or configuration
system you use (FAI, puppet, etc.)
Cheers,
Chris.
smime.p7s
Description:
What's the problem with simply changing the configuration by usual means
as with all other options which are not specifically handled by debconf?
Cheers,
Chris.
smime.p7s
Description: S/MIME cryptographic signature
Hi Michael.
Your proposal seems to be a good solution for now. Maybe Colin can merge
it and it will find it's way into jessie.
As for sd_notify,... a simply google query didn't turn up any existing
patches for that and it may be hard to convince upstream to do it ;)
Since this problem may
On Mon, 2015-03-23 at 10:17 +, Colin Watson wrote:
I disagree with this characterisation.
Well I guess we won't come to an agreement here.
I've had a short glance over the discussion that the IETF WG and
upstream had about the bug you've mentioned, and it seems that both
seemed to think the
On Sun, 2015-03-22 at 23:18 +, Colin Watson wrote:
Control: tag 765633 wontfix
Ah it's really a shame... not that the issue is particularly critical,
but it shows a general problem within Debian why we have so many fields
where no progress is made - and if it it's made some people must just
On Sun, 2015-03-22 at 19:20 -0400, Chris Knadle wrote:
Christoph: there may be a lack of empathy in your response statements.
Please try to put yourself in the user's shoes -- the issue looks
very different from that perspective. [I'm likewise considering this
from the maintainer
On Sun, 2015-03-22 at 20:35 +, Colin Watson wrote:
Anyway, I would appreciate it if people could refrain from filling my
mailbox further about this bug. :-)
One last thing perhaps. O:-)
Due to what I view as historical errors, sshd_config doesn't really have
a single canonical state on
On Sat, 2015-03-21 at 00:51 -0400, Chris Knadle wrote:
§ 10.7.3 Behavior
Configuration file handling must conform to the following behavior:
• local changes must be preserved during a package upgrade
Well, strictly speaking, if the user had let that option at it's Debian
default,
On Sat, 2015-03-21 at 11:13 +0100, Vincent Lefevre wrote:
The configuration consists of a full file, and the choice for some
option may depend on others.
That way you could *never* change anything nor upgrade systems.
Get a new firefox version, and the whole binary blob profile may
completely
On Sun, 2015-03-22 at 03:00 +0100, Vincent Lefevre wrote:
Bad example. The Firefox profile is not a config file.
Why not? it contains all my about:config settings, my bookmarks, etc.
It contains my enabled/disabled CA certificates (so it's actually even
quite security relevant, and every
On Thu, 2015-03-19 at 23:37 +0100, Vincent Lefevre wrote:
BTW, it's also annoying that the user can no longer pass env variables
(e.g. the charset) to the remote side for machines where the admin
just uses Debian's default.
But that was the case before either, at least except those matching
On Fri, 2015-03-20 at 00:46 +0100, Vincent Lefevre wrote:
Unfortunately, some admins want to stick with Debian's default config
(even when this config has a well-known security vulnerability[*]).
Well to be honest, apart from the fact that many people may not consider
AcceptEnv as security
On Thu, 2015-03-19 at 19:02 +, Colin Watson wrote:
Please read the original report in which Vincent explicitly said that he
had made local changes to that file.
Ah, I thought you'd also update modified files.
Absolutely not. This is not a reasonable question to ask most users and
I'm
On Thu, 2015-03-19 at 23:58 +0100, Vincent Lefevre wrote:
But at least the user could use non-standard (thus unused by the
system) variables to pass information to the remote side (in my case,
I used LC_CHARMAP). After this change only the standard variables can
be passed, but one shouldn't
On Fri, 2015-03-20 at 03:06 +0100, Vincent Lefevre wrote:
So, it's even easier: when the admin installs some software using,
say, LC_ALLOW_ARBITRARY_ACCESS, he can change the sshd config to
disallow this variable.
Sorry, but this is a highly disturbing and simply plain wrong approach
to
On Thu, 2015-03-19 at 16:31 +, Colin Watson wrote:
What did the file look like before this upgrade?
He probably had the Debian default which was then auto-migrated?
In general I think that old systems *SHOULD* actually be kept up to date
and that it's good to have them migrated.
AFAICS,
On Tue, 2015-02-24 at 11:40 +0800, Paul Wise wrote:
Unfortunately the documentation for -R and -L in the ssh manual page
still only mentions forwarding TCP ports, it would be nice to mention
forwarding sockets in the documentation of -R and -L as well as adding a
SOCKET FORWARDING section
On Sun, 2015-02-22 at 17:53 +, Colin Watson wrote:
Well, um, in either case, isn't it pretty weird that systemctl status
shows the unit as failed while the boot progress system shows it as OK?
Feels like a systemd bug to me.
Arguably, I'mm CCing the systemd guys, perhaps they can help out!
On Sun, 2015-02-22 at 22:31 +, Philip Hands wrote:
The primary thrust of this report seems to be about the modification
From upstream of the default for ForwardX11Trusted to now be set.
Well my mean reason, was actually more that Debian really changes some
default values in the program
On Sun, 2015-02-22 at 22:46 +0100, D.S. 'Spider' Ljungmark wrote:
Can you please add perl as the required dependency for OpenSSH
server? Since it refuses to actually install due to the postinst
script being written in perl. ( Installation order matters here, and
it usually works by
On Mon, 2015-02-09 at 19:18 -0800, Russ Allbery wrote:
It does make sense to me that it should be possible to both enable GSS-API
key exchange and otherwise restrict the key exchange methods that the
server will use in the absence of GSS-API. (Ideally, you could restrict
which specific
On Mon, 2015-02-09 at 20:15 -0800, Karl Kornel wrote:
That's what I thought, but as I understood the patch, it seems that
turning on GSSAPIKeyExchange is just working out what GSSAPI
key-exchange methods are supported, and then prepending those to the
default list of key-exchange
On Mon, 2015-02-09 at 18:53 -0800, Russ Allbery wrote:
Yeah, I would expect this, since GSS-API key exchange *is* a key exchange
mechanism. If you do GSS-API key exchange, that completely replaces the
normal ssh public key negotiation, since it instead uses Kerberos to
negotiate the
In order to make this more easily followable,... I'd ask people to post
any further information/replies on the earlier report (#774711) of the
same issue, which I've already merged with this bug. :)
Thx.
smime.p7s
Description: S/MIME cryptographic signature
retitle 774711 OpenSSH should use stronger crypto algo and parameters
respectively disable others
stop
Hi.
First, I've modified the title, since I think it's useless to only
harden servers while clients would be left at less secure defaults.
Also, the title should have stronger ciphers selected
forcemerge 774793 774711
stop
Hi.
This is basically the same as #774711, therefore merging.
On Wed, 2015-01-07 at 18:29 +0100, comot...@krutt.org wrote:
The attached patch updates openssh-server debian defaults through the
postinst script according to bettercrypto.org[2], stribika[3] and
On Wed, 2015-01-07 at 18:13 +, Colin Watson wrote:
The defaults should be changed upstream first (has anyone contacted
them?)
Well I've had some discussions with them as I've noted in #774711, but
more with respect to the issues in DH-GEX (moduli sizes, that the client
basically accepts
On Wed, 2015-01-07 at 15:25 +, Matthew Vernon wrote:
Christoph Anton Mitterer cales...@scientia.net writes:
On Tue, 2015-01-06 at 18:52 +0200, Vasil Kolev wrote:
- get openssh to generate 4096-bit RSA keys by default;
... and disable DSA and RSA1 keys, which is possible if you name
On Sun, 2014-12-14 at 09:28 -0800, Russ Allbery wrote:
since I routinely see the same behavior
when shutting down servers right now, in wheezy, using sysvinit.
This is quite interesting, btw,... cause I've never seen that during
times I've sysvinit.
Have you had any special modifications that
Answering two of your mails in one, since all of this got really off
topic.
On Sun, 2014-12-14 at 15:46 +0100, Marc Haber wrote:
Yes, but GNU/Linux is not a grüne wiese approach, it is migrating
millions of existing systems.
Sure, but this doesn't mean that one cannot pick out single points,
On Sun, 2014-12-14 at 16:19 +0100, Marc Haber wrote:
It might be expected by somebody very familiar with how new init
works. It is surprising to people who aren't and undresired by some of
them.
Again, this is why we have this bug. And when I talked about absolutely
expected behaviour I meant
On Sat, 2014-12-13 at 15:19 +0100, Marc Haber wrote:
prominent place which will be seen as systemd's fault by a gazillion
of people, including me.
Could you please place that systemd hatred somewhere else (we have
countless of such threads open where people could place there nonsense)?
ssh
On Sat, 2014-12-13 at 15:01 +0100, Marc Haber wrote:
I would like to have a method to
kill all ssh sessions with the exception of my own ones, or the single
session that I happen to type the command restarting sshd in.
Since there is no definition of which are yours (the ones logged in to
your
On Sat, 2014-12-13 at 15:06 +0100, Marc Haber wrote:
/lib/systemd/system/ssh.service in current sid has
After=network.target in its Unit stanza and still not cleanly kills
off ssh sessions.
Since the ssh.service unit file only starts the listener daemons and not
the sessions neither explicitly
On Sun, 2014-11-30 at 22:44 -0500, Micah Anderson wrote:
If you add the option ProtectSystem=yes to the service file, then the
daemon will not have the ability to write to /usr.
would =full work as well?
smime.p7s
Description: S/MIME cryptographic signature
Hmm, I'd have blindly guessed that all of systemd's security options apply only
per cgroup... and the sessions which run in their own cgroup wouldn't inherit
them... but you may be right..
--
To UNSUBSCRIBE, email to debian-ssh-requ...@lists.debian.org
with a subject of unsubscribe. Trouble?
retitle 751636 ssh sessions are not cleanly terminated on shutdown/restart with
systemd
stop
Hey.
Some updates on this:
1) I recently completely reworked my sshd_config, and since then, when I
shutdown the server where sshd runs upon, I do get logouts on the
clients that are connected to it.
On Wed, 2014-11-12 at 19:33 +0100, Christoph Anton Mitterer wrote:
1) ...
So it still seems that something is a bit fishy there.
I've now also seen the following:
root@otherHost:~# poweroff
Terminated
You have mail in /var/mail/root
root@otherHost:~# Connection to otherHost closed by remote
On Sun, 2014-10-26 at 18:06 +0100, Jonas Smedegaard wrote:
According to
http://www.greenend.org.uk/rjk/sftp/sftpimpls.html this implementation
supports version 3 - but that information may be inaccurate or too old.
It should then probably also document, what is actually meant with
protocol
On Sun, 2014-11-02 at 00:25 +0800, Desmond O.Chang wrote:
The argument of UsePAM must be yes or no, but sshd -T outputs 1 or
0.
It causes sshd -T always fails on any file generated by sshd -T.
This is probably an upstream issue.
It also seems that sshd -T misses quite some options from
Hi Gerfried
On Fri, 2014-10-17 at 13:31 +0200, Gerfried Fuchs wrote:
This is documented and explained in the documentation in
/usr/share/doc/openssh-client/README.Debian.gz and also referenced from
the changelog.Debian.gz file, which is the canonical point to look at
for changes within the
On Fri, 2014-10-17 at 13:31 +0200, Gerfried Fuchs wrote:
This is documented and explained in the documentation in
/usr/share/doc/openssh-client/README.Debian.gz
btw: at least parts of that file seem to be outdated:
Authorization Forwarding - setting this to no seems to be just the
plain
Package: openssh-client
Version: 1:6.7p1-2
Severity: minor
Hi.
1) In the beginning of the ssh_config(5) manpage it states:
Note that the Debian openssh-client package sets several options as stan‐
dard in /etc/ssh/ssh_config which are not the default in ssh(1):
· SendEnv LANG LC_*
·
Package: openssh-client
Version: 1:6.7p1-2
Severity: important
Tags: security
Hi.
Apparently Debian deviates in a few of OpenSSH's hardcoded default
settings, namely:
- ForwardX11Trusted having set to yes
- ServerAliveInterval being set to 300, when BatchMode is set to yes.
Even though I've
Source: openssh
Version: 1:6.7p1-2
Severity: wishlist
Hi.
May I suggest to use a default of:
LANG LC_ALL LC_ADDRESS LC_COLLATE LC_CTYPE LC_IDENTIFICATION
LC_MEASUREMENT LC_MESSAGES LC_MONETARY LC_NAME LC_NUMERIC
LC_PAPER LC_TELEPHONE LC_TIME
instead of the current
LANG LC_*
for SendEnv and
Source: openssh
Version: 1:6.7p1-2
Severity: wishlist
Tags: patch
Hi Colin.
I would find the attached patch to be a useful addition
to the description of the two options regarding cascading
credentials in the manpages.
Could you please have a look at it and if you like it
merge it with your
tags 765655 + upstream
stop
Hi Simon.
Russ Allerby just reminded me that these things should go upstream
respectively that you can likely answer them.
Could you please have a look at:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765655
Thanks,
Chris.
smime.p7s
Description: S/MIME
On Sat, 2014-10-11 at 11:23 +0200, Tom Hutter wrote:
Exactly. Stop apache, nginx, mysql, postgres and tell me, how many
children processes will be left, once you stopped it.
As ssh behaves differently and keeps the children alive, you have to
handle it differently :-)
Sure...
But I mean
On Sat, 2014-10-11 at 18:33 -0700, Russ Allbery wrote:
Yes, a lot of people being *quite* upset when they stop ssh to restart it
with debugging or to temporarily bring it down while working on something,
discover that their session was terminated in a way that's never happened
with ssh in the
On Fri, 2014-10-10 at 11:52 +0200, Tom Hutter wrote:
Therefore I added a service, to solve this under the current Debian
Wheezy version I am running.
Hmm I'm a bit torn apart between thinking that this is either an ugly
hack or a clean solution ^^
ExecStart=/bin/true
At least this seems a hack
On Fri, 2014-10-10 at 21:56 +0100, Colin Watson wrote:
I think it is indeed far too late to change this, sorry.
Mhh yeah well I thought that perhaps - if it was agreed that the name
could be better - one could do the following:
- add a NEWS file entry
- parse the old name as well for one Debian
On Fri, 2014-10-10 at 18:51 +0200, Tom Hutter wrote:
Hmm I'm a bit torn apart between thinking that this is either an
ugly hack or a clean solution ^^
Never said it's not a hack. I may disagree in the word ugly ;-)
;-)
If ssh is restarted, my hack does exactly the expected. The ssh user
(Sorry if there's double posting, but something apparently went wrong
and the bug was archived again before this reply made it through)
On Fri, 2014-10-10 at 22:15 +0100, Colin Watson wrote:
I honestly don't think that this is worth the hassle and additional code
to change this. More code
Package: openssh-server
Version: 1:6.6p1-5
Severity: normal
Hi.
Since openssh-server comes with systemd support, whenever a host
is shut down or restarted, ssh connections to that host just hang
and are no longer cleanly terminated (one also doesn't see the
shutdown message anymore).
I'd
See Also:
https://bugzilla.redhat.com/show_bug.cgi?id=626477
smime.p7s
Description: S/MIME cryptographic signature
On Tue, 2014-02-11 at 11:19 +, Colin Watson wrote:
Oops, right.
No real problem... I'm just a perfectionist... even regarding typos in
changelogs ;)
I'll retroactively correct the changelog. (You still need
to add the HostKey entry manually on upgrades.)
Actually I didn't understand
Package: openssh-server
Version: 1:6.5p1-1
Severity: minor
Hi.
As far as I'd understand the changelog entry
* Generate ED25519 host keys on fresh installations. Upgraders who wish
to add such host keys should manually add 'HostKey
/etc/ssh/ssh_host_ed25519_key' to
Package: openssh-server
Version: 1:6.2p2-3
Severity: wishlist
Hi.
With respect to the creation of SSH server keys in postinst, may I suggest the
following:
- not create ssh1 keys at all... actually I've never seen them auto-created,
but code seems to be there
This is mainly for security
1 - 100 of 102 matches
Mail list logo
