For AIX OpenSSH, the configurations files are located in the /etc/ssh file and the SSH (sshd) daemon is in the /usr/sbin/sshd file. For other OpenSSH types, typically the configuration files are located in /usr/local/etc and the SSH (sshd) daemon is located in /usr/local/sbin/sshd. Hello, Can someone tell me, How i can enable PermitRootLogin in /etc/ssh/sshd_config in AIX currently the server cannot be 'su - root' to as well. Grid Infrastructure Installation and Upgrade Guide for IBM AIX on POWER Systems (64-Bit) Table of Contents. Open the OpenSSH configuration file /etc/ssh/sshd_config.
SSH (OpenSSH) provides a secure encrypted connection to remote hosts. If a user has a valid AIX® account, they then can connect via SSH. However, as with any system regarding security awareness, there maybe a requirement to restrict certain users or hosts from connecting to a designated system via SSH. SSH provides two mechanisms to restrict user access: Deny and Allow attributes. These keywords are based on user and group lists. TCP Wrappers can also be used to block SSH connections from known or unknown hosts. I suggest using TCP Wrappers to block hosts either by host name/domain or IP and use thesshd_configfor user/group based access control.
- For AIX OpenSSH, the configurations files are located in the /etc/ssh file and the SSH (sshd) daemon is in the /usr/sbin/sshd file. For other OpenSSH types, typically the configuration files are located in /usr/local/etc and the SSH (sshd) daemon is located in /usr/local/sbin/sshd.
- OpenSSH Config File Examples last updated May 15, 2018 in Categories BASH Shell, CentOS, Debian / Ubuntu, FreeBSD, Linux, OpenBSD, RedHat and Friends, Suse, UNIX H ow do I create and setup an OpenSSH config file to create shortcuts for servers I frequently access under Linux or Unix desktop operating systems?
The configuration files and SSH daemon can be found in two places depending on what variant of SSH you have installed. ForAIX OpenSSH, the configurations files are located in the/etc/sshfile and the SSH (sshd) daemon is in the/usr/sbin/sshdfile.
For other OpenSSH types, typically the configuration files are located in/usr/local/etcand the SSH (sshd) daemon is located in/usr/local/sbin/sshd.
TCP Wrappers is used to block or allow TCP-based applications that are started frominetd, like thetelnetorFTPservices. As a rule, SSH is not started frominetd. If you wish to control SSH access via TCP Wrappers, you will need to copy thelibwrap.ainto a directory where yourLIBPATHpoints to (for third party applications, this could be:/usr/local/lib). The TCP Wrappers daemon istcpd.
Looking through the/var/adm/messagesfile, there could be occasions where you find SSH attempts to your system. These maybe totally innocent attempts at connecting from a local machine within your network or a brute force attempt from an unknown host. These entries should be further investigated. If one concludes that these are unlawful attempts at access, then these should be blocked. Although one can block hosts using thesshd_configfile, I suggest using TCP Wrappers to block hosts, since this is your primary wall of defense for incoming based TCP connections.
TCP Wrappers (tcpd) reads two files to determine if the incoming tcp based connection should be allowed or disallowed. The two files are:
Changes to these files are dynamic. Rules to pattern matching in both these files will control what gets denied or allowed. These rules can be complicated or simple. Thehosts.allowis searched first. If a pattern match is found, the connection is let in, or more precisely,tcpddies and lets the real serving daemon take over. Thehosts.denyis then searched for a pattern match. If a match is found, thentcpdwill deny access for that connection. Simply put, this meanshosts.allowrules are applied first, followed byhosts.denyrules. The overall rule is to first allow hosts you trust then deny everything else.
Now, let's go over some examples of how TCP Wrappers can control access via SSH to a host. Imagine we belong to the domain drwho.com, and we only want to allow users belonging to this domain to SSH in. We could use the following to achieve this:
To further refine the previous example, we could still allow all the drwho.com domain connections in and also allow the following IP address ranges:172.24.11, 172.24.12.(the dot at the end of the IP addresses means to match anything after the dot). Notice in the following example each pattern is separated by a comma.
Generally, you would want to allow all of the domain in, except certain hosts. This would be the case if it was a production system, and you did not want connection coming from a development system. The following will allow all in the previous example just presented apart from the following hosts:dev01anddev02.
One can also use theusername@hostnameformat in thehosts.alloworhosts.denyfile. For example:
You may have to supply the FQDN (fully qualified domain name). To test this, look at how TCP Wrappers resolves the hostname in the messages file, then amend thehosts.allowfile accordingly.
For theusername@hostformat, I prefer to use thesshd_configfile to control access. This is because it allows me to use TCP Wrappers to authenticate hosts only for TCP-based services liketelnet,FTPand thessh_configfile to authenticate users/groups for SSH only. It makes for easier management of host and user control access from a system administrators point of view.
To log connections viasyslogto/var/adm/messagesin/etc/syslogd.conf, make sure you have one of the following entries:
Or
Be sure to restartsyslogdfor the changes to take effect:
A typical entry in the messages file for a successful connection (in this case, user dxtans from the host tardis which belongs to the domain drwho.com) could be:
A blocked attempt by a user from the host dev01, via the rules applied in thehosts.allowfile, could be:
Located in thesshd_config, there are four entries:
If these keywords are not present, simply create them as required. Be sure you only create the keyword you require to avoid unreliable results from occurring. Each of the Allow or DenyUsers lists are space separated by valid usernames, because the Allow or DenyGroups valid groups can only be present. The pattern match is in the following order:DenyUsers,AllowUsers,DenyGroups,AllowGroups.
Any changes made to the filesshd_configwill not take effect untilsshdis restarted, like so:
If you populate the AllowUsers list with user ids, then only those users can SSH in. The same principal applies to the DenyUsers list, only those users contained in the deny list are denied access. This same rules applies to the group lists. This can become very confusing when you mix some of these rules up, so don't. Just have one list, either an allow list or deny list depending on what your security requirements are.
Users that have an account on that system, but do not have their user ID present in the AllowUsers list, will be denied entry. The same rule applies for the DenyUsers list. Let's now look at that with an example, suppose our AllowUsers list contained the following:
If user alpha tries to SSH in then that user will be denied access, as the user name is not present in the AllowUsers list.
Looking at the/var/adm/messagesfile confirms this, informing the administrators that user alpha is not listed in the AllowUsers list.
Now looking at the DenyUsers list, suppose our list contained the following:
Now all users whom have an account on the system who are not listed in the deny user list can SSH in.
If user alpha tries to SSH in, then that user will be allowed access as his user name is not contained in the DenyUsers list. This can be verified by viewing the messages file:
However, if user bravo who is on the DenyUsers list tries to SSH in, he will be denied access:
Again, the reason for denial can be verified by viewing the messages file:
To stop pattern matching producing unpredictable results, I strongly suggest you do not have a group and user list entries, but rather, have either a user list entry (allow or deny) or group list entry (allow or deny), but not both.
Looking at how it could be confusing, suppose we have the following:
Because of pattern matching order, we can now state that no users contained in the DenyUsers list will be granted access, only the user alpha will be granted access. In that case, I suggest just having the AllowUsers list only. If the user ID is not listed in the allow list, then you are not connecting, no matter what is contained in the deny list.
The same principle applies to the groups. Suppose we had the following entry:
The members of the group water are:
Now, if the user dxtans (a member of groups staff and admin)
tries to connect, the user dxtans will fail with the following entry in/var/adm/messages
Sshd Config File
because dxtans is not in the allow list nor in the deny list.
It maybe advantageous to create a group that contains users that you do not want to allow to SSH in, as this will require least maintenance, and then create a group of users that are allowed to SSH in. For example, suppose we had a group called nossh, containing users not allowed to SSH in:
In thesshd_configfile, we had the following entry:
Now any user belonging to the group nossh would be denied access, as can be viewed in the messages file when user golf, whom belongs to the group nossh, tries to SSH in:
Using the group list, rather than the user list, can seem more favorable when you have a large number of users on the system.
When dealing with direct root SSH access from remote hosts, I suggest it is best to limit which hosts can SSH in as user root. This approach allows administrators to keep control of where user root can SSH to, thus keeping control on root remote connections.
To control access by user and host via the sshd_conf file, you can use the following formats:root@<hostname>orroot@<hostname.domain>.
You will need to see what format SSH reports in the/var/adm/messagesfile, whether the host is resolved as a short or long hostname. Once this has been identified, simply insert the corresponding entry into the AllowUsers list. If you are not sure whether it is a short or long name, as this can be dependent on different operating systems from the originating SSH connection, it is best to include both the short and long name.
For example, to allow only root access from the host tardis (which belongs to the drwho domain) we could have the following:
Of course, in the real world, the above list would also be populated with other users.
The above method would be ideally used where you have a deployment server, and only root from that deployment server (in the above example) can SSH and SCP from one determined host to all clients.
Being able to generate automatically a user list, be it for allow or deny lists, does have its benefits. Users get added and deleted over a period of time, so it can be easy to become complacent and forgot to update the list. What list should you generate? I would suggest populating only the allow list. It can be easier to determine if that user is not in the AllowUsers list. If not, then access will be denied. What rules do you apply to allow a user into the AllowUsers list? Consider that if the user's attributes state that the user can remoterlogin/telnet(rlogin=true), then why not be allowed to SSH in, as well? Using this rule immediately cuts out all the system and application owner accounts and should leave just normal users.
On a typical system, all system accounts and applications owners should, as a rule, be non-login able. Thus, the only access to those accounts is via su or sudo.
One could then perhaps manually edit the list only for adhoc events, like to further allow (or deny) temporary access during application roll-outs.Listing 1below demonstrates one way this can be achieved. For example, first the location of thesshd_configfile is determined, so we know which SSH version to update. Next, a list of all users on the host is gathered where therloginattribute is true, excluding root. The file /tmp/ssh_ignore is then read and any matches found in the generated list of users is then deleted from the list. The use of the file ssh_ignore allows administrators to make adhoc changes on users whom are not to appear in the allowed user list in thesshd_configfile.
The format of the file is:
The AllowUsers list in thesshd_configfile is then extracted and compared with the newly generated user list. If there are changes, thesshd_configfile is updated. Notice the short and long name of the root@tardis is included. As discussed previously, this means only root from the host tardis can SSH in; this provides control as only root from the hosts tardis can SSH in. If there are any changes in thesshd_config, then the SSH service is restarted, and an email is sent out to administrators informing them of the change tosshd_configAllowUsers list.
The script assumes that there is already an entry for the AllowUsers list, and that the list contains at least an entry for the deployment server, like so:
That is, the name of the host, that user root can only connect from. In this example, it contains both the short and long host name (the host's name is tardis). Please amend the script to suit your needs, replace the host tardis with your own host. The script could be run from your favorite scheduler once a day to keep the user list up to date.
Listing 1. pop_user_allow_ssh
To enable debugging, where the messages file just does not display enough information. From the client side, use the verbose (v) where more v's means more verbose option when connecting via SSH:
From the server side, stop thesshdservice and start it up with the debug option. The debug (d) means more verbose. When a connection is made,sshdwill then terminate. You will then need to either restart it in debug mode again (if you require further testing) or normally via thestartsrccommand. To start in debug mode use:
If you do find issues when trying to connect via SSH, and the issue is not immediately obvious, then I recommend using both the client and server debug methods together to diagnose issues.
Typical output of startingsshdin debug mode could be:
Ifsshdis started in debug mode, any errors found insshd_confbysshdwill be reported to standard ouput. Ifsshdis started by thestartsrccommand any errors found in thesshd_conffile will be displayed in the/var/adm/messagesfile. You can also use the following method by checking the last exist status (you can determine if you have issues with the configuration):
Using the debug method, however, should be first when diagnosing SSH related issues.
Using SSH allows for secure encrypted connections to remote hosts. However, as with any incoming connection, these need to be policed. The use of TCP Wrappers and the Allow/Deny lists insshd_configcan put you on a proactive stance regarding security.
David Tansley is a freelance writer. He has 15 years of experience as a UNIX administrator, using AIX the last eight years. He enjoys playing badminton, then relaxing watching Formula 1, but nothing beats riding and touring on his GSA motorbike with his wife.
I have Ubuntu 9.10 installed with sshd and I can successfully connect to it using login and password. I have configured an RSA key login and now have 'Server refused our key' as expected. Ok, now I want to check sshd log in order to figure out a problem. I have examined /etc/ssh/sshd_config and it have
Ok. I'm looking at /var/log/auth.log and... it's empty O_O. Changing Loglevel to VERBOSE helps nothing - auth.log is still empty. Any hints how I can check sshd log?
5 Answers
If no one else is using the system at the moment you could do what i've done in such cases:
- stop sshd service (at least i've been able to do this while logged in via ssh)
- start sshd manually and add some -d options to get more verbose debug output. Unless you have something funky going on it should use the same keys and config it does when started properly
Creating an answer based on the comments above, credit to @Prof. Moriarty and @Eye of Hell
SSH auth failures are logged here /var/log/auth.log
The following should give you only ssh related log lines
grep 'sshd' /var/log/auth.log
To be on the safe side, get the last few hundred lines and then search (because if the log file is too large, grep on the whole file would consume more system resources, not to mention will take longer to run)
tail -500 /var/log/auth.log | grep 'sshd'
Sshd Config Example
If you can try the failing connection again easily, one way easy way is to run:
and then retry the connection with:
Sshd_config File In Aix
Using -p 2222 so that we don't have to stop the main SSH server, which could lock you out.
See also: https://unix.stackexchange.com/a/55481/32558
If you want to see all log messages about sshd, run this: