SSH - blocking SLOGIN from another server

[Anthony_141]

We have HP-UX 11.23 and a Redhat Linux server talking to each other though SSH. The HP-UX server sends information over to the Linux server through SCP as a specific (non-human) user.

The problem we're trying to address is users on the Linux box can SLOGIN over to the HP-UX server (requiring a password). We'd like this blocked so they can only login if they connect directly to the HP-UX server.

We have RSA tokens in place and want them to use the tokens every time they connect to the HP-UX server - we don't want them logging into the Linux server and then SLOGGING in to the HP-UX server (bypassing their RSA token).

For technical reason I won't get into, the Linux server isn't setup to require the RSA token (it's on the other side of a firewall).

We tried the AllowUsers option in sshd_config, but this ended up also blocking the direct logins.

So, to summarize:

1) we need the 2 servers to transfer data back and forth using SCP as a non-human user (a user than can not login direct to either server)
2) we want users to login direct to the HP-UX server
3)we do not want users to be able to SLOGIN from the Linux server over to the HP-UX server

Thanks for any advice!

[Tim Nelson]

Many things you can do.

Enable TCP-WRAPPERs. edit hosts.deny file with IP of linux server

If it were telnet I would say to modify the /var/adm/inetd.sec

You can play with IPsec

You can modify the sshd_config and maybe use #HostbasedAuthDenyUsers (not sure about this one )

[Court Campbell]

Depending on your version of ssh on hp-ux iot may already have tcp wrappers. Try:

# what /usr/sbin/sshd

and look for tcp wrappers.

[Anthony_141]

Yes, we have TCP-Wrappers enabled.

[Court Campbell]

I am still trying to wrap my head around this. I do not think tcp wrappers is going to help since it is more at the host level. And if you deny/allow users via AllowUsers/DenyUsers then that affects the ability even when not connected through the linux box. I was thinking you could turn of password authentication. So then you would have to use some other auth besides passwords, ie, your rsa setup. I guess you could try

PasswordAuthentication no

If that still allows passwords you can either update ssh, or change

UsePAM no

[Tim Nelson]

/etc/hosts.deny with the following will block ssh from linux_host

sshd : linux_host : DENY

[Court Campbell]

Tim,

if he blocks the host. then his process that copies files from the linux server to the hpux server will not work.

[Court Campbell]

I am not sure if this will work, but I guess you could try this in /etc/hosts.deny

sshd: linux_host EXCEPT user@linux_host

[Anthony_141]

That blocked the entire server - evidently the "EXCEPT" doesn't have any effect.

The message I got was:

ssh_exchange_identification: Connection closed by remote host
lost connection

[TTr]

How about starting a second sshd process on the HP box on a different port (with a different config file). Then block the linux server on the standard sshd and allow only the automated-SCP user on the second port. There is some work that needs to be done in the second config file to separate the port, pidfile, keysfile etc. I have not tried it but I think it is doable.

[TTr]

I actually verified this because it got me going. The important changes are a different config file, with a different port and a PID file. The keyfile location changes are optional.

The PID file is important because it is used in the RC start/stop sequencer.

You can also create separate /etc/rc.config.d/sshd and /sbin/init.d/secsh files and rc?.d links

[Tim Nelson]

Thanks for the correction Court.

I missed the "back and forth" parth of item 1

>>1) we need the 2 servers to transfer data back and forth using SCP as a non-human user (a user than can not login direct to either server)

[Matti_Kurkela]

How are the non-human SCP transfers set up? Do they use SSH keys, or .rhosts/.shosts files?

My first thought:

If they're using SSH keys, you could set "IgnoreRhosts yes" in /opt/ssh/etc/sshd_config file to disable the .rhosts/.shosts files.

Your users would still be able to set up SSH keys for themselves and log in using them... but you could make it more difficult (or even impossible) by setting the "AuthorizedKeysFile" option to some non-default value.

The default value is "%h/.ssh/authorized_keys". Setting it to something like "/var/sshkeys/%u/authorized_keys" and then setting restrictive permissions to /var/sshkeys hierarchy would allow you total control over who can use SSH keys and who can't.

---------
My second thought:

Note also that the AllowUsers/DenyUsers can take USER@HOST forms too, even with wildcard patterns.

The sshd_config man page says that the allow/deny directives are processed in this order: DenyUsers, AllowUsers, DenyGroups and finally AllowGroups. But it does not seem to say whether the process is stopped at the first match or not.

I cannot test at the moment, but one of the following should do the trick:

Either:
DenyUsers *@linux.box.example
AllowUsers scpuser@linux.box.example
(works if the later AllowUsers can override the first DenyUsers)

Or:
AllowUsers scpuser@linux.box.example
DenyGroups *@linux.box.example
(works if the first match wins, i.e. DenyGroups is not examined after an explicit AllowUsers is found to match)

MK

[Court Campbell]

Anthony,

I thought that might happen. tcp wrappers is geared toward host access, but I thought you could give it a shot. Matti's answer looks like it's a winner. But you will also need to add each user that needs access via ssh to the box. You might look into the AllowGroup directive. Then you can create a group that has users that are allowed to ssh into the server. Funny how the things that seem like they should be easy can start to seem so complicated.

[Anthony_141]

Looks like if you use the Deny options that the Allowed are ignored.

I may just have to use the Deny but then change some our scripts so we send from these servers (instead of the Linux servers doing the sending of data).