How can I disable the SSH login banner for a given user?

S

scryptkiddy

Hey all,

I have a non-human user account that logs into remote systems via RSA key, and executes scripts on a cron, and I capture the output of these cron jobs in files, here is an example:

Code: 
*/10 * * * * /usr/local/etc/data_checker.php >> /data/log/data_checker_daemon.log 2>&1

Parsing the logs from these crons I notice that the logs contained the output from the remote server's /etc/motd that these PHP files log into. Since the jobs run so frequently, the logs fill up 10-20x faster and are harder to parse due to the banner being included (since the banner is returned before an authentication occurs), and are becoming a disk utilization problem.

As one try, I put a ~/.hushlogin on the remote server, into this non-human user's home directory. This did remove the /etc/motd output from returning when I ssh into the remote server as the non-human user (or when the cron jobs ran). However, I still see the output of the banner /etc/ssh/sshd_config for the user both on the CLI and from the cron jobs. This is the banner line entry on the remote server that I'm logging into:

Code: 
banner /etc/mybanner

So how do I get the ~/.hushlogin to hush the banner as well? The only other thing I thought might work is putting a ~/.login.conf on the remote server that contains the environment variable
Code: 
hushlogin=false
. But I'm not sure of the syntax or what a complete login.conf(5) should look like.

Is the ~./login.conf a viable option, or is there a better way to do this?

SK
 
ondra_knezour said:
See the info about Match and Banner in sshd_config(). Something like
Code: 
Match User nonhumanuser
  Banner "none"
at the end of the config file should work.
Click to expand...
I didn't think that would work, but it does. That strikes me as a security risk because it could allow potential intruders to figure out that nonhumanuser is a valid username.

Kevin Barry
 
Monoecus said:
If intruders can read your sshd_config file, I guess you are screwed anyway.
Click to expand...
Good one. I meant that if an intruder attempts to log in and there's a banner every time, and one time he/she attempts to log in with a particular username and there's no banner (or a different banner,) that's an indication that the username is special and is probably valid on the system. (If you disable password login for the user that's not as big of a problem, but, of course, this thread provides information to all members with interest in the original question.) Most of the ssh attacks I get don't target a particular username; they target hundreds of usernames. If the attacker knew a valid username (other than the obvious root,) he/she would try to brute-force that username rather than a dictionary of common usernames.

At some point there was concern that the very slight delay caused by attempted authentication of an actual username (vs. a shorter delay for an invalid username) was too much of an indication that the username was valid. Changing the banner for a user pretty much broadcasts it, though.

Kevin Barry
 
ta0kira said:
Good one. I meant that if an intruder attempts to log in and there's a banner every time, and one time he/she attempts to log in with a particular username and there's no banner (or a different banner,) that's an indication that the username is special and is probably valid on the system.
Click to expand...
Although that could be true there is one small flaw in your reasoning; you're deducting from what you already knew.

An attacker doesn't know anything about this of course. I wouldn't be surprised at all if he drew a different conclusion: "This account is the only one without a banner; so most likely used for automated logins; like my hack script does. Man, can they make their honeypots any more obvious to detect that that? Suckers!".

I don't see a potential risk here because it heavily depends on what conclusions an attacker would draw, and that's something you can't predict. In my opinion it can swing either way.
 
ShelLuser said:
Although that could be true there is one small flaw in your reasoning; you're deducting from what you already knew.

An attacker doesn't know anything about this of course. I wouldn't be surprised at all if he drew a different conclusion: "This account is the only one without a banner; so most likely used for automated logins; like my hack script does. Man, can they make their honeypots any more obvious to detect that that? Suckers!".

I don't see a potential risk here because it heavily depends on what conclusions an attacker would draw, and that's something you can't predict. In my opinion it can swing either way.
Click to expand...

I find your point to be valid, and a good one at that. However, it's generally suggested to take the more pessimistic approach when dealing with security. Always hope for the best, but expect the worst. In this case, that would be to hope the attacker will think it's a honey pot, but expect they'll think it's a valid account.
 
ShelLuser said:
Although that could be true there is one small flaw in your reasoning; you're deducting from what you already knew.
Click to expand...
When I get brute-force attacks, nearly all of the attempts are for invalid non-root usernames, but once in a while they hit a valid username. If when that happened there was something discernibly different about the interaction, that would at least be an indication that the username just attempted was a more promising direction of attack than the other 1000 usernames previously attempted.
ShelLuser said:
An attacker doesn't know anything about this of course. I wouldn't be surprised at all if he drew a different conclusion: "This account is the only one without a banner; so most likely used for automated logins; like my hack script does. Man, can they make their honeypots any more obvious to detect that that? Suckers!".
Click to expand...
My conclusion would be the opposite: that the sysadmin was tired of seeing the banner when logging in, so disabled it for his/her own account. Also, bots don't really consider higher-order things like, "are they trying to trick me?"

In the absence of all other leads, why discard one because you think it might be a trick? Nothing is lost if the attacker temporarily redirects all efforts to the one username that provided different feedback. In fact, it might cause the attacker to redirect resources from other attacks to your machine. Looking at it probabilistically, it's not unreasonable for a bot designer to think that a valid username is a more-likely entry point than a dictionary of usernames of unknown status, regardless of how it's deduced that the username is valid.

Kevin Barry
 
Regardless of what they might think, having one account react differently than all the others gives the attacker information they did not have before. Something is different about that account.
 
If you are scared about the attacker, then you can switch from Banner to Motd. You can edit the /etc/ssh/sshd_config, so that the entries are:
Code: 
PrintMotd yes
#Banner /etc/issue.net

Match User nohumanuser
 PrintMotd no

Alternativly you could stop displaying stuff by the sshd daemon and start using the users' profile (or systems profile). Then you could achieve such dynamic information when an user logs in like host info and stuff running on the server.

Regards
Markus
 
Thanks for all the thoughts. I have been playing around with this alot last few days.

Few thoughts.

1. @ondra_knezour - All lines after the "Match User nonhumanuser" in the /etc/ssh/sshd_config fail to start up SSH. I'm assuming I needed to terminate the Match (end Match?). Moving the Match line to the bottom of the /etc/ssh/sshd_config file is my current work around.

2. @wblock@ - Disabling the banner for all users is not an option. Our company requires a banner for "all human user accounts".

3. @ShelLuser/@ta0kira/@Savagedlight - As far as the non human account, it is password disabled. The cron jobs specify its private key within the scripts for SSH to other BSD servers.

4. @storvi_net I tried the PrintMotd no option with Match, SSH will not start up, saying that option is not allowed with Match block.

Lots of thanks to all that responded, but unless I'm doing the Match blocks wrong (pretty straight forward though), I cannot get a working solution.

Last attempt with errors #4 above (sshd_config snippet):

Code: 
Protocol 2
LogLevel VERBOSE
UseDNS no
MaxAuthTries 3
Subsystem     sftp     /usr/libexec/sftp-server

PrintMotd yes
Match User non_human_user
     PrintMotd no

#Banner none

My goal is still to:

1. Display banner for all human users
2. Hide motd and banner from all non human users

Just can't get the right combination yet. I tried combining this solution with the ~/.hushlogin, but to no avail. Any ideas on my syntax or something else I'm missing?

SK
 
Last edited by a moderator:
ShelLuser said:
I don't see a potential risk here because it heavily depends on what conclusions an attacker would draw, and that's something you can't predict. In my opinion it can swing either way.
Click to expand...

I second that.

How often do you give a SSH user login that is not /fairly/ guessable ? Login is not a secret, password is.

Give nohumanuser as least permissions as possible and chroot it in a dedicated directory. If you consider banner to be important, you can maybe adjust a script to trim it off from logs upon each login.

Check sshd_config(5) for details; you can't mix global section and Match paragraphs.
 
ta0kira said:
That's not a work-around. That's how it's supposed to be.

Kevin Barry
Click to expand...

Good point, I found that in the manpage after posting:
...If all of the criteria on the Match line are satisfied, the keywords on the following lines override those set in the global section of the config file, until either another Match line or the end of the file.
Click to expand...
But unfortunately my workaround is not working. I still get an all or nothing kind of solution.

@matoatlantis
...you can maybe adjust a script to trim it off from logs upon each login.
Click to expand...
Originally I thought of that. But then I thought why am I writing / scripting something that I can probably just set in a configuration file? In regards to the client side ssh_config(5) did not have a key word for Banner or PrintMotd, it appears those are only for server side sshd_config

Let me know if I missed something, still no dice.

SK
 
Last edited by a moderator:
Note that you just need to change the remote side of the sshd daemon, nothing on a client side. You did bounce sshd once you changed sshd_config, right ?

My config (remote side):

grep -vE '^$|^#' /etc/ssh/sshd_config
Code: 
Banner /etc/banner
Subsystem       sftp    /usr/libexec/sftp-server
Match User silentone
        Banner none

ll ~silentone/.hushlogin
Code: 
-r--------  1 silentone  silentone  0 Aug  5 22:10 /home/silentone/.hushlogin

Client:

$ ssh silentone@sandbox
Code: 
Password:
silentone@sandbox:/home/silentone %

All changes are done on remote side; .hushlogin is read by login(1).
 
Righteous

Okay, that worked!

@@matoatlantis - Yup, only server side and yes to bouncing sshd. In regards to the client side, I was alluding to possibly sending some environment settings from the client to control this perhaps, since I was having difficulty doing this from sshd_config on the server side. It works now because I recreated the .hushlogin file, I was not using that anymore after it failed and focused only on the sshd_config.

Many thanks for restating all that was required.

SK
 
Last edited by a moderator:
matoatlantis said:
I second that.

How often do you give a SSH user login that is not /fairly/ guessable ? Login is not a secret, password is.
Click to expand...
If passwords are the key to security, why don't you turn off your firewall? I agree that people don't generally have usernames like "asrecccdsf", but I disagree that most usernames are guessable unless you know the full names of the respective people. Apparently my usernames are fairly secret, since one particular attack a few weeks ago made 5229 attempts using 415 usernames (taking about 57 minutes), none of which were valid. The secret isn't just the password; it's the entire combination of password, username, host, and allowed location of access. It would be very naive to think that you could publish your hostname, usernames, and firewall settings without attracting a massive influx of attacks.

Kevin Barry
 
@@ta0kira I guess we can agree less the attacker knows the better.

But I still think (even in the scenario OP presented) there's too much focus on username to remain hidden. I'd rather focus on the user security itself (chroot, drop privileges, etc.) than thinking attacker can distinguish something is different just because banner is not shown.
 
Last edited by a moderator:
You must log in or register to reply here.
Back
Top