
/bin/false is not security (2005) - jessaustin
http://www.semicomplete.com/articles/ssh-security/
======
bch
I recall reading of one Unix implementation that when executing /bin/false
noticed that the spawned shell (/bin/false) had failed (because that’s what
/bin/false does, by design) and helpfully launched /bin/sh so you could debug
it. True or false (pun intended), this is why I use /bin/true to stand in as a
shell in this capacity.

------
isostatic
Modern ssh implementations won't let a user with a shell that isn't in
/etc/shells access via ssh.

Clearly you'll only be accepting public key authentication too.

~~~
pecg
Disable root authentication over ssh should be the default too. This is
literally ssh 101.

~~~
jstimpfle
what's wrong with public key auth as root? The "alternative" would be making a
sudo-enabled login account. Another indirection, and probably not fully
transparent...

~~~
isostatic
If you have more than one person logging in, it's far easier to identify who
did something as root by looking at the username that logged in.

Also far better to encourage running sudo for every command, gives a nice
simple audit log of what happened, right there in your syslog, so you can
identify and undo mistakes, and also eliminate lines of enquiry.

Clearly you can cover your tracks with the old sudo vi / !bash and similar
tricks, but the goal isn't to protect against hostile privileges users, its to
know what happened so that when John is on holiday you can see what he did to
fix the problem you had last week.

~~~
cuckcuckspruce
If your sudoers policy allows you to run vi then you've already failed.

sudoedit(8) has been around for a long time and it solves this problem.

~~~
isostatic
Failed at what? I want my sysadmins to have full access, I just want to know
what they did. I'm not trying to defend against malicious staff members - I
trust them, otherwise they wouldn't have sudo access.

~~~
cuckcuckspruce
If you can trust your administrators then you don't need to worry about shell
escapes in editors.

The idea for sudoedit is that it allows you to allow non-root users to safely
edit files, and if they shell out of their editor then they've not gained root
rights - they edit a temporary file as a regular user and then sudo moves the
file into place after it is edited.

------
STRML
FWIW, I tried that DoS idea on a little digitalocean machine. It capped the
number of open file descriptors for the SSH daemon at 1024. Only about 3000
file descriptors were in use after it stopped allocating channels, and file-
heavy operations like apt-get still succeeded.

~~~
bvinc
You'll probably hit the ulimit maximum file descriptors for the process. This
might cause problems for the sshd process, or it might not since it might just
hit the maximum for a process that's dedicated to your ssh connection.

It would take a lot more processes to hit the maximum for the entire system

------
0xmohit
SSH best priactices [0] says:

    
    
      - Use public key authentication
      - Encrypt your private keys
      - Check the Host keys
      - Use SSH Agent
      - Use a different key for every computer
      - Disable password authentication
      - Do not SSH cross-server
      - Use safe algorithms
      - Use agent forwarding at appropriate times
      - Use SSH certificates
      - Use a smartcard
      - Remove all system passwords
      - Use Two-factor Authentication
    

[0]
[https://blog.0xbadc0de.be/archives/300](https://blog.0xbadc0de.be/archives/300)

~~~
dfc
Your list is almost entirely client hygiene and does not seem to have any
connection to the priblems with port forwarding outlined linked article. Am I
missing something?

~~~
DiabloD3
IMO, that list puts the entire issue usefully in context.

------
aexaey
fail2ban [1] would take care of this by automatically firewalling off IPs that
fail to authenticate too frequently.

[1] [https://www.fail2ban.org/](https://www.fail2ban.org/)

~~~
lvh
Would it? My understanding is the authentication worked just fine, it’s just
spawning a shell that doesn’t. That could be intentional: eg for SFTP hosts or
jump hosts.

------
pecg
Simple and straightforward article that exposes one of many usual misbehaviors
of so called sysadmins these days: they think they know their tools, but
haven't even completely read the manual for the programs they rely on
production environments. Systems administration is something to be taken
seriously; recently a friend of mine, that knows nothing about network
perimeter security and didn't enforced adequate credentials on production
environments, got a RANSOMWARE on a machine with a critical for business
instance of a CRM database, chiefs on the organization refused to pay for the
bitcoins asked, and probably my friend will be fired for incompetence; the
infrastructure department personnel doesn't even have backups of such server,
it's clear the information is lost forever.

~~~
eesmith
"These days"? What you describe has happened for decades, though of course
with different details.

You never knew about sys admins who put "." in the PATH for root? That was one
of the warnings that I remember learning back in the early 1990s.

Remember the good old days when someone's .finger could be used for an escape
sequence injection? Even if you read the manual for your terminal, that
doesn't mean you change all your habits.

Or sys admins using "xhost +" for easy access to other machines in the local
network?

And sys admins forgetting to do backups? That's certainly nothing new.

~~~
icedchai
Early SGI systems, maybe as late as IRIX 5.x, actually shipped with "xhost +"
as the default! I remember people putting these on the internet with no
firewall (of course... this was the mid 90's) not realizing they could be key
logged remotely...

~~~
eesmith
I had a IRIX 5.x box and I remember having to do "xhost +". Which I did,
because ... easy.

