Hello,
I've read on several howtos that one way to make ssh more secure, or at least reduce the damage if somebody breaks in, is to NOT allow direct ssh login from root, but allow logins from another user. So you have to know two passwords in order to do any real damage.
Does this make sense? IF yes, what is the right way to create an user only for this purpose, that is one that can only login to give me a local prompt to become root, but has no privilege, no possibility to create files, or do anything at all?
TIA, Marco
On Wed, 2006-06-14 at 18:56 +0200, M. Fioretti wrote:
I've read on several howtos that one way to make ssh more secure, or at least reduce the damage if somebody breaks in, is to NOT allow direct ssh login from root, but allow logins from another user. So you have to know two passwords in order to do any real damage.
Does this make sense? IF yes, what is the right way to create an user only for this purpose, that is one that can only login to give me a local prompt to become root, but has no privilege, no possibility to create files, or do anything at all?
Normally you would want people to use their own account for the initial login - and to use good passwords so a dictionary attack isn't likely to work.
On Wed, Jun 14, 2006 12:38:51 PM -0500, Les Mikesell (lesmikesell@gmail.com) wrote:
On Wed, 2006-06-14 at 18:56 +0200, M. Fioretti wrote:
I've read on several howtos that one way to make ssh more secure, or at least reduce the damage if somebody breaks in, is to NOT allow direct ssh login from root, but allow logins from another user. So you have to know two passwords in order to do any real damage.
[...]
Normally you would want people to use their own account for the initial login - and to use good passwords so a dictionary attack isn't likely to work.
I agree, but normal users have no reason to exist on that particular box. It is a web and email server, nothing more. Even email is handled via virtual users.
If I create another Unix account (my_aux_login), it will only be so I can disable ssh directly as root and then ssh into the box with that login, to immediately su to root for system administration. So my original question means:
(must I)/can I reduce as much as possible the privileges/access rights of the my_aux_login account? so that if somebody breaks _its_ password, it won't be able to do anything, including browsing around to see what's installed?
If yes, how?
Marco
On Wed, 2006-06-14 at 20:22 +0200, M. Fioretti wrote:
On Wed, Jun 14, 2006 12:38:51 PM -0500, Les Mikesell (lesmikesell@gmail.com) wrote:
On Wed, 2006-06-14 at 18:56 +0200, M. Fioretti wrote:
I've read on several howtos that one way to make ssh more secure, or at least reduce the damage if somebody breaks in, is to NOT allow direct ssh login from root, but allow logins from another user. So you have to know two passwords in order to do any real damage.
I'm new to all this, so I hope it's useful. This WFM (Works For Me) in my little LAN.
Better is no passwords? I ssh around my little niche using only the files '*known_hosts' in ~/.ssh and /etc/ssh and the public keys. If you have a restricted set of nodes from which you access the server, this seems an ideal solution for the "authorized access" part of your task. On my IPCop gateway, I don't allow password-based authentication and login.
[...]
Normally you would want people to use their own account for the initial login - <snip>
If passwordless login works for you, then maybe a restricted shell or chroot, once you are in, to further restrict? IIRC from recent readings of many docs *trying* to learn some of this stuff, that stuff doesn't have to be root either. So if they can be set as some other user and group, you don't have to worry about what root can do.
HTH
On Wed, 2006-06-14 at 15:00 -0400, William L. Maltby wrote:
On Wed, 2006-06-14 at 20:22 +0200, M. Fioretti wrote:
On Wed, Jun 14, 2006 12:38:51 PM -0500, Les Mikesell (lesmikesell@gmail.com) wrote:
On Wed, 2006-06-14 at 18:56 +0200, M. Fioretti wrote:
I've read on several howtos that one way to make ssh more secure,
<snip>
P.S. Also, if you change the SSH port from 22 to 459 (but better pick one outside the reserved range I think) on the target machine so that something like
ssh -p 459 ...
is needed to connect, then all the nodes trying to penetrate are stymied.
From rom "man ssh", /etc/ssh/sshrc might be useful for part of what you want and "man sshd" might have something in the "command=" and "from="pattern-list" sections that is useful.
<snip sig stuff>
On Wed, 2006-06-14 at 13:22, M. Fioretti wrote:
I've read on several howtos that one way to make ssh more secure, or at least reduce the damage if somebody breaks in, is to NOT allow direct ssh login from root, but allow logins from another user. So you have to know two passwords in order to do any real damage.
[...]
Normally you would want people to use their own account for the initial login - and to use good passwords so a dictionary attack isn't likely to work.
I agree, but normal users have no reason to exist on that particular box. It is a web and email server, nothing more. Even email is handled via virtual users.
If I create another Unix account (my_aux_login), it will only be so I can disable ssh directly as root and then ssh into the box with that login, to immediately su to root for system administration. So my original question means:
(must I)/can I reduce as much as possible the privileges/access rights of the my_aux_login account? so that if somebody breaks _its_ password, it won't be able to do anything, including browsing around to see what's installed?
You probably can't without breaking something because certain areas like /tmp are writable by everyone and you must have read access to the ssh binary and its libraries to execute them. However, Linux is designed to be multiuser and non root users should not be able to damage anything but their own files. You might make sure that any critical data is under directories that don't have rx permissions for 'other' and assign a disk quota to this user. As others have already suggested, you might also turn off passwords so you need the ssh key to connect.
-
Les Mikesell -
M. Fioretti -
William L. Maltby