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:
for a server:
for a client:
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)
[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.
Once ssh is started, if you have a PTY allocation error, then check the console, it might not be NULL:
Random devices will be generated after a reboot (stopwpar/startwpar if WPAR, shutdown -Fr if LPAR)
[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
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
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 = “”
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
Step 5: check permissions again and start sshd # startsrc -s sshd
- check the kernel module:
# genkex|grep rand 53ff000 1d000 /usr/lib/drivers/random
- unload the kernel module:
# randomctl -u
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
# ls -l /etc/ssh/sshd_config -rw-r--r-- 1 root system 3478 Sep 07 01:19 /etc/ssh/sshd_config
The permissions should be 644 and the ownership root:system.
# chmod 644 /etc/ssh/sshd_config # chown root:system /etc/ssh/sshd_config
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.
Subsystem sftp internal-sftp
Then restart sshd demon
If you have an error with right access, then check SSH rights:
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