In this article, I will mention some files and techniques you can use to find the reasons for problems with an SSH connection from an AIX partition or to an AIX partition. This is by no means a completed document and I'm always open to suggestions/additions/corrections; if I get any, I will update this post.

Simple things to check first

• Does the error message give any clues? If so, the reason for the error may be obvious.
• If you can't get a connection:
  • is the host up-and-running?
  • is name resolving working correctly?
  • is there a firewall between the two hosts and does it allow the ports needed (typically 22 for the default configuration)
  • are the permissions correct on the files that make up the SSH fileset(s)?
    • in /etc/ssh, the files ssh_config and sshd_config need to be 0644,
    • in /etc/ssh, the files ssh_host_*_key (for private keys) need to be 0600,
    • in /etc/ssh, the files ssh_host_*_key.pub (for public keys) need to be 0644,
    • most executables (like ssh, scp, sftp, ssh-keygen etc. in /usr/bin or /usr/sbin) need to be 0755,
    • in /usr/sbin, the executable ssh-keysign needs to be 4711.

Check logging settings

Both ssh and sshd can do extensive logging. By default they perform the type of logging identified in the configuration files that go with them. Or by the defaults built in to the programs if nothing is specified in the configuration files.De client-side ssh can produce debugging output that typically appears on-screen; the server-side ssh daemon (sshd)  typically forwards the debugging information to the syslogd daemon.

Configuration file /etc/ssh/ssh_config

See the following example of a fragment of the default sshd_config file

#SyslogFacility AUTH
#LogLevel INFO

Since the entries are commented-out (a # in front of the line) the defaults are used, built in to sshd.

• Messages from sshd are sent to the syslogd daemon using the AUTH (authentication) facility. Possibilities are DAEMON, USER, AUTH, LOCAL0, LOCAL1, LOCAL2, LOCAL3, LOCAL4, LOCAL5, LOCAL6 and LOCAL7. The default is AUTH.
• The level of logging is set to INFO (informational). Possibilities are QUIET, FATAL, ERROR, INFO, VERBOSE, DEBUG, DEBUG1, DEBUG2, and DEBUG3. The default is INFO. The default means that you get all informational messages, as well as messages that are higher in priority, like ERROR and FATAL. If you modify the LogLevel to FATAL, you only get FATAL messages. If you set LogLevel to the DEBUG2 level you also get DEBUG1, VERBOSE, INFO, ERROR and FATAL.
  
  

Configuration file /etc/syslog.conf (only for sshd)

The file /etc/syslog.conf determines where output from sshd is written. When the default SyslogFacility and LogLevel are used, the message(s) from sshd will be written to all files (or external systems) mentioned in a line starting with *.info, auth.* or auth.info.

See the following example:

aso.notice /var/log/aso/aso.log rotate size 1m files 8 compress
aso.info   /var/log/aso/aso_process.log rotate size 1m files 8 compress
aso.debug  /var/log/aso/aso_debug.log rotate size 32m files 8 compress
*.alert    errlog
*.debug    /var/log/messages size 1m files 8 compress
*.info     /var/adm/ras/syslog.caa rotate size 1m files 10
auth.info  /var/log/auth.log rotate size 1m files 8
user.debug /var/log/mqm_syslog.log rotate size 1m files 2
auth.debug;syslog.debug;kern.debug;local5.info  @10.11.254.20

This means that messages from sshd will be written to file /var/adm/ras/syslog.caa and to /var/log/auth.log.

The combination of SyslogFacility (only for sshd) and LogLevel determines how much debugging info is generated, and where it goes.

Debugging for the client side (ssh)

The client-side SSH programs (like ssh and scp) can provide debugging output by specifying the "-v" option (for verbose). If you include "v" more often, you get more debugging output, up to the maximum of "-vvv". Each added "v" will increase the verbosity of the output, giving you more information.
 

Modify /etc/ssh/ssh_config

If you always want more logging on all your outgoing sessions, you can use built-in debugging levels that ssh provides by modifying the file /etc/ssh/ssh_config. Changing the LogLevel to DEBUG1, DEBUG2 or DEBUG3 gives you the same effect as "-v", "-vv" and "-vvv" respectively. If you want to start ssh with less logging than the default, use (one or more) "-V" (capital letter v) characters to reduce the level. It is not recommended having any DEBUG* level by default, as it will reveal details about users and security that could be helpful to attackers.

Simple debugging for incoming ssh sessions (sshd)

Debugging sshd is more complicated, as it normally does not output to the screen.
 

Modify /etc/ssh/sshd_config

If you want higher levels of debug on incoming sessions, you can use built-in debugging levels that sshd provides by modifying the file /etc/ssh/sshd_config. Changing the LogLevel to VERBOSE, DEBUG1, DEBUG2 or DEBUG3 will give you more information. You might want to also change the SyslogFacility to something different, like LOCAL7, to prevent the normal logfiles from filling up (or rotating too quickly) because the increased levels of logging.

If you modify sshd_config, do not forget to restart sshd:
# stopsrc -s sshd
# startsrc -s sshd


Modify /etc/syslog.conf

If you changed the SyslogFacility for sshd, you should also modify /etc/syslog.conf so the syslogd daemon knows where to store messages coming in from that particular SyslogFacility (like LOCAL7).

Include a line like:
local7.debug    /var/log/mysshd.log

Also create an empty file /var/log/mysshd.log; the syslogd won't log into this file if it doesn't exist when the daemon starts!

And do not forget to refresh the syslogd daemon if you have modified the /etc/syslog.conf file, otherwise your changes won't have any effect.
# refresh -s syslogd

Alternative debugging for sshd

If you want to have the debugging information from sshd on-screen, you can start sshd in debugging mode. That means you run sshd in the foreground, where it will process ONLY ONE SESSION and terminate, instead of the normal behavior where it runs as a daemon in the background and processes multiple sessions.

That would normally mean stopping the regular sshd daemon, start sshd in the foreground, start one session that hopefully captures the problem and restart the daemon in the background. Luckily you can instruct both the client (ssh or scp) and server (sshd) to use a different port than the default port of 22, providing there is no firewall between the two systems, that blocks the traffic on the alternate port.

You have to start sshd using the full pathname and specify one or more "-d" options (just like -v with ssh), if you add more "d" characters you get deeper debugging output on-screen. Using the -p option, tells sshd what port to listen on. Use the -p option with ssh or scp also, to have your test ssh-session connect to the sshd with debugging enabled, instead of the default one.

Example 1:

# /usr/sbin/sshd -dd -p 4444

This will start sshd listing on port 4444, with debugging (level 2) sent to your screen.
Please note the sshd you started will terminate as soon as the ssh/scp/sftp session terminates.

Example 2:

# /usr/sbin/sshd -dd -p 4444 -E /tmp/mysshd.log

This will start sshd listening on port 4444, with debugging (level 3) sent to file /tmp/mysshd.log instead of your terminal.
And also in this case: the sshd you started will terminate as soon as the ssh/scp/sftp session terminates.

If you cannot use any other port than 22 (because you have no influence on the remote system ssh-ing into your system), you have to stop the regular sshd daemon first, and omit the "-p" option. Remember that you have to warn other users not to ssh into your system, you can only look at ONE incoming ssh session, before this foreground sshd process terminates. Restart sshd as soon as possible after your test finishes:

# stopsrc -s sshd

# /usr/sbin/sshd -ddd

# startsrc -s sshd



Last resort for sshd

If regular debugging output still doesn't give you any clues and you have used the AIX command "truss" before, you can debug exactly ONE session logging into sshd and capture exactly what it does by having the truss command run sshd.

The steps to take are:

• Prepare a command-line, script or testcase on an external system to connect to the system you want to debug, use a situation that always/usually generates the unexpected behavior.
• Start truss and instruct it to run sshd in the foreground, specify an output file to truss where detailed output is to go and also capture output from programs started by sshd to do its job:
  # truss -f -o /tmp/mytruss.out /usr/sbin/sshd -ddd -p 4444
• Initiate the ssh/scp/sftp session from the other server, to execute the test.
• Analyse the output from sshd and the output file logging details in the file saved by truss

(This trick once helped me to find out that scp (using the sftp protocol) to a system failed to work because the remote user I chose did not have read-permission on /etc/ssh/sshd_config file, no debug (or -v) option told me that)

If all fails

If this still doesn't give you any clues to what is going (or you can find what is going on, but cannot fix it) you can search the community or log a case with IBM support, if you meet the requirements of getting support (AIX levels and/or OpenSSH levels sufficiently recent etc.).