up vote 0 down vote favorite
share [g+] share [fb]

I'va remote linux debian server that 99.9% of the time I access via ssh remotely. However I was aware that the local terminal is sitting there with a logon prompt. Is there anything I could change this to, or log in and run locally and safely leave running? Physical access to the server is limited to me but a secure situation would be preferable.

Thanks.. Ian

link|improve this question
0% accept rate
@ rkthkr >> you don't know me and why should I accept an answer that I am not happy with – ianfuture Apr 22 '10 at 12:52
@ianfuture When you never accept answers, people start to wonder if you're overly hard to please. – ceejayoz Apr 22 '10 at 13:37
If you really have no answers worth accepting then you could update the questions with more detail. Add comments to any answers that don't solve your issue. Please remember serverfault is for server. You will proably get better answers about things like VPNs to your home network on superuser.com – Zoredache Apr 22 '10 at 16:12
@zoredache >I think that VPN question was migrated over from superuser. – ianfuture Apr 22 '10 at 17:58
@ceejayoz > not hard to please just hard to find time to actually try things out and then decide if something is worth accepting. – ianfuture Apr 22 '10 at 17:59
show 2 more comments
feedback

3 Answers

up vote 4 down vote

I'm not sure exactly, but my guesses if this helps you would be to look into /etc/inittab or the kernel boot parameters.

That being said, I would think leaving those terminals active makes the most sense. Security is often a balance against the ability to troubleshoot/fix something vs restricting access. In this case I would say troubleshooting is more important. Disabling the terminals just seems like security via obscurity. The terminal is password protected, and if someone has physical access they could always boot into single user mode or something like that (although I guess in this situation you might get an alert).

link|improve this answer
1  
Yea, you would comment the gettys in inittab and SIGHUP init. (pid 1) Agree entirely with Kyle, might not be worth the risk if you break SSH. – Warner Apr 22 '10 at 14:04
ok, is there anything I could run that if anyone tried to exit out of it would return to a logon prompt, therefore keeping security but also allowing me to run something? – ianfuture Apr 23 '10 at 12:00
Sure... /bin/login. In other words, what's your motivation here? Why do you even want to run something? Just for kicks? – MikeyB Apr 23 '10 at 14:15
feedback
up vote 2 down vote

The terminal should stay running. What if your ssh daemon crashes? Physical access to a system is an easy way to get around most security. As Kyle said, they can boot into single user mode and get access to the system. You can mitigate this by using a bootloader password in grub, but if someone has physical access to your systems then you have bigger problems.

To directly answer your other questions, it sounds like you just want some general hardening advice. Leaving unnecessary daemons/services running can introduce unnecessary risk. Look at all of your services, look up what they do or what they provide and think about whether you need or use that particular one. If you don't, disable it. You seem to want to focus on ssh access as well. Disable root logins via ssh, enforce lock outs so that someone can't brute force you, or if you have a limited amount of users accessing this system, you can allow only those specific users to log in via ssh.

link|improve this answer
feedback
up vote 1 down vote

Don't worry about the login prompts. They are the least of your worries. When securing the server make sure that someone can't alter the boot parameters and append "init=/bin/bash" to bypass authentication and get a root shell.

To prevent this you could disallow any access to the boot loader by preventing access to the boot loader menus. Not ideal.

Better is to add a password to the boot loader to prevent modifications to those settings: http://ubuntuforums.org/showthread.php?t=7353

And then you may also want to password protect the BIOS. Oh and while we're at it you should probably lock it up... not sure how far to take this as your description is lacking details.

link|improve this answer
feedback

Your Answer

 
or
required, but never shown
discard

Not the answer you're looking for? Browse other questions tagged or ask your own question.