-
29th June 2012, 10:15 PM
#1
sshd awkardness -- "ListenAddress" keyword
Hi all,
I wonder whether anyone could help with a ssh issue that I've never seen before:
I have recently set up two Fedora 17 machines: a server/router (32 bit) with two NICs and a regular desktop machine (64bit). On both machines, I did a basic firewall configuration with the graphical tool. After that, I was able to log on to the server machine (now headless) with SSH -- no problem whatsoever at first. No changes have been made to the ssh config on the client side BTW.
Unfortunately, being aware that the firewall wasn't ideal (it's going to be replaced later on), I tried to fiddle with the SSH setup on the server, trying to force sshd to listen on the internal network side only (it's connected to the Internet on the external NIC via a DSL modem). So I read some man pages and edited /etc/ssh/sshd_config:
#Port22
#AddressFamily any
#ListenAddress 0.0.0.0
#ListenAddress ::
ListenAddress 192.168.2.1:22
.
.
.
PermitRootLogin no
.
So apart from the root thing, I only inserted the ListenAddress rule. I first did it without specifying the port, then as above, and finally specifying the port in the first "Port" line only -- but each time I got locked out with a "connection denied" message.
Why, I have no idea. In those cases where the connection fails, /var/log/secure says: "error: Bind to port 22 on 192.168.2.1 failed: Cannot assign requested address". -- Pardon? I simply don't understand what's going on here -- could anyone please explain what this all means?
(BTW, if I leave the config file as is, i.e. without specifying the ListenAddress rule, /var/log/secure says: "Server listening on 0.0.0.0 port 22" -- so far as expected. However, as soon as I connect from the desktop machine, it reads: "Accepted password for [user] from 192.168.2.68 port 53408 sssh2". And there are lots of other high ports being mentioned here, each time a different one it seems -- I don't think it's related to the above issue, but it's still confusing me. What are these high ports for?)
I'm not an IT guy but I've been using Linux since 1996, and these things leave me scratching my head, asking myself whether I should finally drop Linux. OK the ports thing, I guess that's just my ignorance, but otherwise ... I had originally planned to install Fedora on a dedicated server to which I would have access over ssh only -- but of course I would depend on the benevolence of my provider by now... So, close but no cigar
I have searched around but with no conclusive results. I mean, the manpage of sshd_config couldn't be any clearer on the ListenAddress rule, the instructions are as simple as it gets. But it seems this simplicity is deceptive. What am I missing here?
Thanks in advance for any help you might be able to come up with.
Last edited by opolt; 29th June 2012 at 10:18 PM.
-
29th June 2012, 10:49 PM
#2
Re: sshd awkardness -- "ListenAddress" keyword
Maybe you did that but i will sugest anyway:
Restart sshd:
# systemctl restart sshd.service
and check the firewall if you have the port 22 opened:
# gedit /etc/sysconfig/iptables
then restart iptables too:
# systemctl restart iptables.service
-
29th June 2012, 11:04 PM
#3
Re: sshd awkardness -- "ListenAddress" keyword
Colors,
thanks a lot for your reply -- I had considered the possibility of the firewall blocking the service, but that doesn't seem to be the case.
First, because I can access the server over ssh as long as I don't explicitly specify anything under "ListenAddress", without any changes to the current iptable rules.
Second, because I had enabled port 22 in the original firewall setup. In /etc/sysconfig/iptables, it says:
-A INPUT -m state -m state NEW -m tcp - p tcp --dport 22 - j ACCEPT
So I don't know.
-
29th June 2012, 11:23 PM
#4
Re: sshd awkardness -- "ListenAddress" keyword
ListenAddress 192.168.2.1:22
Seems OK, but I've never used the port spec in the ListenAddress.
As Colors said, ALWAYS restart sshd after you change sshd_config (( sudo systemctl restart sshd.service ))
You do not need to specify port 22, it's the default unless you specify some other ports.
On the sshd server do "sudo netstat -ntpl" (or otherwise run as root) and see what it reports for sshd
You should see 1 tcp line, with your 192.168.2.1 interface specified.
If not then post
for the server.
-
29th June 2012, 11:38 PM
#5
Re: sshd awkardness -- "ListenAddress" keyword
Stevea,
as I said, I also tried without specifying the port at all, with the same lockout.
I also forgot to mention that I always did the restart thing -- seemed obvious to me.
Currently, netstat -ntplt returns this:
tcp 0 0 127.0.0.1:25 0.0.0.0:* LISTEN 627/sendmail: accep
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 600/sshd
tcp 0 0 0.0.0.0:631 0.0.0.0:* LISTEN 462/cupsd
tcp6 0 0 :::22 :::* LISTEN 600/sshd
tcp6 0 0 :::631 :::* LISTEN 1/systemd
That is the configuration, without specifying anything for "ListenAddress" BTW.
The "ip" commands return this:
default via 192.168.1.254 dev p1p1 proto static
192.168.1.0/24 dev p1p1 proto kernel scope link src 192.168.1.1
192.168.2.0/24 dev p3p1 proto kernel scope link src 192.168.2.1
...
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: em1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN qlen 1000
link/ether 00:0d:60:65:04:3d brd ff:ff:ff:ff:ff:ff
3: p1p1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 1000
link/ether 00:08:54:0f:ed:5f brd ff:ff:ff:ff:ff:ff
inet 192.168.1.1/24 brd 192.168.1.255 scope global p1p1
inet6 fe80::208:54ff:fe0f:ed5f/64 scope link
valid_lft forever preferred_lft forever
4: p3p1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 1000
link/ether 00:08:54:0f:ed:49 brd ff:ff:ff:ff:ff:ff
inet 192.168.2.1/24 brd 192.168.2.255 scope global p3p1
inet6 fe80::208:54ff:fe0f:ed49/64 scope link
valid_lft forever preferred_lft forever
In my previous research I have found some evidence that it might have to do with the interfaces being configured for both IPv4 and IPv6, which the above output seems to confirm, but I would be totally unable to resolve any conflict of this type on my own ...
-
30th June 2012, 01:07 AM
#6
Re: sshd awkardness -- "ListenAddress" keyword
I can say that i done a test and all that i changed was the line
ListenAddress 0.0.0.0
to my ip adress.
Then stopped sshd
systemctl stop sshd.service
and checked in terminal
# /sbin/sshd -d -f /etc/ssh/sshd_config
debug1: sshd version OpenSSH_5.9p1
debug1: read PEM private key done: type RSA
debug1: private host key: #0 type 1 RSA
debug1: read PEM private key done: type DSA
debug1: private host key: #1 type 2 DSA
debug1: rexec_argv[0]='/sbin/sshd'
debug1: rexec_argv[1]='-d'
debug1: rexec_argv[2]='-f'
debug1: rexec_argv[3]='/etc/ssh/sshd_config'
Set /proc/self/oom_score_adj from 0 to -1000
debug1: Bind to port 22 on 192.168.1.64.
Server listening on 192.168.1.64 port 22.
EDIT: delete all the files from ~/.ssh directory then restart sshd and try again.
Last edited by Colors; 30th June 2012 at 08:25 PM.
-
30th June 2012, 01:45 PM
#7
Re: sshd awkardness -- "ListenAddress" keyword
There is another thread on the forum about this firewall problem.
But there is something else wrong ....
debug1: Bind to port 22 on 192.168.1.64.
Server listening on 192.168.1.64 port 22.
You posted 192.168.1.1, not ...64.
-
30th June 2012, 03:39 PM
#8
Re: sshd awkardness -- "ListenAddress" keyword
Not sure what you mean...
-
2nd July 2012, 11:57 PM
#9
Re: sshd awkardness -- "ListenAddress" keyword
Hi stevea,
thanks for your suggestions. Are you referring to this thread?
The suspicion is that the fault arises from IPv6 being implicitly enabled by the default configuration of the daemon. However, I don't think this is the case, because according to what is said at the beginning of the sshd_config file (and in that discussion thread), "ListenAddress 192.168.2.1" should explicitly enable IPv4 and disable IPv6 at the same time. So I don't know.
BTW could anyone please clarify my doubts about the high ports appearing in the logs, as mentioned in my original post?
I'm still investigating this. Overall, it's not really a show stopper -- but only if you know about it beforehand. If this hits you on a remote server and you're unprepared, you're seriously out of luck. So unless I've overlooked anything, it's a bug. Or some piece of documentation is missing here. At the very minimum, the config file should include a big, big warning.
-
3rd July 2012, 05:25 PM
#10
Re: sshd awkardness -- "ListenAddress" keyword
Originally Posted by
opolt
Hi all,
I wonder whether anyone could help with a ssh issue that I've never seen before:
I have recently set up two Fedora 17 machines: a server/router (32 bit) with two NICs and a regular desktop machine (64bit). On both machines, I did a basic firewall configuration with the graphical tool. After that, I was able to log on to the server machine (now headless) with SSH -- no problem whatsoever at first. No changes have been made to the ssh config on the client side BTW.
Unfortunately, being aware that the firewall wasn't ideal (it's going to be replaced later on), I tried to fiddle with the SSH setup on the server, trying to force sshd to listen on the internal network side only (it's connected to the Internet on the external NIC via a DSL modem). So I read some man pages and edited /etc/ssh/sshd_config:
#Port22
#AddressFamily any
#ListenAddress 0.0.0.0
#ListenAddress ::
ListenAddress 192.168.2.1:22
.
.
.
PermitRootLogin no
.
So apart from the root thing, I only inserted the ListenAddress rule. I first did it without specifying the port, then as above, and finally specifying the port in the first "Port" line only -- but each time I got locked out with a "connection denied" message.
Why, I have no idea. In those cases where the connection fails, /var/log/secure says: "error: Bind to port 22 on 192.168.2.1 failed: Cannot assign requested address". -- Pardon? I simply don't understand what's going on here -- could anyone please explain what this all means?
(BTW, if I leave the config file as is, i.e. without specifying the ListenAddress rule, /var/log/secure says: "Server listening on 0.0.0.0 port 22" -- so far as expected. However, as soon as I connect from the desktop machine, it reads: "Accepted password for [user] from 192.168.2.68 port 53408 sssh2". And there are lots of other high ports being mentioned here, each time a different one it seems -- I don't think it's related to the above issue, but it's still confusing me. What are these high ports for?)
The high port is a dynamically assigned port number on the CLIENT machine that allows the server to communicate back with the client. Let me explain; it is very likely that the client machine is also running an ssh server on port 22, so when you connect to another server on its port 22, it can't communicate back on port 22 since the client's port 22 is already occupied by another process.
I'm not an IT guy but I've been using Linux since 1996, and these things leave me scratching my head, asking myself whether I should finally drop Linux. OK the ports thing, I guess that's just my ignorance, but otherwise ... I had originally planned to install Fedora on a dedicated server to which I would have access over ssh only -- but of course I would depend on the benevolence of my provider by now... So, close but no cigar
I have searched around but with no conclusive results. I mean, the manpage of sshd_config couldn't be any clearer on the ListenAddress rule, the instructions are as simple as it gets. But it seems this simplicity is deceptive. What am I missing here?
Thanks in advance for any help you might be able to come up with.
You've made some points about ipv4 vs ipv6. From what I understand about the configuration, setting the ipv4 listening address explicitly won't disable ipv6 listening! It might instead get all munged up if you don't explicitly set the ipv6 address as well, or set it to ipv4 only.
You should try setting "AddressFamily inet"
** the default is "any", and other option is "inet6". Setting as above will disable ipv6.
Also; when you make your changes to the sshd_config, do NOT just "restart" sshd, and ESPECIALLY do not "reload". Stop first, ensure that all sshd processes are ended (i.e., there should be ZERO connections over ssh -- can try 'killall -9 sshd'), and then start sshd again.
-
9th July 2012, 02:23 AM
#11
Re: sshd awkardness -- "ListenAddress" keyword
Fwiw, I have 4 default installs of fedora 17 with active ssh and all function without modification. The only difference I see is I have disabled the filewall and all iptables services, I am behind a firewall from my router. Personally I do not see any reason to run a firewall on a computer behind another firewall, my routes has served me extremely well in this respect.
-
9th July 2012, 02:27 AM
#12
Re: sshd awkardness -- "ListenAddress" keyword
A firewall on each system helps protect it from attacks from other systems that are behind the "firewall".
It only helps. But as seen with windows behind a "firewall", once one system is penetrated, it can then be used to attack others; and the "firewall" doesn't do anything about it.
-
9th July 2012, 02:55 PM
#13
Re: sshd awkardness -- "ListenAddress" keyword
Originally Posted by
jpollard
A firewall on each system helps protect it from attacks from other systems that are behind the "firewall".
It only helps. But as seen with windows behind a "firewall", once one system is penetrated, it can then be used to attack others; and the "firewall" doesn't do anything about it.
I guess on the first point that is always a possibility. I don't just haphazardly elevate privileges to an unknown process.
Point two is a purely windows related issues, and you are correct that once one is infected then it will sweep through the entire network in most cases. Windows and the RPC model it uses is a, oh never mind that is a conversation not for this thread.
-
10th July 2012, 02:52 PM
#14
Re: sshd awkardness -- "ListenAddress" keyword
Only in that having a firewall on the host being attacked makes it much more obvious, and can defend against possible denial of service.
This becomes a defense against rogue MS hosts.
-
9th December 2014, 09:45 PM
#15
Re: sshd awkardness -- "ListenAddress" keyword
As is often the case, the topic has lost its focus and shifted to Windows from the main issue--one with which I've been plagued for a while as well. Therefore, I'm shamelessly resurrecting this thread in hopes of finding a fitting resolution to this problem. Does anyone have any thoughts on this matter? Two years since; I know we're all wiser and better-informed.
Similar Threads
-
By dorianrenato in forum Using Fedora
Replies: 1
Last Post: 21st November 2011, 04:09 AM
-
By pza in forum Security and Privacy
Replies: 1
Last Post: 27th January 2009, 10:43 AM
-
By neo_fox in forum Servers & Networking
Replies: 2
Last Post: 10th January 2008, 09:05 AM
-
By tc60045 in forum Security and Privacy
Replies: 3
Last Post: 19th July 2007, 06:32 AM
-
By wangfeng in forum Using Fedora
Replies: 0
Last Post: 23rd May 2005, 04:59 AM
Tags for this Thread
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules
[[template footer(Guest)]]