====== SSH Error ======

This situation can occur in case of failure when stopping a WPAR, only on the Global LPAR; most time the random device has disappear, which is needed to generate random number for SSH:

==== Debug mode for SSH ====

for a server:
  - stopsrc -s sshd
  - /usr/sbin/sshd -ddd   (only one d for less verbose mode; this process end at end of the first ssh connexion, and only one simultaneous session is authorized)

for a client:
  - /usr/bin/ssh -vvv <hostname> (same as server, less v for less verbose

==== SAMPLES SSH ERRORS ====

=== PTY allocation request failed on channel 0 ===

If ssh is not started on a WPAR, connect with clogin, and start it as daemon, or as single process with debug if needed (/usr/sbin/sshd -ddd)
<cli prompt='#'>
[root@test1]/root# ssh testsrv
ssh: connect to host testsrv port 22: Connection refused

[root@testsrv]/root# startsrc -s sshd
0513-059 The sshd Subsystem has been started. Subsystem PID is 7929996.
</cli>

Once ssh is started, if you have a PTY allocation error, then check the console, it might not be NULL:
  * On a WPAR: /var/adm/ras/conslog
  * On an LPAR: /dev/vty0
Random devices will be generated after a reboot (stopwpar/startwpar if WPAR, shutdown -Fr if LPAR)
<cli prompt='#'>
[root@test1]/root# ssh testsrv
PTY allocation request failed on channel 0

[root@testsrv]/root# lscons
NULL
[root@testsrv]/root# chcons -a login=disable /var/adm/ras/conslog
chcons: console login disabled, effective on next system boot
chcons: console assigned to: /var/adm/ras/conslog, effective on next system boot
[root@testsrv]/root# lscons
/var/adm/ras/conslog
</cli>



=== PRNG is not SEEDED ===

<cli prompt='#'>
Step 1: 
Check permissions on random numbers generators, the ”other” must have ”read” access to these devices:
# ls -l /dev/random
crw-r----- 1 root system 39, 0 Jan 22 10:48 /dev/random
# ls -l /dev/urandom
crw-r----- 1 root system 39, 1 Jan 22 10:48 /dev/urandom

#chmod o+r /dev/random; chmod o+r /dev/urandom
</cli>

<cli prompt='#'>
Step 2:
If /dev/random doesn’t exist anymore, look for the ID into the ODM, to recreate the random device like it was:
# odmget CuDvDr | grep –p random
CuDvDr:
    resource  =  “ddins”
    value1 = “random”
    value2 = “39”        --> ID 
    value3 = “”
</cli>

<cli prompt='#'>
Step 3:
# stopsrc -s sshd
</code>

<code>
Step 4:
# rm -rf /dev/random
# rm -rf /dev/urandom
Recreate random devices with the correct ID (major number), and minor number 0 for random and 1 for urandom
# mknod /dev/random c 39 0
# mknod /dev/urandom c 39 1
Reload the kernel module:
# randomctl -l
</cli>

<cli prompt='#'>
Step 5:
check permissions again and start sshd
# startsrc -s sshd
</cli>

=== Additionnal information: ===
- check the kernel module:
<cli prompt='#'>
# genkex|grep rand
         53ff000    1d000 /usr/lib/drivers/random
</cli>
- unload the kernel module:
<cli prompt='#'>
# randomctl -u
</cli>

=== Error sftp not working ===

On Winscp you have the following error
  cannot initialize SFTP protocol. Is the host running a SFTP server?
sftp returns "Connection closed" immediately after entering password 

The three most common reasons for the sftp server to close the connection are

1. Incorrect path to the sftp-server binary in /etc/ssh/sshd_config
2. Incorrect permissions on the /etc/ssh/sshd_config file
3. "ListenAddress" is defined after sftp-server subsystem in /etc/ssh/sshd_config

Check the permissions on the sshd_config file
<cli prompt='#'>
#  ls -l /etc/ssh/sshd_config
-rw-r--r--    1 root     system         3478 Sep 07 01:19 /etc/ssh/sshd_config
</cli>

The permissions should be 644 and the ownership root:system.
<cli prompt='#'>
# chmod 644 /etc/ssh/sshd_config
# chown root:system /etc/ssh/sshd_config
</cli>

If you are not able to allow world read access due to restrictions in your environment, (e.g. your permissions are 640) you will need to use the in-process sftp server instead by changing the subsystem line as shown below. Restart sshd after making any changes to the config file.
<cli prompt='#'>
Subsystem       sftp    internal-sftp
</cli>

Then restart sshd demon

=== Error unable to login without password ===

If you have an error with right access, then check **SSH rights**:
  - the user home directory on the target: you have maybe to many rights, the group and other can't have a write access (755 is correct, not more)
  - .ssh into the target user home directory must have 700
  - authorized_keys must be 600
<code>
debug2: userauth_pubkey: authenticated 0 pkalg ssh-rsa
Postponed publickey for repmon from 10.170.233.21 port 60889 ssh2
debug1: userauth-request for user repmon service ssh-connection method publickey
debug1: attempt 2 failures 0
debug2: input_userauth_request: try method publickey
debug3: mm_key_allowed entering
debug3: mm_request_send entering: type 20
debug3: mm_key_allowed: waiting for MONITOR_ANS_KEYALLOWED
debug3: mm_request_receive_expect entering: type 21
debug3: mm_request_receive entering
debug3: monitor_read: checking request 20
debug3: mm_answer_keyallowed entering
debug3: mm_answer_keyallowed: key_from_blob: 2007e9f8
debug1: temporarily_use_uid: 205/206 (e=0/0)
debug1: trying public key file /opt/repmon/home/.ssh/authorized_keys
debug1: fd 5 clearing O_NONBLOCK
debug3: secure_filename: checking '/opt/repmon/home/.ssh'
debug3: secure_filename: checking '/opt/repmon/home'
debug3: secure_filename: terminating check at '/opt/repmon/home'
debug1: matching key found: file /opt/repmon/home/.ssh/authorized_keys, line 2
Found matching RSA key: 3c:f4:36:54:a8:75:69:4a:22:37:de:25:0c:7a:59:86
debug1: restore_uid: 0/0
debug3: mm_answer_keyallowed: key 2007e9f8 is allowed
debug1: Failed to collect Cookie from Keystore
</code>