Fernando de Oliveira wrote:
>>>>> and sometimes had issues with networrk
>> timeouts
>>>> (ServerAlive*). I like
>>>>> to disable sshv1 also since it's not secure.
>
> In an ssh session, connection to one particular machine many times is
> lost. Perhaps what is happening is that timeout you mentioned. Would
> you please help me to learn how I could test and solve this?
If there is no activity across a connection, sometimes a time out will
occur, perhaps in the target machine, perhaps in an intermediate router
or switch. Sending a simple "I'm alive" packet once in a while prevents
this. In the client's config file:
Protocol 2
ServerAliveInterval 45
ServerAliveCountMax 10
will help with this problem.
ServerAliveInterval
Sets a timeout interval in seconds after which if no data has been
received from the server, ssh(1) will send a message through the
encrypted channel to request a response from the server.
The default is 0, indicating that these messages will
not be sent to the server. This option applies to protocol
version 2 only.
ServerAliveCountMax
Sets the number of server alive messages which may be sent without
ssh(1) receiving any messages back from the server. If this threshold
is reached while server alive messages are being sent, ssh will
disconnect from the server, terminating the session. It is important
to note that the use of server alive messages is very different from
TCPKeepAlive (below). The server alive messages are sent through the
encrypted channel and therefore will not be spoofable. The
TCP keepalive option enabled by TCPKeepAlive is spoofable. The server
alive mechanism is valuable when the client or server depend on knowing
when a connection has become inactive.
The default value is 3. If, for example, ServerAliveInterval is set
to 15 and ServerAliveCountMax is left at the default, if the server
becomes unresponsive, ssh will disconnect after approximately 45
seconds. This option applies to protocol version 2 only.
> In the ArchLinux VM, there is no syslog.conf. I found there syslog-ng,
> but it is not installed, system uses systemd. Thus, really do not know
> where to look for the system's default log level configuration.
What are the advantages of systemd again?
> As you well know, I still have a very very small knowledge about
> security, so, what follows might be obvious for others.
I suspect you know more that you are giving yourself credit for.
> I always
> type a password, for rsync from other machines to this LFS, so I
> think I am using "manually type in a pass phrase every time you want
> to use a key", of your reply. The key for the other machine has to
> be accepted, in the first session.
It could be that or it could be the pass phrase in the ssh key.
> A rule in iptables allows, in
> this LFS machine, connection only for tcp from the other ip, and
> only to one port. Hope this is secure enough.
Is the system visible from the outside? If that is needed, then you do
have to expose that port. Actually, blocking things with netfilter
doesn't do a huge amount of good. If you want to limit the range of
incoming IP addresses, then it is useful. For instance, if you don't
have a web server listening on port 80, using netfilter to block it
doesn't do a huge amount of good. The only thing somone could do is
tell if the system is up and the ssh port does that too.
In my case, I don't have any servers here that are exposed to the
outside. anduin is at a remote isp. If you found the IP address that I
use, you could do a complete sweep of all 65536 tcp ports and all 65536
udp ports and conclude there is no machine here. The only thing my
router responds to is those IP packets that it expects because I made an
outdoing connection.
> I still miss very basic necessary knowledge, in Linux. Many decades
> ago, I was able to program in assembler Z80 and Intel 8086, and
> remember vaguely, I knew by heart most important memory addresses. I
> created then a graphical library to link with fortran, to display
> data on screen from fortran programs for data analysis of numerical
> calculations I was doing. At the time, I knew no other way to do
> that. It was MS-DOS. Not the same man I used to be.
Things have become more complicated. MS-DOS did not have networking at
all. Z80 and Intel 8086 only differed in three instructions. There was
no floating point processor. In fact, MS-DOS was not an operating
system. It was a program loader. MS-DOS did not allow for or manage
processes, memory, IO, or anything else. The BIOS did provide some HW
interface routines (e.g. INT 10h), but other than that, it was virtually
useless.
-- Bruce
--
http://linuxfromscratch.org/mailman/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
