I've used ssh as a secure telnet up to now but done little else with it. The FreeBSD machines I look after on our internet-facing network all have one account which I connect to for administration. I've set up /etc/hosts.allow on all the machines to only allow ssh from a limited internal network range. Now I want to create a new account on one machine which will be accessible from the Internet as a whole, to be used for tunnelling of SMTP and POP3. I can't predict what the client IP address will be so I will have to remove the hosts.allow restriction. Is there any way I can: - still prevent connections to my admin user from anywhere except a restricted set of addresses - disallow shell access for the new account but still allow tunnelling I think I can solve the first problem by using a new login class and an entry in login.conf, but there may be better ways. I think I can solve the second by giving the new user a shell of /bin/cat (putting that in /etc/shells) but again there may be a neater way. jim
Volker Kindermann
2004-Oct-07 10:53 UTC
Question restricting ssh access for some users only
Hi Jim,> I've used ssh as a secure telnet up to now but done little else with > it. The FreeBSD machines I look after on our internet-facing network > all have one account which I connect to for administration. I've set > up /etc/hosts.allow on all the machines to only allow ssh from a > limited internal network range. > > Now I want to create a new account on one machine which will be > accessible from the Internet as a whole, to be used for tunnelling of > SMTP and POP3. I can't predict what the client IP address will be so I > will have to remove the hosts.allow restriction.have you considered the "AllowGroups" and "AllowUsers" directives of sshd_config? They should provide exact the functionality that you want. -volker
Jim Hatfield wrote:> Now I want to create a new account on one machine which will be > accessible from the Internet as a whole, to be used for tunnelling of > SMTP and POP3. I can't predict what the client IP address will be so I > will have to remove the hosts.allow restriction. Is there any way I > can:have you tried using /etc/login.access? # Login access control table. # # When someone logs in, the table is scanned for the first entry that # matches the (user, host) combination, or, in case of non-networked # logins, the first entry that matches the (user, tty) combination. The # permissions field of that table entry determines whether the login will # be accepted or refused.
On Thu, 7 Oct 2004 21:14:07 +0100 , in local.freebsd.security you wrote:>Jim Hatfield wrote: >> Now I want to create a new account on one machine which will be >> accessible from the Internet as a whole, to be used for tunnelling of >> SMTP and POP3. I can't predict what the client IP address will be so I >> will have to remove the hosts.allow restriction. Is there any way I >> can: > >have you tried using /etc/login.access?I didn't know about this - thanks. In fact thanks to everyone for the many helpful replies, I have lots of solutions to choose from now! Jim
On Thu, 7 Oct 2004 21:14:07 +0100 , in local.freebsd.security you wrote:> >have you tried using /etc/login.access?Hmm, looks like sshd does not consult this file! I'm connecting as user "mis" and the client machine is 172.16.64.16 so I put this at the bottom: +:mis:172.16.64.16 and it let me in from a different machine. I tried adding this below: -:ALL:ALL but it made no difference. I did HUP sshd. jim
> Is there a way to enforce sshd login restrictions without using login(1)? > (i.e. I want to enforce a specific umask for all ssh logins).AFAIK this should be achievable using the PAM session facility. But I found no `pam_umask' module. BTW it should be pretty easy to implement by derivating an existing session module such as `pam_chroot'. -- Jeremie Le Hen jeremie@le-hen.org
Reasonably Related Threads
- ((AllowUsers || AllowGroups) && !(AllowUsers && AllowGroups))
- AllowUsers Change
- [Bug 1690] New: AllowUsers and DenyGroups directives are not parsed in the order specified
- Question about AllowUsers and AllowGroups
- AllowUsers "logic" and failure to indicate bad configuration