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

[Vincent Lefevre]

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

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

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

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

openssh-server 1:7.9p1-10+deb10u3

but I don't think this is useful.

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

At the time of the test:

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

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

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

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

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

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

[Greg Wooledge]

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

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

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

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

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

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

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

[Klaus Singvogel]

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

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

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

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

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

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

[Vincent Lefevre]

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

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

Note also that this is an error that occurs randomly.

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

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

[Klaus Singvogel]

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

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

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

Re: openssh server

[Ángel]

On 2022-08-22 at 08:42 -0400, Roberto C. Sánchez wrote:
> On Mon, Aug 22, 2022 at 12:33:42PM +0200, Radwan Daoud wrote:
> >I want to install an old version of openssh server on my Debian 11.
> >I want to install Debian 9 ssh version on Debian 11 ,  is that possible:
> >[1]https://packages.debian.org/stretch/openssh-server
> >Please don't ask me , I want to do that 
> >Thanks 
>
> Installing that older version of openssh directly on Debian 11 is likely
> to come with some issues related to dependecies.  I would recommend that
> you create a chroot, docker container, or some other separate
> environment with Debian 9 and install the openssh-server packages there,
> where you will be certain to get all the dependencies automatically and
> without the possibility of disturbing other packages and their
> dependencies (which can happen when mixing packages from different
> Debian releases).
> 
> Regards,
> 
> -Roberto


The problem of installing openssh-server into a chroot/container/VM is
that when connecting to the system, he would end up into that
container. He may be able to install in a chroot but allow himself to
exit into the main system once connected, but it's not elegant.

I think a better solution in this case would be to recompile the
openssh-server source package from stretch in bullseye. It will
probably compile cleanly, and should avoid most dependency problems
that could arise if he instead used the binary package.


Nonetheless, I know that the OP said
> Please don't ask me , I want to do that 

but I'm pretty sure this is a XY Problem , 
and the actual issue is probably that be OP is no longer able to
connect from certain client, but thinks it worked in stretch, so
decided to install an old version of openssh-server.

Whereas the right solution is probably to either:
a) Install an updated ssh client
b) Change a few lines on sshd_config so that the newer openssh-server
in bullseye still allows that outdated client to connect.


Regards

Re: openssh server

[Roberto C . Sánchez]

On Mon, Aug 22, 2022 at 12:33:42PM +0200, Radwan Daoud wrote:
>I want to install an old version of openssh server on my Debian 11.
>I want to install Debian 9 ssh version on Debian 11 ,  is that possible:
>[1]https://packages.debian.org/stretch/openssh-server
>Please don't ask me , I want to do that 
>Thanks 
> 
Your question belongs on the debian-user list, not the debian-www list
(which is about maintenance of Debian's websites).

Installing that older version of openssh directly on Debian 11 is likely
to come with some issues related to dependecies.  I would recommend that
you create a chroot, docker container, or some other separate
environment with Debian 9 and install the openssh-server packages there,
where you will be certain to get all the dependencies automatically and
without the possibility of disturbing other packages and their
dependencies (which can happen when mixing packages from different
Debian releases).

Regards,

-Roberto

-- 
Roberto C. Sánchez

Re: OpenSSH: cause of random kex_exchange_identification errors?

[Vincent Lefevre]

On 2022-06-15 15:10:17 +0200, Vincent Lefevre wrote:
> They set LogLevel to DEBUG, which explains that the debug3() message
> doesn't appear. They can see debug lines when my connection succeeds,
> but nothing in case of immediate failure. So this would mean that it
> is the pipe() from server_accept_loop() in sshd.c that fails, as
> nothing is logged in that case.

I've eventually submitted an enhancement request to get something
logged in case of pipe() failure:

  https://bugzilla.mindrot.org/show_bug.cgi?id=3447

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

Re: OpenSSH: cause of random kex_exchange_identification errors?

[Vincent Lefevre]

On 2022-06-15 03:48:38 +0200, Vincent Lefevre wrote:
> The source from misc.c is
> 
> int
> unset_nonblock(int fd)
> {
> int val;
> 
> val = fcntl(fd, F_GETFL);
> if (val < 0) {
> error("fcntl(%d, F_GETFL): %s", fd, strerror(errno));
> return (-1);
> }
> if (!(val & O_NONBLOCK)) {
> debug3("fd %d is not O_NONBLOCK", fd);
> return (0);
> }
> debug("fd %d clearing O_NONBLOCK", fd);
> val &= ~O_NONBLOCK;
> if (fcntl(fd, F_SETFL, val) == -1) {
> debug("fcntl(%d, F_SETFL, ~O_NONBLOCK): %s",
> fd, strerror(errno));
> return (-1);
> }
> return (0);
> }
> 
> Well, one should get at least a debug message. I had already told
> that to the admins last week. But no such debug message appears,
> even when the connection succeeds! I'll try to have more information
> from the admins, in particular which debug lines they claim to see.

They set LogLevel to DEBUG, which explains that the debug3() message
doesn't appear. They can see debug lines when my connection succeeds,
but nothing in case of immediate failure. So this would mean that it
is the pipe() from server_accept_loop() in sshd.c that fails, as
nothing is logged in that case.

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

Re: OpenSSH: cause of random kex_exchange_identification errors?

[Vincent Lefevre]

On 2022-06-14 19:17:01 +0100, Tim Woodall wrote:
[MaxStartups limit]
> In the case where I hit it it was a cron job starting an ssh connection
> from multiple machines - 'out of hours' where 'convenience' was more
> valuable than 'performance'.

Note that I get the errors at random times of the day and night,
with periods where the error occurs quite often and other periods
where I cannot reproduce it.

> I don't have any more suggestions, sorry. Do you know how unset_nonblock
> can fail?

The source from misc.c is

int
unset_nonblock(int fd)
{
int val;

val = fcntl(fd, F_GETFL);
if (val < 0) {
error("fcntl(%d, F_GETFL): %s", fd, strerror(errno));
return (-1);
}
if (!(val & O_NONBLOCK)) {
debug3("fd %d is not O_NONBLOCK", fd);
return (0);
}
debug("fd %d clearing O_NONBLOCK", fd);
val &= ~O_NONBLOCK;
if (fcntl(fd, F_SETFL, val) == -1) {
debug("fcntl(%d, F_SETFL, ~O_NONBLOCK): %s",
fd, strerror(errno));
return (-1);
}
return (0);
}

Well, one should get at least a debug message. I had already told
that to the admins last week. But no such debug message appears,
even when the connection succeeds! I'll try to have more information
from the admins, in particular which debug lines they claim to see.

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

Re: OpenSSH: cause of random kex_exchange_identification errors?

[Tim Woodall]

On Tue, 14 Jun 2022, Vincent Lefevre wrote:


On 2022-06-07 17:19:12 +0100, Tim Woodall wrote:

On Tue, 7 Jun 2022, Vincent Lefevre wrote:

I eventually did a packet capture on the client side as I was able to
reproduce the problem. When it occurs, I get the following sequence:

Client ? Server: [SYN] Seq=0
Server ? Client: [SYN, ACK] Seq=0
Client ? Server: [ACK] Seq=1
Server ? Client: [FIN, ACK] Seq=1
Client ? Server: Client: Protocol (SSH-2.0-OpenSSH_9.0p1 Debian-1)
Server ? Client: [RST] Seq=2
Client ? Server: [FIN, ACK] Seq=33
Server ? Client: [RST] Seq=2

So the issue comes from the server, which sends [FIN, ACK] to terminate
the connection. In OpenSSH's sshd.c, this could be due to

   if (unset_nonblock(*newsock) == -1 ||
   drop_connection(*newsock, startups) ||
   pipe(startup_p) == -1) {
   close(*newsock);
   continue;
   }

At least 2 kinds of errors are not logged:

* In unset_nonblock(), a "fcntl(fd, F_SETFL, val) == -1" condition.

* the "pipe(startup_p) == -1" condition.

I'm not sure about drop_connection(), which is related to MaxStartups.



I've not seen the start of this thread but is this occasional or always?


Occasional. Someone else at my lab could reproduce the issue.
But the admins can't.


If occasional, how many concurrent connections do you have starting all
at once.


I'm not sure what you mean by "concurrent connections". The server
is a SSH gateway, so that many users connect to it. But for the
client host above (my personal machine at my lab), this was the
only connection from this machine; note I did this connection only
for testing, as there is no need to connect to this SSH gateway
from the lab.



It doesn't matter if they're from the same machine, the problem happens
if the target machine has too many connections that haven't finished
authenticating (but from what you say below I doubt this is the problem)


The default ssh config has a super-annoying default that
randomly kills sessions if too many are handshaking at once.

It's the MaxStartups setting you allude to. I've been bitten by this
where cron jobs all start at the same time and ssh to the same host.


MaxStartups was increased in February, after I initially reported
the problem.


So long as they've increased the first parameter then that should have
fixed it if it was the cause.


Since this is a Debian 10 machine with OpenSSH_7.9p1 Debian-10+deb10u2,
I should have quoted the code from this sshd.c version. Thus the
connection close issue should occur in

if (unset_nonblock(*newsock) == -1) {
close(*newsock);
continue;
}
if (drop_connection(startups) == 1) {
char *laddr = get_local_ipaddr(*newsock);
char *raddr = get_peer_ipaddr(*newsock);

verbose("drop connection #%d from [%s]:%d "
"on [%s]:%d past MaxStartups", startups,
raddr, get_peer_port(*newsock),
laddr, get_local_port(*newsock));
free(laddr);
free(raddr);
close(*newsock);
continue;
}
if (pipe(startup_p) == -1) {
close(*newsock);
continue;
}

Now, it appears that verbose() logs at SYSLOG_LEVEL_VERBOSE, and it
is just below the default SYSLOG_LEVEL_INFO, so that nothing would be
logged by default concerning MaxStartups, if I understand correctly.

But the admins changed the log level to some debug one a few days ago,
and debug messages effectively appear, but nothing concerning my case
(I had sent the exact time of the failures to the admins).

BTW, the issue also occurs at night, while there should be very few
connections at handshaking status.



In the case where I hit it it was a cron job starting an ssh connection
from multiple machines - 'out of hours' where 'convenience' was more
valuable than 'performance'.

I don't have any more suggestions, sorry. Do you know how unset_nonblock
can fail? Other than building a patched version with more logging I
don't know what else to try that you haven't already done.

Tim.

Re: OpenSSH: cause of random kex_exchange_identification errors?

[Vincent Lefevre]

On 2022-06-07 17:19:12 +0100, Tim Woodall wrote:
> On Tue, 7 Jun 2022, Vincent Lefevre wrote:
> > I eventually did a packet capture on the client side as I was able to
> > reproduce the problem. When it occurs, I get the following sequence:
> > 
> > Client ? Server: [SYN] Seq=0
> > Server ? Client: [SYN, ACK] Seq=0
> > Client ? Server: [ACK] Seq=1
> > Server ? Client: [FIN, ACK] Seq=1
> > Client ? Server: Client: Protocol (SSH-2.0-OpenSSH_9.0p1 Debian-1)
> > Server ? Client: [RST] Seq=2
> > Client ? Server: [FIN, ACK] Seq=33
> > Server ? Client: [RST] Seq=2
> > 
> > So the issue comes from the server, which sends [FIN, ACK] to terminate
> > the connection. In OpenSSH's sshd.c, this could be due to
> > 
> >if (unset_nonblock(*newsock) == -1 ||
> >drop_connection(*newsock, startups) ||
> >pipe(startup_p) == -1) {
> >close(*newsock);
> >continue;
> >}
> > 
> > At least 2 kinds of errors are not logged:
> > 
> > * In unset_nonblock(), a "fcntl(fd, F_SETFL, val) == -1" condition.
> > 
> > * the "pipe(startup_p) == -1" condition.
> > 
> > I'm not sure about drop_connection(), which is related to MaxStartups.
> > 
> 
> I've not seen the start of this thread but is this occasional or always?

Occasional. Someone else at my lab could reproduce the issue.
But the admins can't.

> If occasional, how many concurrent connections do you have starting all
> at once.

I'm not sure what you mean by "concurrent connections". The server
is a SSH gateway, so that many users connect to it. But for the
client host above (my personal machine at my lab), this was the
only connection from this machine; note I did this connection only
for testing, as there is no need to connect to this SSH gateway
from the lab.

> The default ssh config has a super-annoying default that
> randomly kills sessions if too many are handshaking at once.
> 
> It's the MaxStartups setting you allude to. I've been bitten by this
> where cron jobs all start at the same time and ssh to the same host.

MaxStartups was increased in February, after I initially reported
the problem.

Since this is a Debian 10 machine with OpenSSH_7.9p1 Debian-10+deb10u2,
I should have quoted the code from this sshd.c version. Thus the
connection close issue should occur in

if (unset_nonblock(*newsock) == -1) {
close(*newsock);
continue;
}
if (drop_connection(startups) == 1) {
char *laddr = get_local_ipaddr(*newsock);
char *raddr = get_peer_ipaddr(*newsock);

verbose("drop connection #%d from [%s]:%d "
"on [%s]:%d past MaxStartups", startups,
raddr, get_peer_port(*newsock),
laddr, get_local_port(*newsock));
free(laddr);
free(raddr);
close(*newsock);
continue;
}
if (pipe(startup_p) == -1) {
close(*newsock);
continue;
}

Now, it appears that verbose() logs at SYSLOG_LEVEL_VERBOSE, and it
is just below the default SYSLOG_LEVEL_INFO, so that nothing would be
logged by default concerning MaxStartups, if I understand correctly.

But the admins changed the log level to some debug one a few days ago,
and debug messages effectively appear, but nothing concerning my case
(I had sent the exact time of the failures to the admins).

BTW, the issue also occurs at night, while there should be very few
connections at handshaking status.

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

Re: OpenSSH: cause of random kex_exchange_identification errors?

[Tim Woodall]

On Tue, 7 Jun 2022, Vincent Lefevre wrote:


On 2022-02-05 18:39:27 -0300, Henrique de Moraes Holschuh wrote:

If it is sshd, ensure it is actually logging all you need, and carefully
study the logs.


Nothing interesting in the logs, according to the admins of the server.


If nothing helps, packet-dump both sides (client and server) and find
out what sent the TCP RST, as that might give you clues for the "why".
A middlebox might be doing it...


I eventually did a packet capture on the client side as I was able to
reproduce the problem. When it occurs, I get the following sequence:

Client ? Server: [SYN] Seq=0
Server ? Client: [SYN, ACK] Seq=0
Client ? Server: [ACK] Seq=1
Server ? Client: [FIN, ACK] Seq=1
Client ? Server: Client: Protocol (SSH-2.0-OpenSSH_9.0p1 Debian-1)
Server ? Client: [RST] Seq=2
Client ? Server: [FIN, ACK] Seq=33
Server ? Client: [RST] Seq=2

So the issue comes from the server, which sends [FIN, ACK] to terminate
the connection. In OpenSSH's sshd.c, this could be due to

   if (unset_nonblock(*newsock) == -1 ||
   drop_connection(*newsock, startups) ||
   pipe(startup_p) == -1) {
   close(*newsock);
   continue;
   }

At least 2 kinds of errors are not logged:

* In unset_nonblock(), a "fcntl(fd, F_SETFL, val) == -1" condition.

* the "pipe(startup_p) == -1" condition.

I'm not sure about drop_connection(), which is related to MaxStartups.



I've not seen the start of this thread but is this occasional or always?
If occasional, how many concurrent connections do you have starting all
at once. The default ssh config has a super-annoying default that
randomly kills sessions if too many are handshaking at once.

It's the MaxStartups setting you allude to. I've been bitten by this
where cron jobs all start at the same time and ssh to the same host.

Re: OpenSSH: cause of random kex_exchange_identification errors?

[Vincent Lefevre]

On 2022-02-05 18:39:27 -0300, Henrique de Moraes Holschuh wrote:
> If it is sshd, ensure it is actually logging all you need, and carefully
> study the logs.

Nothing interesting in the logs, according to the admins of the server.

> If nothing helps, packet-dump both sides (client and server) and find
> out what sent the TCP RST, as that might give you clues for the "why".
> A middlebox might be doing it...

I eventually did a packet capture on the client side as I was able to
reproduce the problem. When it occurs, I get the following sequence:

Client → Server: [SYN] Seq=0
Server → Client: [SYN, ACK] Seq=0
Client → Server: [ACK] Seq=1
Server → Client: [FIN, ACK] Seq=1
Client → Server: Client: Protocol (SSH-2.0-OpenSSH_9.0p1 Debian-1)
Server → Client: [RST] Seq=2
Client → Server: [FIN, ACK] Seq=33
Server → Client: [RST] Seq=2

So the issue comes from the server, which sends [FIN, ACK] to terminate
the connection. In OpenSSH's sshd.c, this could be due to

if (unset_nonblock(*newsock) == -1 ||
drop_connection(*newsock, startups) ||
pipe(startup_p) == -1) {
close(*newsock);
continue;
}

At least 2 kinds of errors are not logged:

* In unset_nonblock(), a "fcntl(fd, F_SETFL, val) == -1" condition.

* the "pipe(startup_p) == -1" condition.

I'm not sure about drop_connection(), which is related to MaxStartups.

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

Re: OpenSSH: cause of random kex_exchange_identification errors?

[Vincent Lefevre]

On 2022-02-05 18:39:27 -0300, Henrique de Moraes Holschuh wrote:
> On Wed, 02 Feb 2022, Vincent Lefevre wrote:
> > When I want to connect with SSH (ssh/scp) to some machine, I sometimes
> > get errors, either
> > 
> > kex_exchange_identification: Connection closed by remote host
> > 
> > or
> > 
> > kex_exchange_identification: read: Connection reset by peer
> 
> That's a very early stage of the initial connection, and your SSH client
> just noticed the remote server (or some middle box like a firewall, or
> oversubscribed NAT gateway) dropped the TCP connection for whatever
> reason.

Yes, this is what I observed, e.g. when I reproduced the error
with telnet.

> It will be related to the TCP connection itself, and nothing else. IP
> protocol family/address/port, or something in the TCP path misbehaving.
> 
> The most common reason is that the remote server disliked your IP
> address and/or port due to /etc/hosts.allow/deny, firewalling, or
> something in sshd_config.

I could reproduce the issue from multiple IP addresses (both from
the local network and from external networks), and the errors are
completely random. Immediately after a failure, this can succeed.

There's a fail2ban, but the IP can get banned only after
authentication failures, and in this case, the error is not the same:
the connection is not accepted (something like "connection refused",
not a kex_exchange_identification error, where the connection is
first accepted).

> Ensure you check both IPv4 and IPv6.

Only IPv4 is supported there (the host does not have an IPv6 address,
so that there can't be any mistake).

> > The admin of the machine could see nothing particular in the logs.
> > He eventually modified the MaxStartups value, but this did not
> > solve the issue (but AFAIK, if this were the cause, there would
> > have been something about it in the logs). The machine has enough
> > available memory.
> > 
> > Any idea about the possible cause of these random errors?
> 
> The debugging needs to be done either in the server side, or on *both*
> sides.
> 
> If you're using socket-forwarding stuff in the client side, check that.
> This is exceedingly rare nowadays, so I doubt it.  Stuff like SOCKS4 or
> SOCKS5 TCP proxies.

Nothing like that.

> Find what is actually listening on the TCP socket server-side, it might
> not be sshd (interposers like systemd socket activation, xinetd/inetd,
> etc).  The logs/access control you need to look at server-side might not
> be SSHD's in that case.

There's a xinetd running, but its config files show that it does not
handle sshd, and there's a /usr/sbin/sshd running anyway (with lots
of children corresponding to all the current connections).

> If it is sshd, ensure it is actually logging all you need, and carefully
> study the logs.

It appears that the failure occurs too soon. The first thing that
sshd normally logs is a "Accepted publickey" line, but the connection
is closed before authentication. Apparently the admin could only see
my successful connections in the logs.

> If nothing helps, packet-dump both sides (client and server) and find
> out what sent the TCP RST, as that might give you clues for the "why".
> A middlebox might be doing it...
> 
> But get the remote admin to re-check server-side /etc/hosts.allow and
> deny, sshd_config, etc. with an eye on "what might my SSH client be
> using when it failed, and what it might have been using when it worked"
> before all that debugging work.  Don't forget to consider IPv6, or all
> possibly outgoing ranges of IPv4 NAT, if any.  It might pay off :-)

/etc/hosts.allow and /etc/hosts.deny just contain comments.

But if the goal were to reject the connection before authentication,
then the connection should not be accepted in the first place.

Currently the errors have stopped (or are just too rare to reproduce).
If they occur again, more debugging could be done.

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

Re: OpenSSH: cause of random kex_exchange_identification errors?

[Henrique de Moraes Holschuh]

On Wed, 02 Feb 2022, Vincent Lefevre wrote:
> When I want to connect with SSH (ssh/scp) to some machine, I sometimes
> get errors, either
> 
> kex_exchange_identification: Connection closed by remote host
> 
> or
> 
> kex_exchange_identification: read: Connection reset by peer

That's a very early stage of the initial connection, and your SSH client
just noticed the remote server (or some middle box like a firewall, or
oversubscribed NAT gateway) dropped the TCP connection for whatever
reason.

It will be related to the TCP connection itself, and nothing else. IP
protocol family/address/port, or something in the TCP path misbehaving.

The most common reason is that the remote server disliked your IP
address and/or port due to /etc/hosts.allow/deny, firewalling, or
something in sshd_config.  Ensure you check both IPv4 and IPv6.

> The admin of the machine could see nothing particular in the logs.
> He eventually modified the MaxStartups value, but this did not
> solve the issue (but AFAIK, if this were the cause, there would
> have been something about it in the logs). The machine has enough
> available memory.
> 
> Any idea about the possible cause of these random errors?

The debugging needs to be done either in the server side, or on *both*
sides.

If you're using socket-forwarding stuff in the client side, check that.
This is exceedingly rare nowadays, so I doubt it.  Stuff like SOCKS4 or
SOCKS5 TCP proxies.

Find what is actually listening on the TCP socket server-side, it might
not be sshd (interposers like systemd socket activation, xinetd/inetd,
etc).  The logs/access control you need to look at server-side might not
be SSHD's in that case.

If it is sshd, ensure it is actually logging all you need, and carefully
study the logs.

If nothing helps, packet-dump both sides (client and server) and find
out what sent the TCP RST, as that might give you clues for the "why".
A middlebox might be doing it...

But get the remote admin to re-check server-side /etc/hosts.allow and
deny, sshd_config, etc. with an eye on "what might my SSH client be
using when it failed, and what it might have been using when it worked"
before all that debugging work.  Don't forget to consider IPv6, or all
possibly outgoing ranges of IPv4 NAT, if any.  It might pay off :-)

-- 
  Henrique Holschuh

Re: OpenSSH: cause of random kex_exchange_identification errors?

[Vincent Lefevre]

On 2022-02-02 14:21:08 -0500, gene heskett wrote:
> When I change something, like rebooting the rpi4 running my big Sheldon 
> lathe, from debian buster to debian bullseye, the keyfile changes, and I 
> get an explicit error telling me to run ssh-keygen to remove the 
> offending key, which I do, and the next attempt then works as it auto-
> registers the new key.
[...]

I recall that in my case, the error occurs at the very beginning
of the connection, *before* authentication has started.

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

Reusing ssh keys on a new installation, was Re: OpenSSH: cause of random kex_exchange_identification errors?

[David Wright]

On Wed 02 Feb 2022 at 14:28:40 (-0500), Greg Wooledge wrote:
> On Wed, Feb 02, 2022 at 02:21:08PM -0500, gene heskett wrote:
> > When I change something, like rebooting the rpi4 running my big Sheldon 
> > lathe, from debian buster to debian bullseye, the keyfile changes, and I 
> > get an explicit error telling me to run ssh-keygen to remove the 
> > offending key, which I do, [...]
> 
> What *I* would do is copy the host key files from the buster instance
> (the one that your client recognizes as valid) into the bullseye
> instance.  That way, the client will recognize *both* server instances
> as the same host.
> 
> The host keys are in the /etc/ssh/ directory in Debian.  There are
> several files, and they all begin with ssh_host.  Just copy them over
> and make sure the permissions are retained.  (The ones without .pub on
> the end are meant to be private, so they have tighter permissions.)
> 
> If you're not running Debian, but instead are running some perverse
> derivative that changes everything but still calls its releases "buster"
> and "bullseye" in order to maximize confusion, then your host keys might
> be in some other directory.

I do similar, after checking that the keys look as if they were
generated by the same scheme. I do this just after Grub has been
installed on the disk, ie at "Finish the installation". In a shell
on VC2, or another remote ssh connection, I type:

# mount /dev/ /mnt
# cp -ipr /mnt/etc/ssh/s*[by] /target/etc/ssh/
# cp -ipr /mnt/root/.ssh (and most of root's dotfiles) /target/root/

The reason I do this in the d-i is because I typically install
over a ssh connection, and when the machine reboots at the end
and I want to login remotely to finish the configuration, I can
just type (from local's root):

# ssh -X hostname

and I'm in.

To summarise, the upshot is that to install a new system, I visit
the machine to plug in a USB installer stick, boot up from it using
the one-time-boot option, and run these commands:

 │  Choose language │
 │  Configure the keyboard  │
 │  Detect and mount CD-ROM │
 │  Load installer components from CD   │
→ network-console: Continue installation remotely using SSH ←
 │  Detect network hardware │
 │  Configure the network   │
 │  Continue installation remotely using SSH│
  set a password (I use the hostname)

and return to my comfortable chair. I never /have to/ revisit
the target machine again.¹

One other trick: I run the remote installer with:

$ ssh -o GlobalKnownHostsFile=/dev/null -o UserKnownHostsFile=/dev/null 
installer@hostname

which avoids polluting my ~/.ssh/known_hosts with the ephemeral
host key being used by the installer.

¹ unless I want my stick back. (Desktop machines are configured
  with magic-packet wake-up in the BIOS.)

Cheers,
David.

Re: OpenSSH: cause of random kex_exchange_identification errors?

[Greg Wooledge]

On Wed, Feb 02, 2022 at 02:21:08PM -0500, gene heskett wrote:
> When I change something, like rebooting the rpi4 running my big Sheldon 
> lathe, from debian buster to debian bullseye, the keyfile changes, and I 
> get an explicit error telling me to run ssh-keygen to remove the 
> offending key, which I do, [...]

What *I* would do is copy the host key files from the buster instance
(the one that your client recognizes as valid) into the bullseye
instance.  That way, the client will recognize *both* server instances
as the same host.

The host keys are in the /etc/ssh/ directory in Debian.  There are
several files, and they all begin with ssh_host.  Just copy them over
and make sure the permissions are retained.  (The ones without .pub on
the end are meant to be private, so they have tighter permissions.)

If you're not running Debian, but instead are running some perverse
derivative that changes everything but still calls its releases "buster"
and "bullseye" in order to maximize confusion, then your host keys might
be in some other directory.

Re: OpenSSH: cause of random kex_exchange_identification errors?

[gene heskett]

On Wednesday, February 2, 2022 9:44:32 AM EST Vincent Lefevre wrote:
> When I want to connect with SSH (ssh/scp) to some machine, I sometimes
> get errors, either
> 
> kex_exchange_identification: Connection closed by remote host
> 
> or
> 
> kex_exchange_identification: read: Connection reset by peer
> 
> immediately after the connection attempt. This happens randomly,
> and there are some periods where this happens quite often. The
> client machine doesn't seem to matter, and this issue also even
> occurs from machines on the local network.
> 
> With ssh -vvv, the output ends with
> 
> debug1: Local version string SSH-2.0-OpenSSH_8.7p1 Debian-4
> kex_exchange_identification: read: Connection reset by peer
> Connection reset by [...] port 22
> 
> In the source, this corresponds to function kex_exchange_identification
> in kex.c:
> 
> len = atomicio(read, ssh_packet_get_connection_in(ssh),
> , 1);
> if (len != 1 && errno == EPIPE) {
> error_f("Connection closed by remote host");
> r = SSH_ERR_CONN_CLOSED;
> goto out;
> } else if (len != 1) {
> oerrno = errno;
> error_f("read: %.100s", strerror(errno));
> r = SSH_ERR_SYSTEM_ERROR;
> goto out;
> }
> 
> so either with EPIPE or with ECONNRESET, and this apparently occurs
> before the exchange of banners.
> 
> I could reproduce the issue with telnet, which gives
> 
> [...]
> Escape character is '^]'.
> Connection closed by foreign host.
> 
> while one normally has
> 
> SSH-2.0-OpenSSH_7.9p1 Debian-10+deb10u2
> 
> just after the "Escape character..." line.
> 
> Note that this is different from a "Connection refused". Here, the
> connection is accepted, but immediately closed.
> 
> The admin of the machine could see nothing particular in the logs.
> He eventually modified the MaxStartups value, but this did not
> solve the issue (but AFAIK, if this were the cause, there would
> have been something about it in the logs). The machine has enough
> available memory.
> 
> Any idea about the possible cause of these random errors?

When I change something, like rebooting the rpi4 running my big Sheldon 
lathe, from debian buster to debian bullseye, the keyfile changes, and I 
get an explicit error telling me to run ssh-keygen to remove the 
offending key, which I do, and the next attempt then works as it auto-
registers the new key. But this machine is bullseye, and the stretch 
before it, didn't have a self advising failure. The update was forced on 
me, a nearly new 2T main drive died in the night losing everything, so I 
threw money at it and now I'm booting from a 500G SSD, and 4 1T SSD's are 
in a raid10 as /home of 2T capacity. One spinning rust drive remains, 
amanda's morgue. I've put smaller SSD's in all my machines now, and the 
only problem I've had was on the pi where I'm using usb3 to sata cables 
to mount work drives, and an off-brand cable died, replaced the cable wth 
a startech brand and the SSD as good, didn't lose a byte.  They are about 
6x faster than spinning rust, putting new life in old machines. Working 
on that fast storage, I can rebuild a v5.16.2-rt12 realtime preempt-rt 
kernel in armhf flavor for the rpi4 in around 20 minutes.  The first time 
I did that on spinning rust and a rpi3, took 13+ hours. And I'm still 
running that older kernel on a rpi4. With a full xfc4 gui, it runs until 
I cause a power failure by unplugging it.  It has a small ups, and 
because my now passed wife had COPD, needed a dependable oxygen supply, 
there is a 20kw generac in the back yard that starts in about 4 seconds.

FWIW, we've not yet been able to make linuxcnc build on a bullseye 
system, boost::python in the 3.9.2 version of python is a total 
showstopper. The same calls in buster, work fine with python 3.7.

Probably more than you wanted to know.

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

Re: OpenSSH: cause of random kex_exchange_identification errors?

[David Wright]

On Wed 02 Feb 2022 at 15:44:32 (+0100), Vincent Lefevre wrote:
> When I want to connect with SSH (ssh/scp) to some machine, I sometimes
> get errors, either
> 
> kex_exchange_identification: Connection closed by remote host
> 
> or
> 
> kex_exchange_identification: read: Connection reset by peer
> 
> immediately after the connection attempt. This happens randomly,
> and there are some periods where this happens quite often. The
> client machine doesn't seem to matter, and this issue also even
> occurs from machines on the local network.

My only guess about what might be random is whether there's a race
between connectiong via IPv4 and IPv6 (printed earlier in the debug log).

Does one end of any failing connection always involve 8.7p1
(that's from testing, isn't it)?

Does it happen on ports other than 22? (If you're like me, almost
everything I see goes through port 22 at one end or the other.)

Cheers,
David.

Re: OpenSSH: cause of random kex_exchange_identification errors?

[Bijan Soleymani]

On 2022-02-02 09:44, Vincent Lefevre wrote:

In the source, this corresponds to function kex_exchange_identification
in kex.c:

 len = atomicio(read, ssh_packet_get_connection_in(ssh),
 , 1);
 if (len != 1 && errno == EPIPE) {
 error_f("Connection closed by remote host");
 r = SSH_ERR_CONN_CLOSED;
 goto out;
 } else if (len != 1) {
 oerrno = errno;
 error_f("read: %.100s", strerror(errno));
 r = SSH_ERR_SYSTEM_ERROR;
 goto out;
 }

so either with EPIPE or with ECONNRESET, and this apparently occurs
before the exchange of banners.


If you look at the source of atomicio you will see that in this case it 
will do a read() of 1 byte on the file descriptor used for communicating 
with the other side.


atomicio will set errno to EPIPE if 0 bytes are returned on any of the 
reads it does


and it returns the number of bytes read, which will be 0 or 1 in this case.

So the failure modes are 0 bytes read and read didn't return an error 
(EPIPE), or 0 bytes read and read did return an error (read returns -1 
and sets errno to something other than EPIPE).


But I think basically this means that read on the socket fails, or 
basically can't read from the network.


Bijan

Re: OpenSSH: cause of random kex_exchange_identification errors?

[Vincent Lefevre]

On 2022-02-02 16:12:32 +0100, Hans wrote:
> Am Mittwoch, 2. Februar 2022, 15:44:32 CET schrieb Vincent Lefevre:
> Sounds weired. I wonder, if there is a typo. Your message beginning with 
> 
> kex_exchange_identif
> 
> looks for me like a typo. I would have "key_exchange_" expected.

No, that's really kex_ in the OpenSSH source, and I think that it just
means "key exchange" (the "exchange" in kex_exchange_identification is
about identification, as part of the key exchange, if I understand
correctly).

[...]
> Other reasons might be a timing problem on the network. Maybe you
> can take a look with wireshark or similar, if there are network
> problems.

Note that the error is always immediate. So this is not due to packet
loss or something like that.

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

Re: OpenSSH: cause of random kex_exchange_identification errors?

[Hans]

Am Mittwoch, 2. Februar 2022, 15:44:32 CET schrieb Vincent Lefevre:
Sounds weired. I wonder, if there is a typo. Your message beginning with 

kex_exchange_identif

looks for me like a typo. I would have "key_exchange_" expected.

However, I did not check this, and mybe this is correct. 
On the other side, maybe this typo causes (if it is really a typo!) some 
weired behaviour.

As I said, I may be wrong, but this is, what I did see at once.

Other reasons might be a timing problem on the network. Maybe you can take a 
look with wireshark or similar, if there are network problems.

Got this one day on my wireless part, had lots of packets to be recalled, 
which I did only see with wireshark and could not be noticed during normal 
internet use.

Just some ideas.

Does this help? Guess, not really

Best regards

Hans

> When I want to connect with SSH (ssh/scp) to some machine, I sometimes
> get errors, either
> 
> kex_exchange_identification: Connection closed by remote host
> 
> or
> 
> kex_exchange_identification: read: Connection reset by peer
> 
> immediately after the connection attempt. This happens randomly,
> and there are some periods where this happens quite often. The
> client machine doesn't seem to matter, and this issue also even
> occurs from machines on the local network.
> 
> With ssh -vvv, the output ends with
> 
> debug1: Local version string SSH-2.0-OpenSSH_8.7p1 Debian-4
> kex_exchange_identification: read: Connection reset by peer
> Connection reset by [...] port 22
> 
> In the source, this corresponds to function kex_exchange_identification
> in kex.c:
> 
> len = atomicio(read, ssh_packet_get_connection_in(ssh),
> , 1);
> if (len != 1 && errno == EPIPE) {
> error_f("Connection closed by remote host");
> r = SSH_ERR_CONN_CLOSED;
> goto out;
> } else if (len != 1) {
> oerrno = errno;
> error_f("read: %.100s", strerror(errno));
> r = SSH_ERR_SYSTEM_ERROR;
> goto out;
> }
> 
> so either with EPIPE or with ECONNRESET, and this apparently occurs
> before the exchange of banners.
> 
> I could reproduce the issue with telnet, which gives
> 
> [...]
> Escape character is '^]'.
> Connection closed by foreign host.
> 
> while one normally has
> 
> SSH-2.0-OpenSSH_7.9p1 Debian-10+deb10u2
> 
> just after the "Escape character..." line.
> 
> Note that this is different from a "Connection refused". Here, the
> connection is accepted, but immediately closed.
> 
> The admin of the machine could see nothing particular in the logs.
> He eventually modified the MaxStartups value, but this did not
> solve the issue (but AFAIK, if this were the cause, there would
> have been something about it in the logs). The machine has enough
> available memory.
> 
> Any idea about the possible cause of these random errors?

Re: OpenSSH: cause of random kex_exchange_identification errors?

[mick crane]

On 2022-02-02 14:44, Vincent Lefevre wrote:

When I want to connect with SSH (ssh/scp) to some machine, I sometimes
get errors, either

kex_exchange_identification: Connection closed by remote host

or

kex_exchange_identification: read: Connection reset by peer

immediately after the connection attempt. This happens randomly,
and there are some periods where this happens quite often. The
client machine doesn't seem to matter, and this issue also even
occurs from machines on the local network.

With ssh -vvv, the output ends with

debug1: Local version string SSH-2.0-OpenSSH_8.7p1 Debian-4
kex_exchange_identification: read: Connection reset by peer
Connection reset by [...] port 22

In the source, this corresponds to function kex_exchange_identification
in kex.c:

len = atomicio(read, ssh_packet_get_connection_in(ssh),
, 1);
if (len != 1 && errno == EPIPE) {
error_f("Connection closed by remote host");
r = SSH_ERR_CONN_CLOSED;
goto out;
} else if (len != 1) {
oerrno = errno;
error_f("read: %.100s", strerror(errno));
r = SSH_ERR_SYSTEM_ERROR;
goto out;
}

so either with EPIPE or with ECONNRESET, and this apparently occurs
before the exchange of banners.

I could reproduce the issue with telnet, which gives

[...]
Escape character is '^]'.
Connection closed by foreign host.

while one normally has

SSH-2.0-OpenSSH_7.9p1 Debian-10+deb10u2

just after the "Escape character..." line.

Note that this is different from a "Connection refused". Here, the
connection is accepted, but immediately closed.

The admin of the machine could see nothing particular in the logs.
He eventually modified the MaxStartups value, but this did not
solve the issue (but AFAIK, if this were the cause, there would
have been something about it in the logs). The machine has enough
available memory.

Any idea about the possible cause of these random errors?



I don't know what kex_exchange is but perhaps you have more than one 
entry/description for the remote machine in known_hosts or something and 
there's a bit of pot luck.


mick
--
Key ID4BFEBB31

Re: openssh server remote access

[Daryl]

On Thu, 21 Oct 2021 15:26:21 -0700
dmacdoug  wrote:
 
> 
> Assuming your sshd server is on a computer attached 
> to a router which is your gateway to the internet, and 
> the router is set to forward port 22 to that computer
> some ISP's don't route port 22 traffic.  I know that 
> AT blocks port 22 traffic and it gives that message.  
> I set the sshd server to listen on port 26 instead and 
> it works fine.
> 
> Don MacDougall
> 

I'm on AT fiber and nothing is blocked. Well to be honest I haven't
tried 25 outbound but safe assumption that one is closed.

Re: openssh server remote access

[Andrei POPESCU]

On Sb, 23 oct 21, 09:33:44, Joe wrote:
> 
> The ssh protocol by default works on TCP port 22, but the sshd (server)
> configuration file allows different ports to be specified. If you have
> port 22 open to the Internet, you will get many firewall logs for
> people trying brute-force password attacks, which tells you why you
> should be using keys. Using a different port won't be any more secure,
> but it will stop these logs.

I've seen such brute-force attacks[1] also on different ports, they are
just much rarer.

The simple (temporary) solution for me was to reboot the router so it 
gets a different IP from the ISP. Long term I should probably look into 
something like fail2ban and/or port knocking.
 
> Wherever you want to connect from must have a clear path to the ssh
> port of your server. If you want to connect across the Internet, then
> your Internet router must forward the ssh port to the server computer.
> How to do this is specific to each model of router, but it's usually
> easy to work out. It will ask for an incoming protocol (TCP) and port
> number, the IP address of the destination computer in your network, and
> sometimes a destination port. In the latter case, you can still use
> port 22 on the server but accept something else entirely from over the
> Net.

My recommendation as well, as I prefer to run with defaults whenever 
possible. If already configuring a port forwarding in the router it's 
easy to use a different port on the public face of the router and keep 
the SSH server at its default.

It also makes local SSH connections much easier as it's not necessary to 
reconfigure each client for each host.

[1] The attacks didn't get past guessing an existing user name, even 
though one is a common English word and one is a Romanian given name :D

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser


signature.asc
Description: PGP signature

Re: openssh server remote access

[Joe]

On Sat, 23 Oct 2021 08:42:09 +0300
Semih Ozlem  wrote:

> Are there specific tutorials websites that you can recommend, how
> about port forwarding. From where which sites in particular can I
> learn about these topics?

Here's a good practical guide:

https://www.digitalocean.com/community/tutorials/how-to-set-up-ssh-keys-2

This site generally isn't specific to Debian, but it has lots of useful
tutorials. The Arch Linux site is also good for documentation.

Here is the ultimate authority, but it may contain too much detail for
a beginner. These are the client and server configuration files, which
are commented, but there's more detail here:

https://www.ssh.com/academy/ssh/config
https://www.ssh.com/academy/ssh/sshd_config

Mostly the default configuration files are OK, you may want to change
the port number or disable passwords. Most of the insecure options are
already disabled.

> 
> Joe , 22 Eki 2021 Cum, 00:08 tarihinde şunu yazdı:
> 
> > On Thu, 21 Oct 2021 23:48:38 +0300
> > Semih Ozlem  wrote:
> >  
> > > I think it was something like "ssh: connect to host  port 22:
> > > Connection refused" It will take me a little while to get the same
> > > error message again.

The ssh protocol by default works on TCP port 22, but the sshd (server)
configuration file allows different ports to be specified. If you have
port 22 open to the Internet, you will get many firewall logs for
people trying brute-force password attacks, which tells you why you
should be using keys. Using a different port won't be any more secure,
but it will stop these logs.

Wherever you want to connect from must have a clear path to the ssh
port of your server. If you want to connect across the Internet, then
your Internet router must forward the ssh port to the server computer.
How to do this is specific to each model of router, but it's usually
easy to work out. It will ask for an incoming protocol (TCP) and port
number, the IP address of the destination computer in your network, and
sometimes a destination port. In the latter case, you can still use
port 22 on the server but accept something else entirely from over the
Net. If the ssh server computer has a firewall, then it must have the
relevant port opened, which again will be specific to the software you
use for the firewall.
 

Re: openssh server remote access

[Semih Ozlem]

Are there specific tutorials websites that you can recommend, how about
port forwarding. From where which sites in particular can I learn about
these topics?

Joe , 22 Eki 2021 Cum, 00:08 tarihinde şunu yazdı:

> On Thu, 21 Oct 2021 23:48:38 +0300
> Semih Ozlem  wrote:
>
> > I think it was something like "ssh: connect to host  port 22:
> > Connection refused" It will take me a little while to get the same
> > error message again.
> >
> >
>
> Ideally you need to do more than open the ssh port, particularly if you
> intend to connect from the Internet. ssh is one of the most commonly
> attacked services, for obvious reasons.
>
> You need a tutorial on setting up ssh with keys, and disabling password
> access. There are many such on the Net.
>
>
> --
> Joe
>
>

Re: openssh server remote access

[Eric S Fraga]

On Friday, 22 Oct 2021 at 09:46, David Wright wrote:
> I'm guessing it was a BT Home Hub. 

EE *before* bought by BT but maybe same supplier even then.

> One might suspect that 100 lies at the lower boundary of its DHCP
> range, leaving 99 static addresses free. But no guess at a product.

I cannot remember any longer which one supplied this one.  Might have
been Tiscali?

And, yes, leaving 99 static addresses free might be a reason.


-- 
Eric S Fraga via Emacs 28.0.60 & org 9.5 on Debian 11.1

Re: openssh server remote access

[David Wright]

On Fri 22 Oct 2021 at 11:59:40 (+0100), Eric S Fraga wrote:
> On Friday, 22 Oct 2021 at 13:40, Andrei POPESCU wrote:
> > Typically modems and home routers use the .1 address for themselves.
> 
> Interesting.  My last 2 routers have had *.254 (!)

I'm guessing it was a BT Home Hub. It's idiosyncratic, but setting
itself to the highest address is as logical as the lowest, is it not.

> and *.100 as their address. 

One might suspect that 100 lies at the lower boundary of its DHCP
range, leaving 99 static addresses free. But no guess at a product.

Cheers,
David.

Re: openssh server remote access

[Eric S Fraga]

On Friday, 22 Oct 2021 at 13:40, Andrei POPESCU wrote:
> Typically modems and home routers use the .1 address for themselves.

Interesting.  My last 2 routers have had *.254 (!) and *.100 as their
address. 

-- 
Eric S Fraga via Emacs 28.0.60 & org 9.5 on Debian 11.1

Re: openssh server remote access

[Andrei POPESCU]

On Jo, 21 oct 21, 22:52:37, Semih Ozlem wrote:
> I am unable to access my modem settings page when writing 192.168.1.100 to
> check if there is a firewall.

Are you sure this is the correct address? How did you establish that?

Typically modems and home routers use the .1 address for themselves.

Even if the firewall is disabled on the modem (it shouldn't be, and you 
should probably leave it enabled), systems connecting to the internet 
via the modem are usually inaccessible from the internet.

To connect to them from the internet you need a "port forwarding".

https://en.wikipedia.org/wiki/Port_forwarding

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser


signature.asc
Description: PGP signature

Re: openssh server remote access

[James B]

That's 'systemctl status ssh' without the 1) of course.I meant to put more 
steps but decided not to

-- 
  James B
  portoteache...@fastmail.com

Em Sex, 22 Out ʼ21, às 00:18, James B escreveu:
> Hi Semih,
>
> In my opinion, I would go back to basics first.You may have installed 
> openssh but it doesn't necessarily run by default (for reasons that 
> will make sense when you look at it further).Do you know how to start 
> systemd services? It looks to me like your ssh server isnt' running.So, 
> run (with sudo privileges or root and presuming you're on a normal 
> variant of Debian and not one with an alternative init system such as 
> SysV)
>
> 1) systemctl status ssh
>
> Post the result please
>
> JB
>
> -- 
>   James B
>   portoteache...@fastmail.com
>
> Em Sex, 22 Out ʼ21, às 00:05, David escreveu:
>> On Fri, 22 Oct 2021 at 09:53, Semih Ozlem  
>> wrote:
>>
>>> From:Semih Ozlem 
>>> To:Debian Users , 
>>> ubuntu-us...@lists.ubuntu.com
>>
>> Please, do not send individual messages to more than one
>> mailing list.
>>
>> It is rather unfriendly to everyone else that reads each list, because
>> we do not see any conversation that occurs on the other mailing list.
>>
>> Please confine any conversations that you have, on any mailing list,
>> entirely to that one mailing list. Sure, you can ask the same question
>> on multiple mailing lists at the same time, but please keep them
>> as separate conversations.

Re: openssh server remote access

[James B]

Hi Semih,

In my opinion, I would go back to basics first.You may have installed openssh 
but it doesn't necessarily run by default (for reasons that will make sense 
when you look at it further).Do you know how to start systemd services? It 
looks to me like your ssh server isnt' running.So, run (with sudo privileges or 
root and presuming you're on a normal variant of Debian and not one with an 
alternative init system such as SysV)

1) systemctl status ssh

Post the result please

JB

-- 
  James B
  portoteache...@fastmail.com

Em Sex, 22 Out ʼ21, às 00:05, David escreveu:
> On Fri, 22 Oct 2021 at 09:53, Semih Ozlem  
> wrote:
>
>> From:Semih Ozlem 
>> To:Debian Users , ubuntu-us...@lists.ubuntu.com
>
> Please, do not send individual messages to more than one
> mailing list.
>
> It is rather unfriendly to everyone else that reads each list, because
> we do not see any conversation that occurs on the other mailing list.
>
> Please confine any conversations that you have, on any mailing list,
> entirely to that one mailing list. Sure, you can ask the same question
> on multiple mailing lists at the same time, but please keep them
> as separate conversations.

Re: openssh server remote access

[David]

On Fri, 22 Oct 2021 at 09:53, Semih Ozlem  wrote:

> From:Semih Ozlem 
> To:Debian Users , ubuntu-us...@lists.ubuntu.com

Please, do not send individual messages to more than one
mailing list.

It is rather unfriendly to everyone else that reads each list, because
we do not see any conversation that occurs on the other mailing list.

Please confine any conversations that you have, on any mailing list,
entirely to that one mailing list. Sure, you can ask the same question
on multiple mailing lists at the same time, but please keep them
as separate conversations.

Re: openssh server remote access

[Semih Ozlem]

I am unable to access my modem settings page when writing 192.168.1.100 to
check if there is a firewall.

Below is the web page that I get


Unable to connect

Firefox can’t establish a connection to the server at 192.168.1.100.

The site could be temporarily unavailable or too busy. Try again in a
few moments.
If you are unable to load any pages, check your computer’s network
connection.
If your computer or network is protected by a firewall or proxy, make
sure that Firefox is permitted to access the Web.

Any ideas?

Greg Wooledge , 21 Eki 2021 Per, 21:32 tarihinde şunu
yazdı:

> On Thu, Oct 21, 2021 at 09:07:02PM +, Semih Ozlem wrote:
> > Yes the error message is
> >
> > ssh: connect to host (ip address of remote host) port 22: Connection
> refused
>
> This message means one of these things:
>
> 1) The sshd process is not running, or is not listening on the default
> port.
>
> 2) A firewall is preventing your connection.
>
>
> You would normally check the first thing by using "ss" or "netstat" on
> the server, and verifying that the process is indeed LISTEN-ing on the
> expected interface(s) and port.  For example:
>
> unicorn:~$ ss -ant | grep :22
> LISTEN0  128  0.0.0.0:22 0.0.0.0:*
> [...]
>
> This tells me that something is listning on port 22 on all IPv4 interfaces.
>
> If you don't see a line like this, then you need to investigate the ssh
> service more deeply.  Perhaps start by running "journalctl -u ssh" to
> read its logs.
>
> If you *do* see a line like this, then you need to look at network-level
> stuff, like firewalls, routers, and so on.
>
>

Re: openssh server remote access

[dmacdoug]

On Thu, Oct 21, 2021 at 11:41:43PM +0300, Semih Ozlem wrote:
> Hi everyone,
> 
> I set up an openssh server and I am trying to access that machine remotely
> (not from the local network. but from another ip address). I get an error
> (something about port 22). What setting needs to be checked and what needs
> to be done on the machine that openssh server is running and on the router
> that machine is connected to, so that openssh server can be accessed
> remotely?
> 
> Thank you
> 
> Semih Ozlem

Assuming your sshd server is on a computer attached 
to a router which is your gateway to the internet, and 
the router is set to forward port 22 to that computer
some ISP's don't route port 22 traffic.  I know that 
AT blocks port 22 traffic and it gives that message.  
I set the sshd server to listen on port 26 instead and 
it works fine.

Don MacDougall

Re: openssh server remote access

[Greg Wooledge]

On Thu, Oct 21, 2021 at 09:07:02PM +, Semih Ozlem wrote:
> Yes the error message is
> 
> ssh: connect to host (ip address of remote host) port 22: Connection refused

This message means one of these things:

1) The sshd process is not running, or is not listening on the default port.

2) A firewall is preventing your connection.


You would normally check the first thing by using "ss" or "netstat" on
the server, and verifying that the process is indeed LISTEN-ing on the
expected interface(s) and port.  For example:

unicorn:~$ ss -ant | grep :22
LISTEN0  128  0.0.0.0:22 0.0.0.0:*
[...]

This tells me that something is listning on port 22 on all IPv4 interfaces.

If you don't see a line like this, then you need to investigate the ssh
service more deeply.  Perhaps start by running "journalctl -u ssh" to
read its logs.

If you *do* see a line like this, then you need to look at network-level
stuff, like firewalls, routers, and so on.

Re: openssh server remote access

[Joe]

On Thu, 21 Oct 2021 23:48:38 +0300
Semih Ozlem  wrote:

> I think it was something like "ssh: connect to host  port 22:
> Connection refused" It will take me a little while to get the same
> error message again.
> 
>

Ideally you need to do more than open the ssh port, particularly if you
intend to connect from the Internet. ssh is one of the most commonly
attacked services, for obvious reasons.

You need a tutorial on setting up ssh with keys, and disabling password
access. There are many such on the Net.


-- 
Joe

Re: openssh server remote access

[Semih Ozlem]

Yes the error message is

ssh: connect to host (ip address of remote host) port 22: Connection refused



Semih Ozlem , 21 Eki 2021 Per, 20:48
tarihinde şunu yazdı:

> I think it was something like "ssh: connect to host  port 22:
> Connection refused" It will take me a little while to get the same error
> message again.
>
> James B , 21 Eki 2021 Per, 23:45 tarihinde
> şunu yazdı:
>
>> Hi Semih,
>>
>> Could you post the exact wording of the error message please?
>>
>> Best
>>
>> JB
>>
>> --
>>   James B
>>   portoteache...@fastmail.com
>>
>>
>>
>> Em Qui, 21 Out ʼ21, às 21:41, Semih Ozlem escreveu:
>>
>> Hi everyone,
>>
>> I set up an openssh server and I am trying to access that machine
>> remotely (not from the local network. but from another ip address). I get
>> an error (something about port 22). What setting needs to be checked and
>> what needs to be done on the machine that openssh server is running and on
>> the router that machine is connected to, so that openssh server can be
>> accessed remotely?
>>
>> Thank you
>>
>> Semih Ozlem
>>
>>
>>

Re: openssh server remote access

[Semih Ozlem]

I think it was something like "ssh: connect to host  port 22:
Connection refused" It will take me a little while to get the same error
message again.

James B , 21 Eki 2021 Per, 23:45 tarihinde
şunu yazdı:

> Hi Semih,
>
> Could you post the exact wording of the error message please?
>
> Best
>
> JB
>
> --
>   James B
>   portoteache...@fastmail.com
>
>
>
> Em Qui, 21 Out ʼ21, às 21:41, Semih Ozlem escreveu:
>
> Hi everyone,
>
> I set up an openssh server and I am trying to access that machine remotely
> (not from the local network. but from another ip address). I get an error
> (something about port 22). What setting needs to be checked and what needs
> to be done on the machine that openssh server is running and on the router
> that machine is connected to, so that openssh server can be accessed
> remotely?
>
> Thank you
>
> Semih Ozlem
>
>
>

Re: openssh server remote access

[James B]

Hi Semih,

Could you post the exact wording of the error message please?

Best

JB

-- 
  James B
  portoteache...@fastmail.com



Em Qui, 21 Out ʼ21, às 21:41, Semih Ozlem escreveu:
> Hi everyone,
> 
> I set up an openssh server and I am trying to access that machine remotely 
> (not from the local network. but from another ip address). I get an error 
> (something about port 22). What setting needs to be checked and what needs to 
> be done on the machine that openssh server is running and on the router that 
> machine is connected to, so that openssh server can be accessed remotely?
> 
> Thank you
> 
> Semih Ozlem

Re: openssh-server

[Greg Wooledge]

On Mon, Aug 17, 2020 at 09:31:20PM +0300, Semih Ozlem wrote:
> Hi Greg,
> Sorry for lack of details in my response, it was just a tiring day because
> almost the whole day passed and finally the issue is at least temporarily
> resolved, and one gets somewhat forgetful. the firewall was enabled on the
> debian machine, and I am trying to connect to the debian machine from
> windows machine. After disabling firewall in debian machine ssh connection
> from the windows machine to debian machine (where the ssh server is
> located) works. However, I presume that disabling firewall makes the
> machine vulnerable, so this is not entirely a good solution. I am just
> reading firewall rules to set up firewall so that ssh connection would be
> allowed. Apologies if this is too simple a question.

There is no firewall in Debian by default.  Any firewall rules you have
are ones that *you* put in place, using software that *you* installed
and configured.

So, configure it the way you want.

Re: openssh-server

[Semih Ozlem]

Hi Greg,
Sorry for lack of details in my response, it was just a tiring day because
almost the whole day passed and finally the issue is at least temporarily
resolved, and one gets somewhat forgetful. the firewall was enabled on the
debian machine, and I am trying to connect to the debian machine from
windows machine. After disabling firewall in debian machine ssh connection
from the windows machine to debian machine (where the ssh server is
located) works. However, I presume that disabling firewall makes the
machine vulnerable, so this is not entirely a good solution. I am just
reading firewall rules to set up firewall so that ssh connection would be
allowed. Apologies if this is too simple a question.


Greg Wooledge , 17 Ağu 2020 Pzt, 21:17 tarihinde şunu
yazdı:

> On Mon, Aug 17, 2020 at 08:12:32PM +0200, john doe wrote:
> > On 8/17/2020 8:04 PM, Semih Ozlem wrote:
> > > And thanks to Greg for the quick response.
> > >
> > > Semih Ozlem , 17 Ağu 2020 Pzt, 21:03
> > > tarihinde şunu yazdı:
> > >
> > > > Sorry for the trailing list of emails, I just realized the firewall
> was
> > > > preventing the connection. After disabling ssh connection works.
> However I
> > > > would like to ask how I can configure firewall so that I can have ssh
> > > > working, instead of simply disabling it.
> > > >
> >
> > Per default SSH uses port '22' with the protocol 'tcp'.
> >
> > So you need to open that inbound port!
>
> I'm guessing the issue was the *outbound* connection on the client, and
> that the firewall in question is on the Windows client.
>
> It's amazing how many emails this person sends and how incredibly lacking
> in detail each one is.
>
>

Re: openssh-server

[john doe]

On 8/17/2020 8:15 PM, Semih Ozlem wrote:

Sorry for the maybe too simple question, but how does one open and close
ports, and how can ufw firewall be configured so as to allow ssh
connections



Have a look at (1).

In the linux world, it is wise to answer at the bottom of an e-mail as
opposed to the Windows world where top-posting is used.

1)
https://www.digitalocean.com/community/tutorials/ufw-essentials-common-firewall-rules-and-commands


--
John Doe

Re: openssh-server

[Greg Wooledge]

On Mon, Aug 17, 2020 at 08:12:32PM +0200, john doe wrote:
> On 8/17/2020 8:04 PM, Semih Ozlem wrote:
> > And thanks to Greg for the quick response.
> > 
> > Semih Ozlem , 17 Ağu 2020 Pzt, 21:03
> > tarihinde şunu yazdı:
> > 
> > > Sorry for the trailing list of emails, I just realized the firewall was
> > > preventing the connection. After disabling ssh connection works. However I
> > > would like to ask how I can configure firewall so that I can have ssh
> > > working, instead of simply disabling it.
> > > 
> 
> Per default SSH uses port '22' with the protocol 'tcp'.
> 
> So you need to open that inbound port!

I'm guessing the issue was the *outbound* connection on the client, and
that the firewall in question is on the Windows client.

It's amazing how many emails this person sends and how incredibly lacking
in detail each one is.

Re: openssh-server

[john doe]

On 8/17/2020 8:04 PM, Semih Ozlem wrote:

And thanks to Greg for the quick response.

Semih Ozlem , 17 Ağu 2020 Pzt, 21:03
tarihinde şunu yazdı:


Sorry for the trailing list of emails, I just realized the firewall was
preventing the connection. After disabling ssh connection works. However I
would like to ask how I can configure firewall so that I can have ssh
working, instead of simply disabling it.



Per default SSH uses port '22' with the protocol 'tcp'.

So you need to open that inbound port!

--
John Doe

Re: openssh-server

[Semih Ozlem]

And thanks to Greg for the quick response.

Semih Ozlem , 17 Ağu 2020 Pzt, 21:03
tarihinde şunu yazdı:

> Sorry for the trailing list of emails, I just realized the firewall was
> preventing the connection. After disabling ssh connection works. However I
> would like to ask how I can configure firewall so that I can have ssh
> working, instead of simply disabling it.
>
> Semih Ozlem , 17 Ağu 2020 Pzt, 21:00
> tarihinde şunu yazdı:
>
>> also pinging works
>>
>> Semih Ozlem , 17 Ağu 2020 Pzt, 20:59
>> tarihinde şunu yazdı:
>>
>>> Regarding previous question on ssh server
>>> Both machines are in the same home network, connected to the internet
>>> through modem.
>>> One machine is running on windows the other on debian. (I tried running
>>> the windows machine from debian as well and that did not work either.)
>>> When I run localhost on the debian machine, the openssh-server is
>>> running, and can connect to it from the same machine.
>>> When I run openssh-server on the windows machine, I am able to connect
>>> to it from debian.
>>> When I run openssh-server from debian, I am not able to connect to it
>>> from the other machine regardless of it working as a windows or debian
>>> machine.
>>>
>>>
>>> Greg Wooledge , 17 Ağu 2020 Pzt, 20:53 tarihinde
>>> şunu yazdı:
>>>
 On Mon, Aug 17, 2020 at 08:49:11PM +0300, Semih Ozlem wrote:
 > I am trying to connect to a debian machine with openssh-server
 installed.
 > When I try to connect, I get the message "connection timed out". I am
 not
 > sure if this group is the right place to address this issue, but is
 there a
 > configuration file that needs to be adjusted to fix the issue. What
 is the
 > right place to address this question to

 Test locally first: does "ssh localhost" work on the Debian system?  If
 so, then you know the service is running and working.

 Test next from another host on the same LAN as the Debian system.  If
 that works, then you know there's no firewall preventing access to the
 Debian system from the LAN.

 Then test from outside the LAN.

 You've given no details.  How are the client and the server connected?
 What command are you running on the client?  Specifically, what hostname
 or IP address are you using on the client?  If it's a hostname, is DNS
 resolving it correctly?  Are you able to ping the Debian system from the
 client?

Re: openssh-server

[Semih Ozlem]

Sorry for the trailing list of emails, I just realized the firewall was
preventing the connection. After disabling ssh connection works. However I
would like to ask how I can configure firewall so that I can have ssh
working, instead of simply disabling it.

Semih Ozlem , 17 Ağu 2020 Pzt, 21:00
tarihinde şunu yazdı:

> also pinging works
>
> Semih Ozlem , 17 Ağu 2020 Pzt, 20:59
> tarihinde şunu yazdı:
>
>> Regarding previous question on ssh server
>> Both machines are in the same home network, connected to the internet
>> through modem.
>> One machine is running on windows the other on debian. (I tried running
>> the windows machine from debian as well and that did not work either.)
>> When I run localhost on the debian machine, the openssh-server is
>> running, and can connect to it from the same machine.
>> When I run openssh-server on the windows machine, I am able to connect to
>> it from debian.
>> When I run openssh-server from debian, I am not able to connect to it
>> from the other machine regardless of it working as a windows or debian
>> machine.
>>
>>
>> Greg Wooledge , 17 Ağu 2020 Pzt, 20:53 tarihinde
>> şunu yazdı:
>>
>>> On Mon, Aug 17, 2020 at 08:49:11PM +0300, Semih Ozlem wrote:
>>> > I am trying to connect to a debian machine with openssh-server
>>> installed.
>>> > When I try to connect, I get the message "connection timed out". I am
>>> not
>>> > sure if this group is the right place to address this issue, but is
>>> there a
>>> > configuration file that needs to be adjusted to fix the issue. What is
>>> the
>>> > right place to address this question to
>>>
>>> Test locally first: does "ssh localhost" work on the Debian system?  If
>>> so, then you know the service is running and working.
>>>
>>> Test next from another host on the same LAN as the Debian system.  If
>>> that works, then you know there's no firewall preventing access to the
>>> Debian system from the LAN.
>>>
>>> Then test from outside the LAN.
>>>
>>> You've given no details.  How are the client and the server connected?
>>> What command are you running on the client?  Specifically, what hostname
>>> or IP address are you using on the client?  If it's a hostname, is DNS
>>> resolving it correctly?  Are you able to ping the Debian system from the
>>> client?
>>>
>>>

Re: openssh-server

[Semih Ozlem]

also pinging works

Semih Ozlem , 17 Ağu 2020 Pzt, 20:59
tarihinde şunu yazdı:

> Regarding previous question on ssh server
> Both machines are in the same home network, connected to the internet
> through modem.
> One machine is running on windows the other on debian. (I tried running
> the windows machine from debian as well and that did not work either.)
> When I run localhost on the debian machine, the openssh-server is running,
> and can connect to it from the same machine.
> When I run openssh-server on the windows machine, I am able to connect to
> it from debian.
> When I run openssh-server from debian, I am not able to connect to it from
> the other machine regardless of it working as a windows or debian machine.
>
>
> Greg Wooledge , 17 Ağu 2020 Pzt, 20:53 tarihinde
> şunu yazdı:
>
>> On Mon, Aug 17, 2020 at 08:49:11PM +0300, Semih Ozlem wrote:
>> > I am trying to connect to a debian machine with openssh-server
>> installed.
>> > When I try to connect, I get the message "connection timed out". I am
>> not
>> > sure if this group is the right place to address this issue, but is
>> there a
>> > configuration file that needs to be adjusted to fix the issue. What is
>> the
>> > right place to address this question to
>>
>> Test locally first: does "ssh localhost" work on the Debian system?  If
>> so, then you know the service is running and working.
>>
>> Test next from another host on the same LAN as the Debian system.  If
>> that works, then you know there's no firewall preventing access to the
>> Debian system from the LAN.
>>
>> Then test from outside the LAN.
>>
>> You've given no details.  How are the client and the server connected?
>> What command are you running on the client?  Specifically, what hostname
>> or IP address are you using on the client?  If it's a hostname, is DNS
>> resolving it correctly?  Are you able to ping the Debian system from the
>> client?
>>
>>

Re: openssh-server

[Semih Ozlem]

Regarding previous question on ssh server
Both machines are in the same home network, connected to the internet
through modem.
One machine is running on windows the other on debian. (I tried running the
windows machine from debian as well and that did not work either.)
When I run localhost on the debian machine, the openssh-server is running,
and can connect to it from the same machine.
When I run openssh-server on the windows machine, I am able to connect to
it from debian.
When I run openssh-server from debian, I am not able to connect to it from
the other machine regardless of it working as a windows or debian machine.


Greg Wooledge , 17 Ağu 2020 Pzt, 20:53 tarihinde şunu
yazdı:

> On Mon, Aug 17, 2020 at 08:49:11PM +0300, Semih Ozlem wrote:
> > I am trying to connect to a debian machine with openssh-server installed.
> > When I try to connect, I get the message "connection timed out". I am not
> > sure if this group is the right place to address this issue, but is
> there a
> > configuration file that needs to be adjusted to fix the issue. What is
> the
> > right place to address this question to
>
> Test locally first: does "ssh localhost" work on the Debian system?  If
> so, then you know the service is running and working.
>
> Test next from another host on the same LAN as the Debian system.  If
> that works, then you know there's no firewall preventing access to the
> Debian system from the LAN.
>
> Then test from outside the LAN.
>
> You've given no details.  How are the client and the server connected?
> What command are you running on the client?  Specifically, what hostname
> or IP address are you using on the client?  If it's a hostname, is DNS
> resolving it correctly?  Are you able to ping the Debian system from the
> client?
>
>

Re: openssh-server

[Greg Wooledge]

On Mon, Aug 17, 2020 at 08:49:11PM +0300, Semih Ozlem wrote:
> I am trying to connect to a debian machine with openssh-server installed.
> When I try to connect, I get the message "connection timed out". I am not
> sure if this group is the right place to address this issue, but is there a
> configuration file that needs to be adjusted to fix the issue. What is the
> right place to address this question to

Test locally first: does "ssh localhost" work on the Debian system?  If
so, then you know the service is running and working.

Test next from another host on the same LAN as the Debian system.  If
that works, then you know there's no firewall preventing access to the
Debian system from the LAN.

Then test from outside the LAN.

You've given no details.  How are the client and the server connected?
What command are you running on the client?  Specifically, what hostname
or IP address are you using on the client?  If it's a hostname, is DNS
resolving it correctly?  Are you able to ping the Debian system from the
client?

Re: OpenSSH not closing idle sessions.

[Thomas Pircher]

Greg Wooledge wrote:
>
> I suggest reading what ClientAliveCountMax and ClientAliveInterval
> actually do in sshd_config(5).  Take particular note of the word
> "unresponsive".  It is not the same as "idle".

Yes, you are right, this setting won't disconnect idle sessions. So I
guess it's mostly useful to clean up server resources.

Thomas

Re: OpenSSH not closing idle sessions.

[mick crane]

On 2019-04-08 18:25, timothylegg wrote:



Ideas?
I've not really used screen but isn't it that you want to start where 
you left off ?


mick


--
Key ID4BFEBB31

Re: OpenSSH not closing idle sessions.

[Greg Wooledge]

On Tue, Apr 09, 2019 at 04:01:20PM +0100, Thomas Pircher wrote:
> > > ClientAliveInterval 5
> 
> This is the setting that the STIG ID RHEL-07-040320 in [2] suggests to
> edit.
> 
> Thomas
> 
> [1] https://iase.disa.mil/stigs
> [2] 
> https://rhel7stig.readthedocs.io/en/latest/medium.html#v-72237-all-network-connections-associated-with-ssh-traffic-must-terminate-at-the-end-of-the-session-or-after-10-minutes-of-inactivity-except-to-fulfill-documented-and-validated-mission-requirements-rhel-07-040320

Pathetic.

I suggest reading what ClientAliveCountMax and ClientAliveInterval
actually do in sshd_config(5).  Take particular note of the word
"unresponsive".  It is not the same as "idle".

Re: OpenSSH not closing idle sessions.

[Thomas Pircher]

Greg Wooledge wrote:
> Most people want the exact opposite of that.

I don't really know the OP's rationale, but terminating an idle ssh
session is a step in the requirements/guidelines (STIG [1]) for
hardening systems for the US Department of Defense.

> Basically, what you're asking for is directly hostile to any kind of
> sane operation of a computer.

I'm not going to defend this requirement, merely showing one example
where one would want (or would have to) configure the ssh server this
way.

> > ClientAliveInterval 5

This is the setting that the STIG ID RHEL-07-040320 in [2] suggests to
edit.

Thomas

[1] https://iase.disa.mil/stigs
[2] 
https://rhel7stig.readthedocs.io/en/latest/medium.html#v-72237-all-network-connections-associated-with-ssh-traffic-must-terminate-at-the-end-of-the-session-or-after-10-minutes-of-inactivity-except-to-fulfill-documented-and-validated-mission-requirements-rhel-07-040320

Re: OpenSSH not closing idle sessions.

[David Wright]

On Mon 08 Apr 2019 at 13:39:36 (-0400), Greg Wooledge wrote:
> On Mon, Apr 08, 2019 at 12:25:28PM -0500, timothylegg wrote:
> > I need to have the session expire and the ssh client terminate after
> > an idle time.
> 
> Most people want the exact opposite of that.
> 
> Basically, what you're asking for is directly hostile to any kind of
> sane operation of a computer.

The first thought that crossed my mind when I read the OP was a
teletype clattering out the message "FIVE MINUTE WARNING".
Expiration was, of course, standard practice when interactive sessions
were a scarce resource that required reclaiming after, say, ten
minutes of inactivity. How times change.

Of course we all hated it. One of the advantages of the old KSR33s
was this audible wake-up call when debugging was taking a little
longer than you expected. After they were replaced by "glass"
teletypes, you'd turn your attention back to the screen only to
find ten minutes had passed and you were logged off. With something
like four times as many terminals as sessions, it could take a while
to get back on at busy times of the day.

Cheers,
David.

Re: OpenSSH not closing idle sessions.

[Dan Ritter]

Richard Hector wrote: 
> On 9/04/19 12:14 PM, timothylegg wrote:
> > I have two residences and one
> > has a port forwarding issue.  I want to make an SSH tunnel to the
> > other site.  If I am at one place for multiple weeks, it's asking too
> > much for the SSH tunnel to stay live that long (I've seen many
> > complaints of SSH connections dropping).  I want to put it on a
> > periodic cron job, but if I don't answer into the tunnel within 30
> > minutes, it becomes idle and drops off.  Every hour a new tunnel is
> > initiated.  The old session must either be closed or expire else I'll
> > have multiple SSH sessions live simultaneously.
> 
> Have you considered using a VPN instead of SSH tunnelling?
> 
> Eg I have OpenVPN set up to my parents' place, so that I can do
> (automatic) backups of their system.
> 
> I did run into issues with address space conflicts (I can't renumber
> either end), so in the end I did it all with IPv6, but you might not
> need that.

If you love SSH: autossh.

If you want the easiest VPN config: wireguard (currently available
only in unstable, but known to work in stable)

-dsr-

Re: OpenSSH not closing idle sessions.

[Richard Hector]

On 9/04/19 12:14 PM, timothylegg wrote:
> I have two residences and one
> has a port forwarding issue.  I want to make an SSH tunnel to the
> other site.  If I am at one place for multiple weeks, it's asking too
> much for the SSH tunnel to stay live that long (I've seen many
> complaints of SSH connections dropping).  I want to put it on a
> periodic cron job, but if I don't answer into the tunnel within 30
> minutes, it becomes idle and drops off.  Every hour a new tunnel is
> initiated.  The old session must either be closed or expire else I'll
> have multiple SSH sessions live simultaneously.

Have you considered using a VPN instead of SSH tunnelling?

Eg I have OpenVPN set up to my parents' place, so that I can do
(automatic) backups of their system.

I did run into issues with address space conflicts (I can't renumber
either end), so in the end I did it all with IPv6, but you might not
need that.

Richard



signature.asc
Description: OpenPGP digital signature

Re: OpenSSH not closing idle sessions.

[Kushal Kumaran]

timothylegg  writes:

> I'm the only user that will be angry at being disconnected.  There is
> no easy way to explain the reasoning; I've rewritten this paragraph
> three times because it was too long.  I have two residences and one
> has a port forwarding issue.  I want to make an SSH tunnel to the
> other site.  If I am at one place for multiple weeks, it's asking too
> much for the SSH tunnel to stay live that long (I've seen many
> complaints of SSH connections dropping).  I want to put it on a
> periodic cron job, but if I don't answer into the tunnel within 30
> minutes, it becomes idle and drops off.  Every hour a new tunnel is
> initiated.  The old session must either be closed or expire else I'll
> have multiple SSH sessions live simultaneously.  I don't want to
> travel with three laptops and 8 USB hard drives in carry on luggage
> again.
>

Why would you have multiple SSH sessions live simultaneously?  Since
you're forwarding ports, you can set it up so that only one of them can
have successfully setup the forwarding (see ExitOnForwardFailure in the
ssh_config manpage).

Something like this might work:

#!/bin/bash

while :; do
ssh \
-o ServerAliveInterval=30 \
-o ServerAliveCountMax=3 \
-o ControlPath=/tmp/ssh-%h-%p-%r \
-o ControlMaster=auto \
-o ControlPersist=yes \
-o ExitOnForwardFailure=yes \
-L  \
other.site \
sleep 1800
sleep 60
done

This will make sure the tunnel is always around, and gets reconnected
after network hiccups long enough to cause disconnection.  Just set it
up to run at boot on each site.

> My next flight is in May.  I'm doing a simulation with two VMs, but in
> reality, there will be two raspberry PIs doing the gatekeeping for me.
>
> On Mon, Apr 8, 2019 at 12:39 PM Greg Wooledge  wrote:
>>
>> On Mon, Apr 08, 2019 at 12:25:28PM -0500, timothylegg wrote:
>> > I need to have the session expire and the ssh client terminate after
>> > an idle time.
>>
>> Most people want the exact opposite of that.
>>
>> Basically, what you're asking for is directly hostile to any kind of
>> sane operation of a computer.
>>
>> > ClientAliveInterval 5
>> > ClientAliveCountMax 1
>>
>> Those settings are used for two purposes.  The first is to allow ssh or
>> sshd to terminate when the network connection has been lost.  The second
>> is to keep sending "I'm still here" messages through the network connection
>> so that a NAT gateway will not drop the session due to inactivity.
>>
>> So, if you wanted to achieve the exact opposite of your stated goal
>> (assuming a NAT is involved somewhere along the way), you've succeeded.
>>
>> I'm not aware of any "features" to cause ssh to terminate when idle, at
>> the ssh transport level.
>>
>> If all you want to do is terminate the user's shell (and thus their
>> ssh connection, ultimately) when the user is sitting idle at the shell
>> prompt for too long, you could use the shell's TMOUT variable.
>>
>> Of course, that won't disconnect the user's idle vim or mutt command.
>> That would result in data loss.
>>
>> TMOUT only works when idling at a shell prompt, and it requires the user
>> to sign up for this "feature" by setting that variable (or neglecting
>> to unset it, if someone tries to set it in a global shell file like
>> /etc/profile).
>>
>> Perhaps you could reframe your question in a way that makes sense in
>> a universe where the data loss from just arbitrarily killing users'
>> text editors and other stateful applications is a concern.  Start by
>> stating why you're trying to do this, who's making you do this, who's
>> going to handle the angry users, who's going to compensate them for
>> their data loss, etc.
>>

Re: OpenSSH not closing idle sessions.

[timothylegg]

I'm the only user that will be angry at being disconnected.  There is
no easy way to explain the reasoning; I've rewritten this paragraph
three times because it was too long.  I have two residences and one
has a port forwarding issue.  I want to make an SSH tunnel to the
other site.  If I am at one place for multiple weeks, it's asking too
much for the SSH tunnel to stay live that long (I've seen many
complaints of SSH connections dropping).  I want to put it on a
periodic cron job, but if I don't answer into the tunnel within 30
minutes, it becomes idle and drops off.  Every hour a new tunnel is
initiated.  The old session must either be closed or expire else I'll
have multiple SSH sessions live simultaneously.  I don't want to
travel with three laptops and 8 USB hard drives in carry on luggage
again.

My next flight is in May.  I'm doing a simulation with two VMs, but in
reality, there will be two raspberry PIs doing the gatekeeping for me.

On Mon, Apr 8, 2019 at 12:39 PM Greg Wooledge  wrote:
>
> On Mon, Apr 08, 2019 at 12:25:28PM -0500, timothylegg wrote:
> > I need to have the session expire and the ssh client terminate after
> > an idle time.
>
> Most people want the exact opposite of that.
>
> Basically, what you're asking for is directly hostile to any kind of
> sane operation of a computer.
>
> > ClientAliveInterval 5
> > ClientAliveCountMax 1
>
> Those settings are used for two purposes.  The first is to allow ssh or
> sshd to terminate when the network connection has been lost.  The second
> is to keep sending "I'm still here" messages through the network connection
> so that a NAT gateway will not drop the session due to inactivity.
>
> So, if you wanted to achieve the exact opposite of your stated goal
> (assuming a NAT is involved somewhere along the way), you've succeeded.
>
> I'm not aware of any "features" to cause ssh to terminate when idle, at
> the ssh transport level.
>
> If all you want to do is terminate the user's shell (and thus their
> ssh connection, ultimately) when the user is sitting idle at the shell
> prompt for too long, you could use the shell's TMOUT variable.
>
> Of course, that won't disconnect the user's idle vim or mutt command.
> That would result in data loss.
>
> TMOUT only works when idling at a shell prompt, and it requires the user
> to sign up for this "feature" by setting that variable (or neglecting
> to unset it, if someone tries to set it in a global shell file like
> /etc/profile).
>
> Perhaps you could reframe your question in a way that makes sense in
> a universe where the data loss from just arbitrarily killing users'
> text editors and other stateful applications is a concern.  Start by
> stating why you're trying to do this, who's making you do this, who's
> going to handle the angry users, who's going to compensate them for
> their data loss, etc.
>

Re: OpenSSH not closing idle sessions.

[Greg Wooledge]

On Mon, Apr 08, 2019 at 12:25:28PM -0500, timothylegg wrote:
> I need to have the session expire and the ssh client terminate after
> an idle time.

Most people want the exact opposite of that.

Basically, what you're asking for is directly hostile to any kind of
sane operation of a computer.

> ClientAliveInterval 5
> ClientAliveCountMax 1

Those settings are used for two purposes.  The first is to allow ssh or
sshd to terminate when the network connection has been lost.  The second
is to keep sending "I'm still here" messages through the network connection
so that a NAT gateway will not drop the session due to inactivity.

So, if you wanted to achieve the exact opposite of your stated goal
(assuming a NAT is involved somewhere along the way), you've succeeded.

I'm not aware of any "features" to cause ssh to terminate when idle, at
the ssh transport level.

If all you want to do is terminate the user's shell (and thus their
ssh connection, ultimately) when the user is sitting idle at the shell
prompt for too long, you could use the shell's TMOUT variable.

Of course, that won't disconnect the user's idle vim or mutt command.
That would result in data loss.

TMOUT only works when idling at a shell prompt, and it requires the user
to sign up for this "feature" by setting that variable (or neglecting
to unset it, if someone tries to set it in a global shell file like
/etc/profile).

Perhaps you could reframe your question in a way that makes sense in
a universe where the data loss from just arbitrarily killing users'
text editors and other stateful applications is a concern.  Start by
stating why you're trying to do this, who's making you do this, who's
going to handle the angry users, who's going to compensate them for
their data loss, etc.

Re: openssh-server's default config is dangerous

[Brian]

On Tue 12 Jul 2016 at 17:32:22 +0200, Nicolas George wrote:

> Le quintidi 25 messidor, an CCXXIV, Brian a écrit :
> > Not really. How to change Policy is adequately described on the Debian
> > web site. How to submit a bug against openssh-server is also described.
> 
> So you were talking about changing the whole policy of the project, not an
> option to apt? What an useless remark.

It takes you a while to catch on. But we are glad you got there eventually.
 
> > All services are started with safe defaults.
> 
> You have not understood a single thing about the issue at the origin of this
> thread, have you.

Possibly not. But more mentoring from an expert could improve that.

Re: openssh-server's default config is dangerous

[Stefan Monnier]

> You could potentially just use the policyrcd-script-zg2 package, and
> then your boolean setting would be:
>
>   echo -e "#!/bin/sh\nexit101;" > /etc/policy-rc.d.
>
> Or something similar. [Or if you really just want a boolean, you could
> potentially write your own package which plugged into policy-rc.d which
> just checked if /etc/no_daemons or something existed to determine
> whether it should exit 101 or not; you could possibly even figure out if
> you were running under dpkg, and just block starting/restarting daemons
> during package install/remove time.]

Yes, I could hand-code it myself.  But the question is why isn't such
a boolean pre-defined by default in Debian?

Am I really the only one who sometimes (like once a year or so, maybe)
takes a disk (aka µSD card) out of a machine, mounts it on another, and
then chroots into it to perform some administration tasks "offline" (tho
sometimes it's really more online: one of the cases where I did it was
because the main machine didn't have access to the Internet, so
I performed the updates by mounting the rootfs on another machine and
used aptitude there)?


Stefan

Re: openssh-server's default config is dangerous

[Don Armstrong]

On Tue, 12 Jul 2016, Stefan Monnier wrote:
> >> I often need something like this when running inside a chroot and
> >> always have trouble finding the clean way to do it
> > Here's one example that mk-sbuild uses:
> > (jessie-amd64)$ cat /usr/sbin/policy-rc.d
> > #!/bin/sh
> > while true; do
> > case "$1" in
> >   -*) shift ;;
> >   makedev) exit 0;;
> >   x11-common) exit 0;;
> >   *) exit 101;;
> > esac
> > done
> 
> Pretty far from my ideal of having some boolean setting under /etc somewhere.

You could potentially just use the policyrcd-script-zg2 package, and
then your boolean setting would be:

  echo -e "#!/bin/sh\nexit101;" > /etc/policy-rc.d.

Or something similar. [Or if you really just want a boolean, you could
potentially write your own package which plugged into policy-rc.d which
just checked if /etc/no_daemons or something existed to determine
whether it should exit 101 or not; you could possibly even figure out if
you were running under dpkg, and just block starting/restarting daemons
during package install/remove time.]

> It's actually worse: in some of my chroots (such as LilDebi's) I do
> want daemons to be started, while in others (typically when I
> mount some external disk that holds some other machine's (broken) root
> filesystem, in order to fix it) I don't.
> 
> So even if we could reliably identify that we're in a chroot jail, it
> wouldn't tell us whether daemons should be started/stopped.

Yep. This problem is exactly why the policy-rc.d framework exists; it's
way too difficult to figure out in what circumstances which daemons
should be started/stopped. Chroot-specific configuration is pretty much
the only way.

[Or, using systemd, which handles things slightly more elegantly using
systemctl enable|disable.]

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

-tommorow is our permanent address
and there they'll scarcely find us(if they do,
we'll move away still further:into now
 -- e.e. cummings "XXXIX" _1 x 1_

Re: openssh-server's default config is dangerous

[Gene Heskett]

On Wednesday 13 July 2016 07:32:10 Henrique de Moraes Holschuh wrote:

> On Wed, 13 Jul 2016, Joe wrote:
> > On Tue, 12 Jul 2016 20:09:31 +0100
> >
> > Brian  wrote:
> > > The cat from next door always looks very intently at me when I am
> > > at the keyboard. Is that normal feline behaviour?
> >
> > Yes. The weight of a cat is more than sufficient to operate most
> > keyboards.
>
> Not to mention their curiosity.  Cat-paw keyboard pattern detection
> exists for a good reason...
>
> And if that cat is used to getting petted by you, there will be a
> jealousy component as well (you should be using those fingers to pet
> it, not to bash on the weird thing that makes clicking noises).

Thereby confirming in the cats mind that you do not own a cat, the cat 
owns you.  That is how its been for several eons, so you may as well get 
used to it.

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)
Genes Web page 

Re: openssh-server's default config is dangerous

[Erwan David]

Le 13/07/2016 à 13:32, Henrique de Moraes Holschuh a écrit :
> On Wed, 13 Jul 2016, Joe wrote:
>> On Tue, 12 Jul 2016 20:09:31 +0100
>> Brian  wrote:
>>> The cat from next door always looks very intently at me when I am at
>>> the keyboard. Is that normal feline behaviour? 
>>>
>> Yes. The weight of a cat is more than sufficient to operate most
>> keyboards.
> Not to mention their curiosity.  Cat-paw keyboard pattern detection
> exists for a good reason...
>
> And if that cat is used to getting petted by you, there will be a
> jealousy component as well (you should be using those fingers to pet it,
> not to bash on the weird thing that makes clicking noises).
>
Add that the keyboard is the best place to see those shiny things moving
on the screen.

Re: openssh-server's default config is dangerous

[Henrique de Moraes Holschuh]

On Wed, 13 Jul 2016, Joe wrote:
> On Tue, 12 Jul 2016 20:09:31 +0100
> Brian  wrote:
> > The cat from next door always looks very intently at me when I am at
> > the keyboard. Is that normal feline behaviour? 
> > 
> Yes. The weight of a cat is more than sufficient to operate most
> keyboards.

Not to mention their curiosity.  Cat-paw keyboard pattern detection
exists for a good reason...

And if that cat is used to getting petted by you, there will be a
jealousy component as well (you should be using those fingers to pet it,
not to bash on the weird thing that makes clicking noises).

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Re: openssh-server's default config is dangerous

[Joe]

On Tue, 12 Jul 2016 21:51:41 +0100
Lisi Reisz  wrote:

> On Tuesday 12 July 2016 20:24:18 Brian wrote:
> > (For those who think this is about password logins in general - it
> > is not. It is about logging in as root).  
> 
> Thank you, Brian. You come up trumps again.  I said that I hadn't
> understood the question.  I did think it was about password logging
> in in general.
> 

There has been a bit of thread drift, and we all see different issues.

I took it to be a comment on the fact that any of a computer's users
have remote access to it, by password only, after a default installation
of openssh, as opposed to, say, MySQL, where nobody but the
administrator designated during installation has any access at all
until explicitly permitted, whether the daemon is running or not.

Or Remote Desktop on Windows Professional, which after being explicitly
enabled by an admin, is still only accessible to admins until others are
granted permissions.

SSH is mostly used in two separate situations: to provide a user with
remote operational access to a machine, and to provide an admin with an
alternative means of login to a machine where normal login is broken. A
default installation could provide the latter without the former.

-- 
Joe

Re: openssh-server's default config is dangerous

[Joe]

On Tue, 12 Jul 2016 20:09:31 +0100
Brian  wrote:


> The cat from next door always looks very intently at me when I am at
> the keyboard. Is that normal feline behaviour? 
> 
Yes. The weight of a cat is more than sufficient to operate most
keyboards.

-- 
Joe

Re: openssh-server's default config is dangerous

[Stefan Monnier]

>> I often need something like this when running inside a chroot and
>> always have trouble finding the clean way to do it
> Here's one example that mk-sbuild uses:
> (jessie-amd64)$ cat /usr/sbin/policy-rc.d
> #!/bin/sh
> while true; do
> case "$1" in
>   -*) shift ;;
>   makedev) exit 0;;
>   x11-common) exit 0;;
>   *) exit 101;;
> esac
> done

Pretty far from my ideal of having some boolean setting under /etc somewhere.

> In this particular case, the issue isn't dpkg, but the package
> maintainer scripts. Those all operate using invoke-rc.d, and are
> blissfully unaware of whether they are operating inside of a chroot or
> outside. [Indeed, there's no reliable way of identifying whether you're
> actually in a chroot or not unless you're root and can compare your root
> to init's root.]

It's actually worse: in some of my chroots (such as LilDebi's) I do want
daemons to be started, while in others (typically when I mount
some external disk that holds some other machine's (broken) root
filesystem, in order to fix it) I don't.

So even if we could reliably identify that we're in a chroot jail, it
wouldn't tell us whether daemons should be started/stopped.


Stefan

Re: openssh-server's default config is dangerous

[Don Armstrong]

On Tue, 12 Jul 2016, Stefan Monnier wrote:
> I often need something like this when running inside a chroot and
> always have trouble finding the clean way to do it

Here's one example that mk-sbuild uses:

(jessie-amd64)$ cat /usr/sbin/policy-rc.d
#!/bin/sh
while true; do
case "$1" in
  -*) shift ;;
  makedev) exit 0;;
  x11-common) exit 0;;
  *) exit 101;;
esac
done

For future reference, this is all covered in Debian Policy §9.3.3
"Interfacing with the initscript system" and invoke-rc.d(8).

> (IIUC dpkg should figure out on its own that it's running in a chroot,
> but it doesn't seem to work reliably enough in my experience, or maybe
> I misunderstood how "running in chroot" is expected to affect dpkg's
> behavior by default).

In this particular case, the issue isn't dpkg, but the package
maintainer scripts. Those all operate using invoke-rc.d, and are
blissfully unaware of whether they are operating inside of a chroot or
outside. [Indeed, there's no reliable way of identifying whether you're
actually in a chroot or not unless you're root and can compare your root
to init's root.]

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

If it jams, force it. If it breaks, it needed replacing anyway.
 -- Lowery's Law

Re: openssh-server's default config is dangerous

[Lisi Reisz]

On Tuesday 12 July 2016 21:48:32 Stefan Monnier wrote:
> > My solution to that is physical access to the computer, actually sitting
> > in front of it - login without a password.
>
> While I don't need a strong password in such a situation, I do want some
> password because I don't like it when other people use my account
> (usually they don't like it either because they find I have weird
> preferences, but sometimes they'd be too lazy to switch to some other
> account unless they're forced by the presence of a password prompt).

Horses for courses again. :-)  I hadn't thought of that risk.

Lisi

Re: openssh-server's default config is dangerous

[Lisi Reisz]

On Tuesday 12 July 2016 20:04:32 Don Armstrong wrote:
> Considering that I maintain multiple things
> which install daemons in Debian

And most of us are very grateful.

Lisi

Re: openssh-server's default config is dangerous

[Stefan Monnier]

> No, it does not. What you show is not an option, an option would be
> something in /etc.  This is editing a script in /usr/sbin, in complete
> violation of any good practice with packages managers.

FWIW, I also find it disappointing that I can't do it in an etc file of
some sort.  E.g. I often need something like this when running inside
a chroot and always have trouble finding the clean way to do it
(IIUC dpkg should figure out on its own that it's running in a chroot,
but it doesn't seem to work reliably enough in my experience, or maybe
I misunderstood how "running in chroot" is expected to affect dpkg's
behavior by default).


Stefan

Re: openssh-server's default config is dangerous

[Lisi Reisz]

On Tuesday 12 July 2016 20:24:18 Brian wrote:
> (For those who think this is about password logins in general - it is
> not. It is about logging in as root).

Thank you, Brian. You come up trumps again.  I said that I hadn't understood 
the question.  I did think it was about password logging in in general.

Lisi

Re: openssh-server's default config is dangerous

[Stefan Monnier]

> My solution to that is physical access to the computer, actually sitting in 
> front of it - login without a password.

While I don't need a strong password in such a situation, I do want some
password because I don't like it when other people use my account
(usually they don't like it either because they find I have weird
preferences, but sometimes they'd be too lazy to switch to some other
account unless they're forced by the presence of a password prompt).


Stefan

Re: openssh-server's default config is dangerous

[Don Armstrong]

On Tue, 12 Jul 2016, Nicolas George wrote:
> Le quintidi 25 messidor, an CCXXIV, Don Armstrong a écrit :
> > That option already exists. See policy-rc.d. For example:
> > 
> > https://jpetazzo.github.io/2013/10/06/policy-rc-d-do-not-start-services-automatically/
> 
> What you show is not an option, an option would be
> something in /etc. This is editing a script in /usr/sbin, in complete
> violation of any good practice with packages managers.

So install policyrcd-script-zg2 which allows you to have "something in
/etc".

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

"What, now?"
"Soon equates to good, later to worse, Uagen Zlepe, scholar.
Therefore, immediacy."
  -- Iain M. Banks _Look to Windward_ p 213

Re: openssh-server's default config is dangerous

[Nicolas George]

Le quintidi 25 messidor, an CCXXIV, Don Armstrong a écrit :
> This is incredibly rude.

I stand by it.

> This is the endless security vs utility debate.

Indeed.

The most secure system

> That option already exists. See policy-rc.d. For example:
> 
> https://jpetazzo.github.io/2013/10/06/policy-rc-d-do-not-start-services-automatically/

No, it does not. What you show is not an option, an option would be
something in /etc. This is editing a script in /usr/sbin, in complete
violation of any good practice with packages managers.


signature.asc
Description: Digital signature

Re: openssh-server's default config is dangerous

[Brian]

On Tue 12 Jul 2016 at 18:53:29 +0200, mwnx wrote:

> > So, you're blaming a perfectly good (and reasonably secure) way of
> > remote access, but somehow assume that weak passwords are ok.
> > By that logic you should not stop there. Why not blame any remote access
> > mechanism that uses PAM for password checking as well?
> 
> There are many kinds of systems on which weak passwords are OK. For

There is no system which justifies having a weak password (whatever
"weak" means). You might like to give an example of an ok weak
password.

> instance, a home PC has no need whatsoever for a strong password. If

Whatever "strong" means this could make sense. On the other hand, it
could be total nonsense.

> someone breaks into my home, they have access to my data anyway; and

Burglars carry Debian Live CDs these days? The ones round here just
kick the door in, load the goods into their cars and fence it

> the password is for local use only. If some malware gets into my
> computer, it can get the root password through keylogging.

I wondered when we would get to malware. You need a new thread for
this. I hope you make a better job of it than the post which started
this discussion.

> Note: this weak password can still be useful to protect my privacy
> from guests.

The cat from next door always looks very intently at me when I am at
the keyboard. Is that normal feline behaviour? 

Re: openssh-server's default config is dangerous

[Don Armstrong]

On Tue, 12 Jul 2016, Nicolas George wrote:
> Le quintidi 25 messidor, an CCXXIV, Don Armstrong a écrit :
> > If a services default configuration is insecure, it should be fixed.
> > File a bug.
> 
> If you think about it slightly more than two seconds,

This is incredibly rude. Considering that I maintain multiple things
which install daemons in Debian, I've thought about this for
significantly more than two seconds.

> you will realize that if the default configuration does ANYTHING, even
> something that is completely harmless in 99.99% of the cases, then
> there will be some cases where this is a serious issue, where the
> administrator really did not want it to happen. Even if it is only
> 0.01% of the cases, that is still too many.

This is the endless security vs utility debate. The most secure system
is a system which is completely useless. Discussing this issue in the
abstract isn't particularly useful. Discussing it in particular cases
(like openssh-server's configuration) is useful, and then it becomes a
question of where to draw the line.

There's a reason why many daemons that do start only listen on
localhost. Or only listen on sockets. Or don't do anything but serve
static files out of very specific directories.

> I am flabbergasted too see how many people oppose the obviously
> correct solution to that kind of issue: have a global option "Start
> services after installing? always / ask / never".

That option already exists. See policy-rc.d. For example:

https://jpetazzo.github.io/2013/10/06/policy-rc-d-do-not-start-services-automatically/

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

in Just-
spring  when the world is mud-
luscious the little lame baloonman 

whistles   far   and wee 
 -- e.e. cummings "[in Just-]"

Re: openssh-server's default config is dangerous

[Lisi Reisz]

On Tuesday 12 July 2016 19:16:37 Brian wrote:
> On Tue 12 Jul 2016 at 18:09:22 +0100, Lisi Reisz wrote:
> > This was sent to me separately privately as well.  I  might have answered
> > differently on the list, but I am not writing a second reply to the same
> > post, so here is a copy-and-paste of my reply.
> >
> > On Tuesday 12 July 2016 17:45:58 mwnx wrote:
> > > On Tue, Jul 12, 2016 at 02:18:58PM +0100, Lisi Reisz wrote:
> > > > I *was* asked last time I installed open-ssh*, at installation time,
> > > > but did not understand the question so went with the default.  If you
> > > > do not allow password log-in, what DO you allow?  For ssh to be
> > > > useful, one has to use it. Note that it is not installed by default,
> > > > one has to actively choose to have it.
> > >
> > > Before writing the original post, I checked on an Ubuntu 16.04 live
> > > CD and was not asked any questions during installation of
> > > openssh-server.
> >
> > My reaction to that is "well, if you will use Ubuntu, what do you expect?
> > Ubuntu is hopelessly insecure."
>
> Your reaction is unwarranted and unsubstantiated.

Yes, probably.  It was my reaction, and has been my experience in general - 
but I did not test this.  I was annoyed that mwnx had gone personal in that 
way.  Mea culpa.

> mwnx relates an 
> experience which can easily be tested. Not that anyone will; this
> is -user! In fact. there is no need to install because a glance at
> the templates file in the openssh-server package should be enough.
>
> Unconvinced? Do
>
>   dpkg-reconfigure openssh-server
>
> Any output? Why not is left as an exercise to the user.
>
> > > I also tried right now on a debian jessie system,
> > > and again, was not asked anything. What version of debian are you
> > > running?
> >
> > Jessie and Wheezy.
>
> The question you say was presented (and hazily recollect) was presented
> because you were upgrading from Wheezy to Jessie.

No, that is neither what I said nor what I meant.  I do not have ssh on any of 
my systems unless I need it.  So the last twice I did 

# aptitude install openssh-client openssh-server

I think once on Wheezy and once on Jessie, but am not absolutle certain that 
that was the order in which I did it, so it could have been the two Jessie 
computers that I did last.  I have installed ssh recently on one Wheezy 
computer and two Jessie ones.  I did not write the question down, but I was 
asked it.
>
> > > My idea was that to be able to use ssh, you should configure it
> > > first, in some way or another. A very basic configuration
> > > (specifically, whether to allow password auth or not) could be done
> > > through a prompt during installation.
> >
> > It was, last time I installed it.  (ssh-server)
>
> No question would be seen with a fresh install of openssh-server. The
>  question in essence is
>
>   Disable SSH password authentication for root?

No it was an a or b choice.
>
> Firstly, this has nothing to do with the original posting. Secondly,
> disabling it is the default for a new install so there is no need to
> ask any question.

It wasn't I who wanted it.  Though I want password access, so if the default 
is now no password access I am glad to have the information you give above.

Lisi
>
> So nwnx is correct. Not that his substantial first post finds any
> favour in these parts.
>
> > > > Where you are administering systems where you can expect users on
> > > > your system to have weak passwords, change the defaults to suit.  On
> > > > my network there are no weak passwords.  At least, I have chosen all
> > > > passwords on the system and I go out of my way to try and make them
> > > > reasonably secure.  It is also (I hope) fairly difficult for anyone
> > > > else to break in in the first place.  I don't want *my* life made any
> > > > harder!!
> > >
> > > You're looking at this from a sysadmin point of view, but many
> > > debian users (I'm including Ubuntu users here) have no or little
> > > knowledge of system administration.
> >
> > a) I am not.  I have a small home network.  And b) then they shouldn't be
> > using ssh.  Especially Ubuntu users.  Ubuntu is hopelessly insecure in so
> > many ways it is one of the main reasons why I don't like it.
> >
> > Weak passwords are a no-no in my opinion.  If you use weak passwords and
> > it causes problems, that is your problem.  Don't foist a self-created
> > problem on the rest of us.  If your network is insecurely open to the
> > world, that is also your problem.  If you are administering a large
> > network, then you are a sys-admin and can configure ssh to suit yourself.
>
> Precisely. The original post sets up an Aunt Sally.

Re: openssh-server's default config is dangerous

[Nicolas George]

Le quintidi 25 messidor, an CCXXIV, Don Armstrong a écrit :
> If a services default configuration is insecure, it should be fixed.
> File a bug.

If you think about it slightly more than two seconds, you will realize that
if the default configuration does ANYTHING, even something that is
completely harmless in 99.99% of the cases, then there will be some cases
where this is a serious issue, where the administrator really did not want
it to happen. Even if it is only 0.01% of the cases, that is still too many.

I am flabbergasted too see how many people oppose the obviously correct
solution to that kind of issue: have a global option "Start services after
installing? always / ask / never".


signature.asc
Description: Digital signature

Re: openssh-server's default config is dangerous

[Brian]

On Tue 12 Jul 2016 at 18:09:22 +0100, Lisi Reisz wrote:

> This was sent to me separately privately as well.  I  might have answered 
> differently on the list, but I am not writing a second reply to the same 
> post, so here is a copy-and-paste of my reply.
> 
> On Tuesday 12 July 2016 17:45:58 mwnx wrote:
> > On Tue, Jul 12, 2016 at 02:18:58PM +0100, Lisi Reisz wrote:
> > > I *was* asked last time I installed open-ssh*, at installation time, but
> > > did not understand the question so went with the default.  If you do not
> > > allow password log-in, what DO you allow?  For ssh to be useful, one has
> > > to use it. Note that it is not installed by default, one has to actively
> > > choose to have it.
> >
> > Before writing the original post, I checked on an Ubuntu 16.04 live
> > CD and was not asked any questions during installation of
> > openssh-server. 
> 
> My reaction to that is "well, if you will use Ubuntu, what do you expect?  
> Ubuntu is hopelessly insecure."

Your reaction is unwarranted and unsubstantiated. mwnx relates an
experience which can easily be tested. Not that anyone will; this
is -user! In fact. there is no need to install because a glance at
the templates file in the openssh-server package should be enough.

Unconvinced? Do

  dpkg-reconfigure openssh-server

Any output? Why not is left as an exercise to the user.

> > I also tried right now on a debian jessie system, 
> > and again, was not asked anything. What version of debian are you
> > running?
> 
> Jessie and Wheezy.

The question you say was presented (and hazily recollect) was presented
because you were upgrading from Wheezy to Jessie.

> > My idea was that to be able to use ssh, you should configure it
> > first, in some way or another. A very basic configuration
> > (specifically, whether to allow password auth or not) could be done
> > through a prompt during installation.
> 
> It was, last time I installed it.  (ssh-server)

No question would be seen with a fresh install of openssh-server. The
 question in essence is

  Disable SSH password authentication for root?

Firstly, this has nothing to do with the original posting. Secondly,
disabling it is the default for a new install so there is no need to
ask any question.

So nwnx is correct. Not that his substantial first post finds any
favour in these parts.

> > > Where you are administering systems where you can expect users on your
> > > system to have weak passwords, change the defaults to suit.  On my
> > > network there are no weak passwords.  At least, I have chosen all
> > > passwords on the system and I go out of my way to try and make them
> > > reasonably secure.  It is also (I hope) fairly difficult for anyone else
> > > to break in in the first place.  I don't want *my* life made any harder!!
> >
> > You're looking at this from a sysadmin point of view, but many
> > debian users (I'm including Ubuntu users here) have no or little
> > knowledge of system administration.
> 
> a) I am not.  I have a small home network.  And b) then they shouldn't be 
> using ssh.  Especially Ubuntu users.  Ubuntu is hopelessly insecure in so 
> many ways it is one of the main reasons why I don't like it.
> 
> Weak passwords are a no-no in my opinion.  If you use weak passwords and it 
> causes problems, that is your problem.  Don't foist a self-created problem on 
> the rest of us.  If your network is insecurely open to the world, that is 
> also your problem.  If you are administering a large network, then you are a 
> sys-admin and can configure ssh to suit yourself.

Precisely. The original post sets up an Aunt Sally.

Re: openssh-server's default config is dangerous

[Lisi Reisz]

On Tuesday 12 July 2016 18:39:29 Erwan David wrote:
> Le 12/07/2016 à 19:34, Lisi Reisz a écrit :
> > My solution to that is physical access to the computer, actually sitting
> > in front of it - login without a password.  ALL external access, even
> > from the neighbouring computer, use a strong password in case someone
> > breaks into your network from outside.
> >
> > Lisi
>
> Note that there are computers to which no user has physical access.

Of course.  But anyone who is administering such a computer can be assumed to 
be at least knowledgeable enough to reconfigure ssh to suit his/her 
needs/likes/wants!  And I would never advocate passwordless entry, nor a weak 
password, in such a situation. 

> > "ALL external access, even
> > from the neighbouring computer, use a strong password in case someone
> > breaks into your network from outside."

Lisi

Re: openssh-server's default config is dangerous

[Erwan David]

Le 12/07/2016 à 19:34, Lisi Reisz a écrit :
>
> My solution to that is physical access to the computer, actually sitting in 
> front of it - login without a password.  ALL external access, even from the 
> neighbouring computer, use a strong password in case someone breaks into your 
> network from outside.
>
> Lisi
Note that there are computers to which no user has physical access.

Re: openssh-server's default config is dangerous

[Lisi Reisz]

On Tuesday 12 July 2016 18:14:04 Stefan Monnier wrote:
> > This is different from what you originally said.  By all means discuss
> > this general problem with the developers - but please don't single ssh
> > out and mess it up for a good many of the rest of us.
>
> I think we're miscommunicating: I specifically don't want to single-out
> SSH but instead I want to single out GDM.  And I think this should be
> done in PAM.

Yes, we are miscommunicating, and I'll go along with that.
>
> > But why do you need weak passwords?  I think we may have an x-y problem
> > here, and weak passwords may not be the only/optimum solution to the
> > problem you are trying to solve by having them.  Weak passwords are a bad
> > idea per se.
>
> Quite likely.  I only pointed out this need of mine as being related to
> the OP's request.
>
> Here are some uses of weak passwords in GDM I can remember offhand:
> - For accounts of people unable to remember a more complex password.
> - For guest accounts
> - For mere convenience (when I'm in front of my desktop at home, it's
>   handy not to have to type my full password, under the assumption that
>   physical access to the machine means that a strong password wouldn't
>   make much difference (as long as the disk isn't encrypted, say)).

My solution to that is physical access to the computer, actually sitting in 
front of it - login without a password.  ALL external access, even from the 
neighbouring computer, use a strong password in case someone breaks into your 
network from outside.

Lisi

Re: openssh-server's default config is dangerous

[Stefan Monnier]

> This is different from what you originally said.  By all means discuss this
> general problem with the developers - but please don't single ssh out and
> mess it up for a good many of the rest of us.

I think we're miscommunicating: I specifically don't want to single-out
SSH but instead I want to single out GDM.  And I think this should be
done in PAM.

> But why do you need weak passwords?  I think we may have an x-y problem here,
> and weak passwords may not be the only/optimum solution to the problem you
> are trying to solve by having them.  Weak passwords are a bad idea per se.

Quite likely.  I only pointed out this need of mine as being related to
the OP's request.

Here are some uses of weak passwords in GDM I can remember offhand:
- For accounts of people unable to remember a more complex password.
- For guest accounts.
- For mere convenience (when I'm in front of my desktop at home, it's
  handy not to have to type my full password, under the assumption that
  physical access to the machine means that a strong password wouldn't
  make much difference (as long as the disk isn't encrypted, say)).


Stefan

Re: openssh-server's default config is dangerous

[Lisi Reisz]

On Tuesday 12 July 2016 17:53:29 mwnx wrote:
> > So, you're blaming a perfectly good (and reasonably secure) way of
> > remote access, but somehow assume that weak passwords are ok.
> > By that logic you should not stop there. Why not blame any remote access
> > mechanism that uses PAM for password checking as well?
>
> There are many kinds of systems on which weak passwords are OK. For
> instance, a home PC has no need whatsoever for a strong password. If
> someone breaks into my home, they have access to my data anyway; and
> the password is for local use only. If some malware gets into my
> computer, it can get the root password through keylogging.
>
> Note: this weak password can still be useful to protect my privacy
> from guests.

Then it is up to you to reconfigure anything that this attitude leaves 
insecure that you want secure.  (Why?  The break in scenario still applies.)

Lisi

Re: openssh-server's default config is dangerous

[Lisi Reisz]

This was sent to me separately privately as well.  I  might have answered 
differently on the list, but I am not writing a second reply to the same 
post, so here is a copy-and-paste of my reply.

On Tuesday 12 July 2016 17:45:58 mwnx wrote:
> On Tue, Jul 12, 2016 at 02:18:58PM +0100, Lisi Reisz wrote:
> > I *was* asked last time I installed open-ssh*, at installation time, but
> > did not understand the question so went with the default.  If you do not
> > allow password log-in, what DO you allow?  For ssh to be useful, one has
> > to use it. Note that it is not installed by default, one has to actively
> > choose to have it.
>
> Before writing the original post, I checked on an Ubuntu 16.04 live
> CD and was not asked any questions during installation of
> openssh-server. 

My reaction to that is "well, if you will use Ubuntu, what do you expect?  
Ubuntu is hopelessly insecure."

> I also tried right now on a debian jessie system, 
> and again, was not asked anything. What version of debian are you
> running?

Jessie and Wheezy.
>
> My idea was that to be able to use ssh, you should configure it
> first, in some way or another. A very basic configuration
> (specifically, whether to allow password auth or not) could be done
> through a prompt during installation.

It was, last time I installed it.  (ssh-server)  

> > Where you are administering systems where you can expect users on your
> > system to have weak passwords, change the defaults to suit.  On my
> > network there are no weak passwords.  At least, I have chosen all
> > passwords on the system and I go out of my way to try and make them
> > reasonably secure.  It is also (I hope) fairly difficult for anyone else
> > to break in in the first place.  I don't want *my* life made any harder!!
>
> You're looking at this from a sysadmin point of view, but many
> debian users (I'm including Ubuntu users here) have no or little
> knowledge of system administration.

a) I am not.  I have a small home network.  And b) then they shouldn't be 
using ssh.  Especially Ubuntu users.  Ubuntu is hopelessly insecure in so 
many ways it is one of the main reasons why I don't like it.

Weak passwords are a no-no in my opinion.  If you use weak passwords and it 
causes problems, that is your problem.  Don't foist a self-created problem on 
the rest of us.  If your network is insecurely open to the world, that is 
also your problem.  If you are administering a large network, then you are a 
sys-admin and can configure ssh to suit yourself.

Lisi

Re: openssh-server's default config is dangerous

[Lisi Reisz]

On Tuesday 12 July 2016 17:26:08 Stefan Monnier wrote:
> I mean, yes, I can (and have) cobbled up some hackish way to plug the
> holes I was aware of, but I think it would be better to be able to
> specifically only allow weak password authentication for some specific
> services and then stop worrying about which other services might still
> use those weak password (su? telnetd? which other ones?  how could
> I find out?)

This is different from what you originally said.  By all means discuss this 
general problem with the developers - but please don't single ssh out and 
mess it up for a good many of the rest of us.  

But why do you need weak passwords?  I think we may have an x-y problem here, 
and weak passwords may not be the only/optimum solution to the problem you 
are trying to solve by having them.  Weak passwords are a bad idea per se.

Lisi

Re: openssh-server's default config is dangerous

[mwnx]

> So, you're blaming a perfectly good (and reasonably secure) way of
> remote access, but somehow assume that weak passwords are ok.
> By that logic you should not stop there. Why not blame any remote access
> mechanism that uses PAM for password checking as well?

There are many kinds of systems on which weak passwords are OK. For
instance, a home PC has no need whatsoever for a strong password. If
someone breaks into my home, they have access to my data anyway; and
the password is for local use only. If some malware gets into my
computer, it can get the root password through keylogging.

Note: this weak password can still be useful to protect my privacy
from guests.

-- 
mwnx
GPG: AEC9 554B 07BD F60D 75A3  AF6A 44E8 E4D4 0312 C726

Re: openssh-server's default config is dangerous

[mwnx]

On Tue, Jul 12, 2016 at 02:18:58PM +0100, Lisi Reisz wrote:
> I was asked last time I installed open-ssh*, at installation time, but did
> not understand the question so went with the default.  If you do not allow
> password log-in, what DO you allow?  For ssh to be useful, one has to use it.
> Note that it is not installed by default, one has to actively choose to have
> it.

Before writing the original post, I checked on an Ubuntu 16.04 live
CD and was not asked any questions during installation of
openssh-server. I also tried right now on a debian jessie system,
and again, was not asked anything. What version of debian are you
running?

My idea was that to be able to use ssh, you should configure it
first, in some way or another. A very basic configuration
(specifically, whether to allow password auth or not) could be done
through a prompt during installation.

> Where you are administering systems where you can expect users on your system
> to have weak passwords, change the defaults to suit.  On my network there are
> no weak passwords.  At least, I have chosen all passwords on the system and I
> go out of my way to try and make them reasonably secure.  It is also (I hope)
> fairly difficult for anyone else to break in in the first place.  I don't
> want my life made any harder!!

You're looking at this from a sysadmin point of view, but many
debian users (I'm including Ubuntu users here) have no or little
knowledge of system administration.

-- 
mwnx
GPG: AEC9 554B 07BD F60D 75A3  AF6A 44E8 E4D4 0312 C726

Re: openssh-server's default config is dangerous

[Stefan Monnier]

>> The original use case was to provide an account to my daughter who
>> was not (yet) able to remember a strong password.  She wasn't going
>> to use a console login either.
> So a corner - and hopefully transitory ;-) - case.

Originally, yes, but I learned in the mean time to appreciate the
possibility of offering an account with a simple/trivial password on
my machine.  It comes in handy more often than "once per offspring".

> Set your system to use key-pairs.

I don't understand what that means (or how that helps).
Do you mean I should disallow password access via SSH altogether?
That doesn't solve the issue of "only allow password access via GDM",
in the sense that there are still other ways in beside GDM and SSH.

I mean, yes, I can (and have) cobbled up some hackish way to plug the
holes I was aware of, but I think it would be better to be able to
specifically only allow weak password authentication for some specific
services and then stop worrying about which other services might still
use those weak password (su? telnetd? which other ones?  how could
I find out?)


Stefan

Re: openssh-server's default config is dangerous

[Reco]

On Tue, Jul 12, 2016 at 03:40:05PM +0200, to...@tuxteam.de wrote:
> On Tue, Jul 12, 2016 at 04:24:41PM +0300, Reco wrote:
> > On Tue, Jul 12, 2016 at 02:55:29PM +0200, to...@tuxteam.de wrote:
> 
> [...]
> 
> > > While it makes sense to keep a more general solution in sight, sshd
> > > is in many respects special.
> > 
> > Such as?
> 
> Hm. Given its task, it runs as root. And is designed to run arbitrary
> commands from "outside" whenever the credentials are right. In my
> view, this puts some weight on those credentials.

Indeed it does all that. But consider this:

- By its design checks for local user's password (again, it can do
  kerberos, but let's not go in there).

- Such check is done by PAM in Debian, hence it's PAM, not openssh
  should be blamed for any fallacies in password check.

- While it's certainly possible to write a custom authentication scheme
  in PAM configuration for sshd only - I don't know any Linux (or
  non-Linux) distribution which does so.

- And sshd is only one example of remote access program which is running
  with uid=0 privileges, although possibly the most common one.

Hence 'sshd allows for weak credentials' problem could be solved in more
correct way - simply prohibit setting weak passwords for any OS user,
root included.

For example, Debian could adopt RedHat approach (it would not be the
first such case after all), and force using pam_cracklib by default.


> > > And how about changing the default to "PasswordAuthentication no"?
> 
> > 2) Keypair type.
> > 
> > As of jessie stock sshd allows 6 ('ssh -Q key | grep -v cert') keypair
> > types, and of those one is secure - ed25519.
> 
> C'mon. This is just a choice of defaults which can be improved on.

By default ssh-keygen generates an rsa keypair (at least the man page
says so). It's important for compatibility with legacy systems (Solaris
comes to mind immediately), but falls into 'nothing to write home about'
category by today's standards.

Changing ssh-keygen default keypair type will require a patch for
openssh, and we're still seeing the fallout from '06 openssl Debian
patch failure ;)

Reco

Re: openssh-server's default config is dangerous

[Nicolas George]

Le quintidi 25 messidor, an CCXXIV, Brian a écrit :
> Not really. How to change Policy is adequately described on the Debian
> web site. How to submit a bug against openssh-server is also described.

So you were talking about changing the whole policy of the project, not an
option to apt? What an useless remark.

> All services are started with safe defaults.

You have not understood a single thing about the issue at the origin of this
thread, have you.

EOT


signature.asc
Description: Digital signature

Re: openssh-server's default config is dangerous

[Lisi Reisz]

On Tuesday 12 July 2016 14:53:41 Stefan Monnier wrote:
> The original use case
> was to provide an account to my daughter who was not (yet) able to
> remember a strong password.  She wasn't going to use a console
> login either.

So a corner - and hopefully transitory ;-) - case.  Set your system to use 
key-pairs.  (Is that what you are advocating that the rest of us should have 
imposed???)  Then change it back when your daughter is old enough to use a 
strong password - if age is the problem.  People do after all outgrow being 
too young.  My being too old can only get worse. ;-)

Lisi

Re: openssh-server's default config is dangerous

[Don Armstrong]

On Tue, 12 Jul 2016, Nicolas George wrote:
> That means the service ran for some time with the wrong config. Pwned.

If a services default configuration is insecure, it should be fixed.
File a bug.


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

I learned really early the difference between knowing the name of
something and knowing something
 -- Richard Feynman "What is Science" Phys. Teach. 7(6) 1969

Re: openssh-server's default config is dangerous

[Brian]

On Tue 12 Jul 2016 at 16:35:49 +0200, Nicolas George wrote:

> Le quintidi 25 messidor, an CCXXIV, Brian a écrit :
> > Of course it can be changed. Jost change Policy.
> 
> Care to elaborate?

Not really. How to change Policy is adequately described on the Debian
web site. How to submit a bug against openssh-server is also described.

> > It's already configured. Want another configuration? Alter and restart
> > the service.
> 
> That means the service ran for some time with the wrong config. Pwned.
> 
> > Stop the service etc.
> 
> That means the service ran for some time while you did not want it to.
> Pwned.

All services are started with safe defaults.