VMware Cloud Community
Wittbert
Contributor
Contributor

Allow SSH Access to ESX by only 2 IP's (sshd_config)

Hello Guys!

Today I tried to restrict the SSH-Access to my ESX-Server that only the Management-Server and my Workstation are allowed to access the ESX 3.5-Server via SSH.

The Management Server's IP is 172.16.5.230 and the IP of my WS is 172.16.5.1.

So I edited the sshd_config and edited the "#ListenAddress 0.0.0.0" to

ListenAddress 172.16.5.230

ListenAddress 172.16.5.1

after saving these changes I restarted the sshd using /sbin/services sshd restart.

Then I tried to connect my ESX-Server via SSH (Putty). After a few seconds a "refused connection" error occured. Now I can only access the ESX directly on the console.

When I undo the ListenAddress changes and set the default #ListenAddress 0.0.0.0 I can access my ESX-server from my complete LAN via SSH.

Does anybody has a clue what's wrong here?

Thanks in advance!

Kind Regards

Benjamin

Reply
0 Kudos
14 Replies
mcowger
Immortal
Immortal

You aren't using the right option.

That option specifies the address to which the sshd daemon will bind, not the hosts from which it will accept connection. Youtold it to bind to addresses it doesn't have, so it didn't listen to anything.

You need firewall rules to accomplish what you are looking for.

--Matt

--Matt VCDX #52 blog.cowger.us
Reply
0 Kudos
petedr
Virtuoso
Virtuoso

Matt's right abut the ListenAddress it is not the right parameter

This is the definition of what that parm is issue.

+The option ListenAddress specifies the IP address of the interface network on which the ssh daemon

server socket is bind. The default is 0.0.0.0; to improve

security you may specify only the required ones to limit possible addresses.+

As Matt said firewall settings may be the best approach.

www.thevirtualheadline.com www.liquidwarelabs.com
Reply
0 Kudos
Wittbert
Contributor
Contributor

Hello Guys, thanks for your fast reply!

Hmmm then I should leave the sshd_config setting on the default settings?

Can I configure the ESX-Firewall via the VC or via console? Can you give me a syntax example please? atm I didn't have a clue how to handle it ;X

Thanks!!

Kind regards

Benjamin

Reply
0 Kudos
mcowger
Immortal
Immortal

man esxcfg-firewall shoudl get you started.

--Matt

--Matt VCDX #52 blog.cowger.us
Reply
0 Kudos
petedr
Virtuoso
Virtuoso

I am not 100% sure since I haven't done this on an esx host but I think you may have to go to hosts.allow, hosts.deny (TCP wrappers) for blocking and allowing IPs.

This is a Red Hat link on the TCP wrappers:

http://www.redhat.com/docs/manuals/linux/RHL-9-Manual/ref-guide/s1-tcpwrappers-access.html

On esxcfg-firewall he is a good page on it from vmware-land

http://vmware-land.com/esxcfg-help.html

www.thevirtualheadline.com www.liquidwarelabs.com
Reply
0 Kudos
Texiwill
Leadership
Leadership

Hello,

There are two ways to do this. One is to use the following:

echo "sshd: IP1 IP2" > /etc/hosts.allow
echo "ALL: ALL" > /etc/hosts.deny

Or use pam_access.so. Use 'man pam_access'

The first item is TCP Wrappers and it is the easiest way to do this.


Best regards,

Edward L. Haletky

VMware Communities User Moderator

====

Author of the book 'VMWare ESX Server in the Enterprise: Planning and Securing Virtualization Servers', Copyright 2008 Pearson Education. As well as the Virtualization Wiki at http://www.astroarch.com/wiki/index.php/Virtualization

--
Edward L. Haletky
vExpert XIV: 2009-2023,
VMTN Community Moderator
vSphere Upgrade Saga: https://www.astroarch.com/blogs
GitHub Repo: https://github.com/Texiwill
Reply
0 Kudos
rpartmann
Hot Shot
Hot Shot

Hi,

the ListenAddress bind the sshd to the ip/interface on your server if you have a multihomed adapter and you do not want to have ssh on any interface, any interface is 0.0.0.0

esxcfg-firewall configures the firewall for the service console, but afaik the are too few options to that command to accomplish that.

But good news, esxcfg-firewall relies on iptables so you can use this command to get you result.

list rules: iptables -L -n --line-numbers

you could try something like that

esxcfg-firewall -d sshServer # yes i know this prevents ssh access!

iptables -A INPUT -p tcp --dport 22 -i vswif0 -s 172.16.5.230 -j ACCEPT

iptables -A INPUT -p tcp --dport 22 -i vswif0 -s 172.16.5.1 -j ACCEPT

hth,

Reinhard

ps: Award points if you find answers helpful. Thanks.

ps: Award points if you find answers helpful. Thanks.
Reply
0 Kudos
dwight
Enthusiast
Enthusiast

If you use a single > in the redirection you will overwrite the hosts.allow and hosts.deny files which may contain other settings and if they are the default files you will loose the comments in the files.

This will only change the sshd settings in /etc/hosts.allow:

grep -v ^sshd: /etc/hosts.allow > /etc/hosts.allow.new

echo "sshd: IP1 IP2" > /etc/hosts.allow.new

cp /etc/hosts.allow.new /etc/hosts.allow

The default /etc/hosts.deny file doesn't contain any settings. This command will append the deny rule without deleting what's already in the hosts.deny file.:

echo "ALL: ALL" >> /etc/hosts.deny


RHCE, VCP

Blog: http://computing.dwighthubbard.info

RHCE, VCP Blog: http://computing.dwighthubbard.info
Reply
0 Kudos
Texiwill
Leadership
Leadership

Hello,

The following will still overwrite the /etc/hosts.allow file.

This will only change the sshd settings in /etc/hosts.allow:

grep -v ^sshd: /etc/hosts.allow > /etc/hosts.allow.new

echo "sshd: IP1 IP2" > /etc/hosts.allow.new

This should be:

echo "sshd: IP1 IP2" >> /etc/hosts.allow.new

cp /etc/hosts.allow.new /etc/hosts.allow

However, the use of an editor to add these into the files is preferred unless you really like Linux scripting. Also more help is available using 'man hosts.allow'.


Best regards,

Edward L. Haletky

VMware Communities User Moderator

====

Author of the book 'VMWare ESX Server in the Enterprise: Planning and Securing Virtualization Servers', Copyright 2008 Pearson Education. As well as the Virtualization Wiki at http://www.astroarch.com/wiki/index.php/Virtualization

--
Edward L. Haletky
vExpert XIV: 2009-2023,
VMTN Community Moderator
vSphere Upgrade Saga: https://www.astroarch.com/blogs
GitHub Repo: https://github.com/Texiwill
Reply
0 Kudos
Wittbert
Contributor
Contributor

Hello guys!

thank you so much for the numerous explanations! I think I'll do it via editing the host files.....

I'll give you feedback next week.

Kind regards Benjamin

Reply
0 Kudos
Named_Jason
Contributor
Contributor

Does anyone know the name of the service that is responsible for the VI Client connections? I've tried vmware-authd, vmware-hostd and xinetd in my hosts.deny file, but none have denied my IP from logging in via the client. I notice that /var/log/messages seems to refer to vmware-hostd as the service that logs in, but it always authenticates from 127.0.0.1... I'm not sure what to make of that.

Reply
0 Kudos
dwight
Enthusiast
Enthusiast

In order for a service to be configurable using the /etc/hosts.allow and /etc/hosts.deny it must be compiled with tcpwrappers support. Not all binaries are compiled with it and as a result the only way to restrict them is using application configuration or firewall rules. I've never checked but I would imagine the vi client doesn't support tcpwrappers...

RHCE, VCP

Blog:

RHCE, VCP Blog: http://computing.dwighthubbard.info
Reply
0 Kudos
Named_Jason
Contributor
Contributor

I took the DSA class about a year ago and they mentioned that vmware-authd uses xinetd which is linked against the libwrap.so library (and therefore "wrapped"), but that training was for ESX 3.0. I'm currently trying to use the hosts.deny configuration from such a host (vmware-authd:<Banned-IP>:deny) without any success, which is why I took a look at the /var/log/messages file (which led to my confusion about the name of the service and the way it authenticates). I'm wondering if ESX 3.5 doesn't link to that library...

Reply
0 Kudos
rpartmann
Hot Shot
Hot Shot

hi,

well then you should try iptables. (see previous post)

I think the firewall way is the better one because when, tcp wrapper

ist handling

access/deny of a service the packets have left the kernel.

And with iptables the can be discarded very early.

Just a thought.

hth,

Reinhard.

ps: Award points if you find answers helpful. Thanks.
Reply
0 Kudos