Thanks for all that info. Going through them and writing took some
time, sorry for the delay.
--- Em qua, 3/4/13, Bruce Dubbs escreveu:
> De: Bruce Dubbs
> Assunto: Re: [blfs-support] openssh-6.2p1 messages
> Para: "BLFS Support List"
> Data: Quarta-feira, 3 de Abril de 2013, 16:28
> Fernando de Oliveira wrote:
>
> >>>>> and sometimes had issues with network
> >> 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.
Thanks, Bruce.
I think it is not yet solved. Delayed this to keep observing their
behaviour.
To facilitate, I will use the names "main" and "vm" for the two
involved machines. They are both client and server (I think, please,
do correct me if I am wrong below).
Main client connects to vm server using
ssh $vm_ip
A password is asked.
But main is where the source files are, so, I mount a directory of
the now server main in vm:
sshfs -o default_permissions -o allow_root
$main_ip:$HOME/MyDownloadFiles/Sistema/Linux/lfs/sources6.8 $HOME/sshfs
Again, a password is asked.
Now I can use vm, with an xterm in main.
What I observed these two days.
After your post, I was reading a file, before editing, using less, when the
connection died again. So, was I not sending and receiving packets for
that?
Before changes, ssh connection would often died.
Then I edited ssh_config in vm according to your suggestions,
rebooted vm, reconnected and waited, while performing a very long
build. Unfortunately, connection closed, again. Connection closes,
but it did not complete the job, whereas before the ssh_config
changes, it did finish the job, even after connection died.
Then, reverted the changes and monitored the connection, which lasted
over 24h, when the vm was idle.
Later, introduced changes to ssh_config in main, did not reboot any,
built linux-3.8.6, again, connection died. When I catch the
connection dying event, and try to connect with ssh, connection is
refused, immediately after, have to wait some time. After
reconnection, sshfs is still mounted.
It used to work flawlessly, some months ago, cannot remember what
changed in the systems that modified the behaviour.
...
> > 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?
No idea.
>
> > 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.
I think it is going to be difficult modifying what I do now. I
learned how to test the key, and have no idea what the passphrases of
any of my machines are. Perhaps I will take all time of one day
regenerating all them, but certainly will do it for next new systems.
> > 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
> someone 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 have the following rules in main:
iptables -A INPUT -s $vm_ip -p tcp --dport 22 -j ACCEPT
for vm's and physical machines.
>From vm:
$ sudo nmap $main_ip
Starting Nmap 6.01 ( http://nmap.org ) at 2013-04-08 12:05 BRT
Nmap scan report for $main_ip
Host is up (0.00015s latency).
Not shown: 999 filtered ports
PORT STATE SERVICE
22/tcp open ssh
MAC Address: $main_mcaddress ($main_brand)
Nmap done: 1 IP address (1 host up) scanned in 34.18 seconds
Now, with the rule commented out:
#iptables -A INPUT -s <ip> -p tcp --dport 22 -j ACCEPT
for a particular machine, but not for others (so, 22/tcp is still open
for the others).
fernando [ ~ ]$ sudo nmap $main_ip
Starting Nmap 6.01 ( http://nmap.org ) at 2013-04-08 12:06 BRT
Nmap scan report for $main_ip
Host is up (0.000099s latency).
All 1000 scanned ports on $main_ip are filtered
MAC Address: $main_mcaddress ($main_brand)
Nmap done: 1 IP address (1 host up) scanned in 34.18 seconds
$
Thus, ping is accepted, I think. Other than that, everything is
hidden, right?
Should I change these rules?
...
>
> -- Bruce
This was written a bit each day. Hope I did not forget anything.
Thanks again, Bruce.
[]s,
Fernando
--
http://linuxfromscratch.org/mailman/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
