I run[...]
ssh -vvv -nN -R 9000:localhost:info info
where info is the outside machine.
Unfortunately it does not work
Here is the end of the log produced by -vvv, after logs state tht there
was a successful logon onto info
debug3: receive packet: type 82[...]
debug1: remote forward failure for: listen 8024, connect localhost:22 -----------------------------------------------------
And this is the end of an attempt by another machine barby which
connected to info from behind another natting router.
debug3: receive packet: type 81
debug1: remote forward success for: listen 8024, connect localhost:22
I am trying to open an ssh tunnel from a machine (let me call it arby) behind a natting router to another
machine, so I can sign in to that hidden computer from the outside
machine, let me call it info. Info is the name of the outside machine.
I can log on to info from arby using passwordless logon without trouble.
I run
ssh -vvv -nN -R 9000:localhost:info info
where info is the outside machine.
Unfortunately it does not work
Here is the end of the log produced by -vvv, after logs state tht there
was a successful logon onto info
debug1: remote forward failure for: listen 8024, connect localhost:22 Warning: remote port forwarding failed for listen port 8024
On Mon, 20 May 2019 02:25:56 -0400, William Unruh <unruh@invalid.ca> wrote:
I am trying to open an ssh tunnel from a machine (let me call it arby) behind a natting router to another
machine, so I can sign in to that hidden computer from the outside
machine, let me call it info. Info is the name of the outside machine.
I can log on to info from arby using passwordless logon without trouble.
I run
ssh -vvv -nN -R 9000:localhost:info info
where info is the outside machine.
Unfortunately it does not work
Here is the end of the log produced by -vvv, after logs state tht there
was a successful logon onto info
debug1: remote forward failure for: listen 8024, connect localhost:22
Warning: remote port forwarding failed for listen port 8024
See https://superuser.com/questions/1390259/how-do-i-forward-443-to-my-machine-from-remote
I strongly recommend using a high number port (higher than 1024) rather
then the default 22 to avoid bots trying to crack the password from
filling the disk with log entries. Even though password login is disabled, that doesn't stop them from trying. Also, only root can open ports 1024
or less.
I'd back up a bit though. What you are trying to do sounds similar to
what I've done using autossh.
http://www.debianadmin.com/autossh-automatically-restart-ssh-sessions-and-tunnels.html
has pretty good starting instructions.
I set up my systems years ago, so would have to dig a bit to get the full details of what I currently have set up. I've just used upgrades since then making minor changes when needed.
If the above instructions are not enough, I can dig through what I have, though it may take a while. In involves dyndns, router config, sshd
config, ssh, and autossh setup :-)
Regards, Dave Hodgins
I have used autossh from a number of machines without trouble. The
direct use of ssh in my tests was so I could see the logs (-vvv) to see
what the trouble was. As mentioned I tried the same test from two
outside machines and from one it worked and the other not. And this is
very consistant (ie I have tried both many ties and it never works from
arby but always works from barby.)
So there must be some difference but I cannot figure out what.
William Unruh <unruh@invalid.ca> wrote:
I run[...]
ssh -vvv -nN -R 9000:localhost:info info
where info is the outside machine.
Unfortunately it does not work
Here is the end of the log produced by -vvv, after logs state tht there
was a successful logon onto info
debug3: receive packet: type 82[...]
debug1: remote forward failure for: listen 8024, connect localhost:22
-----------------------------------------------------
And this is the end of an attempt by another machine barby which
connected to info from behind another natting router.
debug3: receive packet: type 81
debug1: remote forward success for: listen 8024, connect localhost:22
Packet types 82 and 81 are SSH2_MSG_REQUEST_FAILURE and SSH2_MSG_REQUEST_SUCCESS respectively, so yes, all that these logs
tell us is that you asked the server nicely to listen on a particular
port, and in one case it said yes and in the other case it said no.
There's no field in the SSH2_MSG_REQUEST_FAILURE packet format for a
more detailed error message, unfortunately.
If you're able to run an ordinary shell session on the host that's
refusing your port forwarding requests, my first suggestion would be
to try to make an ordinary process listen on the same port number and
see what error message that gives. For example, something like 'nc -l port-number', if it's a Linux box with nc installed, and if not, some
local equivalent. With any luck that might narrow the problem down -
for example (my first guess) it might turn out that some other process
is already using that port number.
(Also I'm confused about the 'listen 8024' in both error messages,
when your command line suggested that the port you were asking the
server to listen on was 9000. But that's probably not important.)
I am trying to open an ssh tunnel from a machine (let me call it arby) behind a natting router to another----
machine, so I can sign in to that hidden computer from the outside
machine, let me call it info. Info is the name of the outside machine.
I can log on to info from arby using passwordless logon without trouble.
I run
ssh -vvv -nN -R 9000:localhost:info info
On 2019-05-20, William Unruh <unruh@invalid.ca> wrote:
----
I am trying to open an ssh tunnel from a machine (let me call it arby) behind a natting router to another
machine, so I can sign in to that hidden computer from the outside
machine, let me call it info. Info is the name of the outside machine.
I can log on to info from arby using passwordless logon without trouble.
I run
ssh -vvv -nN -R 9000:localhost:info info
that bit might be wrong. should be the sshd port number.
I am trying to open an ssh tunnel from a machine (let me call it arby) behind a natting router to another
machine, so I can sign in to that hidden computer from the outside
machine, let me call it info. Info is the name of the outside machine.
I can log on to info from arby using passwordless logon without trouble.
I run
ssh -vvv -nN -R 9000:localhost:22 info
where info is the outside machine.
Unfortunately it does not work
Here is the end of the log produced by -vvv, after logs state tht there
was a successful logon onto info
debug1: remote forward failure for: listen 8024, connect localhost:22 Warning: remote port forwarding failed for listen port 8024
-----------------------------------------------------
And this is the end of an attempt by another machine barby which
connected to info from behind another natting router.
debug1: remote forward success for: listen 8024, connect localhost:22
debug1: All remote forwarding requests processed
On 20/05/2019 08.25, William Unruh wrote:
I am trying to open an ssh tunnel from a machine (let me call it arby) behind a natting router to another
machine, so I can sign in to that hidden computer from the outside
machine, let me call it info. Info is the name of the outside machine.
I can log on to info from arby using passwordless logon without trouble.
I run
ssh -vvv -nN -R 9000:localhost:22 info
where info is the outside machine.
Unfortunately it does not work
Here is the end of the log produced by -vvv, after logs state tht there
was a successful logon onto info
debug1: remote forward failure for: listen 8024, connect localhost:22
Warning: remote port forwarding failed for listen port 8024
-----------------------------------------------------
And this is the end of an attempt by another machine barby which
connected to info from behind another natting router.
debug1: remote forward success for: listen 8024, connect localhost:22
debug1: All remote forwarding requests processed
Feels more like you tested barby before you tested arby, so the port
9000 would already be occupied on the remote machine, you need to see to
that each machine you connect to the remote one will use it's own port.
I am trying to open an ssh tunnel from a machine (let me call it
arby) behind a natting router to another machine, so I can sign in to
that hidden computer from the outside machine, let me call it info.
Info is the name of the outside machine. I can log on to info from
arby using passwordless logon without trouble.
I run
ssh -vvv -nN -R 9000:localhost:info info
where info is the outside machine.
Unfortunately it does not work
Here is the end of the log produced by -vvv, after logs state tht
there was a successful logon onto info
-------------------------------------------------------------
debug1: Authentication succeeded (publickey).
Authenticated to info ([142.103.xxx.xxx]:22).
debug1: Remote connections from LOCALHOST:8024 forwarded to local
address localhost:22 debug3: send packet: type 80
debug2: fd 3 setting TCP_NODELAY
debug3: ssh_packet_set_tos: set IP_TOS 0x48
debug1: Requesting no-more-sessions@openssh.com
debug3: send packet: type 80
debug1: Entering interactive session.
debug1: pledge: exec
debug3: receive packet: type 80
debug1: client_input_global_request: rtype hostkeys-00@openssh.com
want_reply 0 debug3: receive packet: type 4
debug1: Remote: Forwarding listen address "localhost" overridden by
server GatewayPorts debug3: receive packet: type 82
debug1: remote forward failure for: listen 8024, connect localhost:22 Warning: remote port forwarding failed for listen port 8024
debug1: All remote forwarding requests processed
debug3: send packet: type 1
-----------------------------------------------------
And this is the end of an attempt by another machine barby which
connected to info from behind another natting router.
-----------------------------------------------------
debug1: Authentication succeeded (publickey).
Authenticated to info ([142.103.234.23]:22).
debug1: Remote connections from LOCALHOST:8024 forwarded to local
address localhost:22 debug3: send packet: type 80
debug2: fd 3 setting TCP_NODELAY
debug3: ssh_packet_set_tos: set IP_TOS 0x48
debug1: Requesting no-more-sessions@openssh.com
debug3: send packet: type 80
debug1: Entering interactive session.
debug1: pledge: exec
debug3: receive packet: type 80
debug1: client_input_global_request: rtype hostkeys-00@openssh.com
want_reply 0 debug3: receive packet: type 4
debug1: Remote: Forwarding listen address "localhost" overridden by
server GatewayPorts debug3: receive packet: type 81
debug1: remote forward success for: listen 8024, connect localhost:22
debug1: All remote forwarding requests processed
debug3: receive packet: type 90
The only difference seems to be that in second case it succeeded and
the first it failed. What could be the problem, and how can I track it
down? The second shows that the machine info does allow port
forwarding. Why could it be failing in the first case?
Groovy hepcat William Unruh was jivin' in alt.os.linux on Mon, 20 May
2019 04:25 pm. It's a cool scene! Dig it.
I am trying to open an ssh tunnel from a machine (let me call it
arby) behind a natting router to another machine, so I can sign in to
that hidden computer from the outside machine, let me call it info.
Info is the name of the outside machine. I can log on to info from
arby using passwordless logon without trouble.
I'm not sure I understand you. You're at arby and trying to create a
tunnel to info so that you can log into arby from info? If that's
correct, why not just ssh to arby from info? You can use dyndns and
your router's port forwarding.
I run
ssh -vvv -nN -R 9000:localhost:info info
I could be wrong here, so please forgive me if I am, but I think what
you are doing here is telling the ssh daemon on the remote host (info)
to make a tunnel to localhost. That is localhost as seen from the
remote side (info), not the local machine (arby), I think. So you're effectively trying to connect from one port on info to another port on
info.
Also I think you need a port number in the third field of the argument
to the -R option, not a host name. (According to man ssh on my system
it's a port number or a socket.)
And if you do sort out those problems, does your router have port forwarding from outside to arby enabled?
where info is the outside machine.
Unfortunately it does not work
Here is the end of the log produced by -vvv, after logs state tht
there was a successful logon onto info
-------------------------------------------------------------
debug1: Authentication succeeded (publickey).
Authenticated to info ([142.103.xxx.xxx]:22).
debug1: Remote connections from LOCALHOST:8024 forwarded to local
address localhost:22 debug3: send packet: type 80
See here it says "Remote connections from LOCALHOST:8024 forwarded to
local address localhost:22". That is, I believe, coming from the remote machine (info) and saying that it has tunnelled its own port 8024 to
its own port 22.
debug2: fd 3 setting TCP_NODELAY
debug3: ssh_packet_set_tos: set IP_TOS 0x48
debug1: Requesting no-more-sessions@openssh.com
debug3: send packet: type 80
debug1: Entering interactive session.
debug1: pledge: exec
debug3: receive packet: type 80
debug1: client_input_global_request: rtype hostkeys-00@openssh.com
want_reply 0 debug3: receive packet: type 4
debug1: Remote: Forwarding listen address "localhost" overridden by
server GatewayPorts debug3: receive packet: type 82
debug1: remote forward failure for: listen 8024, connect localhost:22
Warning: remote port forwarding failed for listen port 8024
debug1: All remote forwarding requests processed
debug3: send packet: type 1
-----------------------------------------------------
And this is the end of an attempt by another machine barby which
connected to info from behind another natting router.
-----------------------------------------------------
debug1: Authentication succeeded (publickey).
Authenticated to info ([142.103.234.23]:22).
debug1: Remote connections from LOCALHOST:8024 forwarded to local
address localhost:22 debug3: send packet: type 80
debug2: fd 3 setting TCP_NODELAY
debug3: ssh_packet_set_tos: set IP_TOS 0x48
debug1: Requesting no-more-sessions@openssh.com
debug3: send packet: type 80
debug1: Entering interactive session.
debug1: pledge: exec
debug3: receive packet: type 80
debug1: client_input_global_request: rtype hostkeys-00@openssh.com
want_reply 0 debug3: receive packet: type 4
debug1: Remote: Forwarding listen address "localhost" overridden by
server GatewayPorts debug3: receive packet: type 81
debug1: remote forward success for: listen 8024, connect localhost:22
debug1: All remote forwarding requests processed
debug3: receive packet: type 90
The only difference seems to be that in second case it succeeded and
the first it failed. What could be the problem, and how can I track it
down? The second shows that the machine info does allow port
forwarding. Why could it be failing in the first case?
I can't explain why this seems to work from barby while failing from
arby. Have you actually been able to use the created tunnel to access
barby from info? My guess is you haven't.
Anyhow, if I'm correct about what the problem is, you may get better results by:
a) enabling port forwarding on your router to a login port on arby,
b) using a service like dyndns to determine your router's IP address (actually your ISP's, but ports should be forwarded from there to
equivalent ones on your router),
c) using that and the forwarded port number in the argument to the -R
option of ssh.
For example, suppose you forward port 1234 on your router to port 22
(the ssh daemon so you can get a login shell) on arby and your router's
IP address is 12.34.56.78, you might do something like:
ssh -vvv -nN -R 9000:12.34.56.78:1234 info
I just want to reiterate that I am not certain about all this. I could
be completely wrong. Also I wasn't entirely sure I understood what
you're trying to do. So please take my comments with due caution.
ssh tunnel is the only option. Note that I have done this many times
in the past. This is the first time that I have had trouble and it
seems to be sporadic. Sometimes it works and sometimes not it seems.
On 5/21/19 4:51 PM, William Unruh wrote:
ssh tunnel is the only option. Note that I have done this many times
in the past. This is the first time that I have had trouble and it
seems to be sporadic. Sometimes it works and sometimes not it seems.
ProTip: Specify "127.0.0.1" instead of "localhost" to avoid issues with "localhost" resolving to "::1" unexpectedly. (Or make sure that ::1
works in addition to 127.0.0.1.)
I trust that the ssh remote port forwarding can work. As such, I'm questioning if the connection between arby and info is going down or
being closed by a naive firewall.
Check to make sure that TCP keep-alive packets are being sent
(TCPKeepAlive, both client and server).
You might also be dealing with some stale forwarding on info if the connection goes down and tries to come back up before info has detected
this and cleared the old port forwarding.
I am trying to open an ssh tunnel from a machine (let me call it arby) behind a natting router to another
machine, so I can sign in to that hidden computer from the outside
machine, let me call it info. Info is the name of the outside machine.
I can log on to info from arby using passwordless logon without trouble.
I run
ssh -vvv -nN -R 9000:localhost:info info
where info is the outside machine.
Unfortunately it does not work
Here is the end of the log produced by -vvv, after logs state tht there
was a successful logon onto info
-------------------------------------------------------------
debug1: Authentication succeeded (publickey).
Authenticated to info ([142.103.xxx.xxx]:22).
debug1: Remote connections from LOCALHOST:8024 forwarded to local address localhost:22
debug1: remote forward failure for: listen 8024, connect localhost:22 Warning: remote port forwarding failed for listen port 8024
Feels more like you tested barby before you tested arby, so the port
9000 would already be occupied on the remote machine, you need to see to
that each machine you connect to the remote one will use it's own port.
Nope. arby was first. I went to barby only to see if I could make things
work from another machine. I also made sure that any ssh port forwarding
was killed before trying it from another machine. I do and did recognise
the possibility of port blocking.
On Tue, 21 May 2019 16:09:43 -0400, William Unruh <unruh@invalid.ca> wrote:
Feels more like you tested barby before you tested arby, so the port
9000 would already be occupied on the remote machine, you need to see to >>> that each machine you connect to the remote one will use it's own port.
Nope. arby was first. I went to barby only to see if I could make things
work from another machine. I also made sure that any ssh port forwarding
was killed before trying it from another machine. I do and did recognise
the possibility of port blocking.
Are they on the same isp? I'm thinking the one isp may be blocking
the connection. I've seen isp do pretty crazy things in the name of preventing abuse.
I'd try having ssh listen on a port other then 22, like 22222, to see
if that makes a difference.
Regards, Dave Hodgins
OK, that is a possibility. I will try that.
Yes, it can work. It works from barby, and it worked in the past
from a different machine called arby. And now it suddenly started to sometimes work and sometimes not.
The problem is that the tunnel never gets set up. The log in works, everything (on the arby side) looks like it is getting set up, and
then at the end it says that the tunnel has not been set up.
I do not think so. It did not work even even a day after ( and a
shutdown on arby-- its a laptop) the last time I tried.
I have tried it onto another remote machine (call it message) and
the tunnel works. Bizarre.
On 5/21/19 11:33 PM, William Unruh wrote:
OK, that is a possibility. I will try that.
Yes, it can work. It works from barby, and it worked in the past
from a different machine called arby. And now it suddenly started to
sometimes work and sometimes not.
Does it sometimes work and not work from the same system? Or different systems?
The problem is that the tunnel never gets set up. The log in works,
everything (on the arby side) looks like it is getting set up, and
then at the end it says that the tunnel has not been set up.
Check the ssh daemon logs on info. OpenSSH is usually quite good about indicating if it can't establish a tunnel, and why not.
I do not think so. It did not work even even a day after ( and a
shutdown on arby-- its a laptop) the last time I tried.
I'm more convinced by the time than I am the shutdown of arby. What
does "(sudo) netstat -lntp" show on info, particularly about the port
that you're trying to bind to on info, when it fails?
I have tried it onto another remote machine (call it message) and
the tunnel works. Bizarre.
I'm guessing that there is something that is preventing the tunneling
from working. The trick is to find what that something is.
Yes, same system.
Where are the sshd logs? I cannot find almost any info from sshd, except
a couple of lines in /var/log/auth.log
Yes, that is what I am trying to do here in this thread-- hints as to
where I could look for that "something"
On 5/22/19 5:29 PM, William Unruh wrote:
Yes, same system.
Okay.
Then it's likely not a configuration issue per say. (It might be
something related to timeouts / retries.)
Where are the sshd logs? I cannot find almost any info from sshd, except
a couple of lines in /var/log/auth.log
I'd expect them to be in /var/log. Usually /var/log/syslog or /var/log/messages. Do an "ls -l /var/log" and look at the files that
were recently modified.
Yes, that is what I am trying to do here in this thread-- hints as to
where I could look for that "something"
ACK
You can crank verbosity up on the server side. You could run the ssh
daemon interactively, though doing so can be tricky.
Check the logs mentioned above.Yes. Nothing there of any help.
On 5/22/19 5:29 PM, William Unruh wrote:
Yes, same system.
Okay.
Then it's likely not a configuration issue per say. (It might be
something related to timeouts / retries.)
Where are the sshd logs? I cannot find almost any info from sshd, except
a couple of lines in /var/log/auth.log
I'd expect them to be in /var/log. Usually /var/log/syslog or /var/log/messages. Do an "ls -l /var/log" and look at the files that
were recently modified.
Yes, that is what I am trying to do here in this thread-- hints as to
where I could look for that "something"
ACK
You can crank verbosity up on the server side. You could run the ssh
daemon interactively, though doing so can be tricky.
Check the logs mentioned above.
Actually I finally found the sshd_config LogLevel directive. However,
the syslog LogLevel does NOT have a DEBUG1, DEBUG2 and DEBUG3 Loglevels
which apparently (nothing documented anywhere) sshd uses for the
debug levels. I have no idea what loglevels for syslog these map to.
Nope. Nor in journalctl. (Yes, I run both rsyslog and systemd journal).
All you get are some basic posts to auth.log, which tell one nothing. /var/log/messages and esp /var/log/syslog are altered abount once
per second by all sorts of stuff.
Yes, it can be tricky, esp for a server machine.
I have looked at man sshd, and there does not seem to be a way of
increasing the verbosity which is logged to syslog.
The only opion is the -d option which "Debug mode. The server sends
verbose debug output to standard error, and does not put itself
in the background. The server also will not fork and will only
process one connection. This option is only intended for debugging
for the server. Multiple -d options increase the debugging level.
Maximum is 3." which is not very helpful.
I would like an option which increases the verbosity, but dumps the
stuff into the system log, not into stderr.
Yes. Nothing there of any help.
On 5/23/19 1:43 AM, William Unruh wrote:
Actually I finally found the sshd_config LogLevel directive. However,
the syslog LogLevel does NOT have a DEBUG1, DEBUG2 and DEBUG3 Loglevels
which apparently (nothing documented anywhere) sshd uses for the
debug levels. I have no idea what loglevels for syslog these map to.
LogLevel (and it's values) have nothing to do with syslog. Instead they
are parameters to tell the ssh daemon how much detail / data to log.
Further, this logging will be independent of the location that logs are
sent to, STDOUT, STDERR, syslog, etc. They don't have anything to do
with which syslog log level is used.
On 5/23/19 1:11 AM, William Unruh wrote:
Nope. Nor in journalctl. (Yes, I run both rsyslog and systemd journal).
All you get are some basic posts to auth.log, which tell one nothing.
/var/log/messages and esp /var/log/syslog are altered abount once
per second by all sorts of stuff.
Okay. Try "grep ssh /var/log/*" as a user with permission to read the
files.
Yes, it can be tricky, esp for a server machine.
Or if you want to change the ssh daemon in a way that requires
restarting ssh when you're using ssh to connect to said machine.
It is the fact that it dumpsI have looked at man sshd, and there does not seem to be a way of
increasing the verbosity which is logged to syslog.
Search the sshd_config man page for "LogLevel".
The only opion is the -d option which "Debug mode. The server sends
verbose debug output to standard error, and does not put itself
in the background. The server also will not fork and will only
process one connection. This option is only intended for debugging
for the server. Multiple -d options increase the debugging level.
Maximum is 3." which is not very helpful.
It can be helpful in some situations.
I would like an option which increases the verbosity, but dumps the
stuff into the system log, not into stderr.
"LogLevel"
You may even be able to use the -o option to specify the LogLevel config parameter on the command line.
-o is a way to specify config parameters on the command line that don't
have a command line option themselves, like "LogLevel".
Yes. Nothing there of any help.
That surprises me.
On 2019-05-24, Grant Taylor <gtaylor@tnetconsulting.net> wrote:
On 5/23/19 1:43 AM, William Unruh wrote:
Actually I finally found the sshd_config LogLevel directive. However,
the syslog LogLevel does NOT have a DEBUG1, DEBUG2 and DEBUG3 Loglevels
which apparently (nothing documented anywhere) sshd uses for the
debug levels. I have no idea what loglevels for syslog these map to.
LogLevel (and it's values) have nothing to do with syslog. Instead they
are parameters to tell the ssh daemon how much detail / data to log.
Further, this logging will be independent of the location that logs are
sent to, STDOUT, STDERR, syslog, etc. They don't have anything to do
with which syslog log level is used.
Well, not really true. For example SyslogFacility is the syslog
facility. And at least the higher levels of LogLevel ARE the syslog
loglevels (ie, using /etc/syslog.conf you can restrict the output.)
Actually it is not too bad.
When you ssh in, the sshd starts up another instance of itself to handle
your connection. When you kill the main sshd daemon (or restart sshd
from whatever init system youuse) you copy of ssh does not get altered.
Well, not really true.
For example SyslogFacility is the syslog facility.
And at least the higher levels of LogLevel ARE the syslog loglevels (ie, using /etc/syslog.conf you can restrict the output.)
On 5/23/19 11:36 PM, William Unruh wrote:
Well, not really true.
I disagree.
For example SyslogFacility is the syslog facility.
SyslogFacility is a separate parameter from LogLevel. The former
specifies what syslog facility sshd should log as. The latter specifies
what amount of detail sshd should log as.
I don't see how the syslog facility used has any influence on the amount
/ detail of logs that sshd generates. (Of course it's independent of
what the syslog daemon actually filters and records.)
And at least the higher levels of LogLevel ARE the syslog loglevels (ie,
using /etc/syslog.conf you can restrict the output.)
The name collision is immaterial. The fact that some, but not all,
LogLevels correlate with syslog levels supports that they are not the
same. The names could be SLAAAAAAAAAA, SLBBBBBBBB, SLCCCCCC, SLDDDD,
SLEE for all it matters. The parameter that sshd uses is matched in a
case statement (thank you Per H.) and translated to a syslog level.
Hence why I say that there is no direct correlation between LogLevel and syslog level. There is a loose correlation with some overlap. But they
are decidedly not the same thing.
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 292 |
Nodes: | 16 (2 / 14) |
Uptime: | 192:10:02 |
Calls: | 6,616 |
Files: | 12,166 |
Messages: | 5,315,292 |