Ssh – how to use different SSH banner for various SSH connections

Here's an example. Details about how Match works is in sshd_config man page.

excerpt

Match   Introduces a conditional block.  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.

        The arguments to Match are one or more criteria-pattern pairs.  The 
        available criteria are User, Group, Host, and Address.  The match 
        patterns may consist of single entries or comma-separated lists and may 
        use the wildcard and negation operators described in the PATTERNS 
        section of ssh_config(5).

Details on the patterns that are permissible are in ssh_config man page under "PATTERNS".

excerpt

PATTERNS
        A pattern consists of zero or more non-whitespace characters, ‘*’ 
        (a wildcard that matches zero or more characters), or ‘?’ (a wildcard 
        that matches exactly one character).  For example, to specify a set of 
        declarations for any host in the “.co.uk” set of domains, the following 
        pattern could be used:

           Host *.co.uk

       The following pattern would match any host in the 192.168.0.[0-9] network 
       range:

           Host 192.168.0.?

       A pattern-list is a comma-separated list of patterns.  Patterns within 
       pattern-lists may be negated by preceding them with an exclamation mark 
       (‘!’).  For example, to allow a key to be used from anywhere within an 
       organisation except from the “dialup” pool, the following entry (in 
       authorized_keys) could be used:

          from="!*.dialup.example.com,*.example.com"

Example

Match User user1,user2
  Banner "none"

I don't think it is possible to do what you are asking. If you could, someone could "brute force" to find valid usernames on your server. I am also pretty sure that the username and the password are sent simultaneously by the client, you could verify this by capturing packets using Wireshark on an unencrypted SSH connection.

By "hacking activities" I assume you are talking about brute force attempts at passwords. There are many ways to protect yourself from this, I will explain the most common ways.

Disable root login By denying root login with SSH the attacker has to know or guess a valid username. Most automated brute force attacks only try logging in as root.

Blocking IPs on authentication failure Daemons like fail2ban and sshguard monitor your log files to detect login failures. You can configure these to block the IP address trying to log in after a number of failed login attempts. In your case this is what I would recommend. This reduces log spam and strain on your server, as all packets from this IP would be blocked before they reach the sshd daemon. Your could, for example, set fail2ban to block IPs with 3 login failures in the last 5 minutes for 60 minutes. You will in the worst cases see three failed logins in your log every 60 minutes, assuming the attacker does not give up and move on.

Public key authentication You can disable password authentication entirely and only allow clients with specific keys. This is often considered to be the most secure solution (assuming the client keeps his key safe and encrypted). To disable password authentication, add your public key to ~/.ssh/authorized_keys on the server and set PasswordAuthentication to no in sshd_config. There are numerous tutorials and tools to assist with this.