7

I have just upgraded my Debian server from Stretch (stable) to Buster (testing).

One strange thing I can't seem to resolve:

$ ssh [email protected] -p [censored] -o ConnectTimeout=5 -i /home/vlastimil/.ssh/id_rsa -vvv

results in:

OpenSSH_7.6p1 Ubuntu-4, OpenSSL 1.0.2n 7 Dec 2017 debug1: Reading configuration data /etc/ssh/ssh_config debug1: /etc/ssh/ssh_config line 19: Applying options for * debug2: resolving "192.168.0.102" port [censored] debug2: ssh_connect_direct: needpriv 0 debug1: Connecting to 192.168.0.102 [192.168.0.102] port [censored]. debug2: fd 3 setting O_NONBLOCK debug1: connect to address 192.168.0.102 port [censored]: Connection refused 

ssh: connect to host 192.168.0.102 port [censored]: Connection refused

However, if I log in as that user locally (I can even log off then, it just needs one login), it does work.

I was able to log in as root. However, only from the one machine, in spite of having public key exchanged.

Further, only one root login from that one machine needed, and then it is possible to log in as root from the other machine.

Could anyone elaborate as to, how do I debug this issue?

Server's config:

# grep -v '#' /etc/ssh/sshd_config Port [censored] Protocol 2 SyslogFacility AUTH LogLevel INFO LoginGraceTime 120 StrictModes yes HostbasedAuthentication no IgnoreRhosts yes PermitEmptyPasswords no ChallengeResponseAuthentication no UsePAM yes X11Forwarding yes PrintMotd no PrintLastLog no Banner none AcceptEnv LANG LC_* Subsystem sftp /usr/lib/openssh/sftp-server KeyRegenerationInterval 3600 ServerKeyBits 4096 Ciphers [email protected],[email protected] MACs [email protected] KexAlgorithms [email protected] FingerprintHash sha512 Match Address 192.168.0.* PermitRootLogin yes Match all PermitRootLogin no
Improve this question

3 Answers 3

Reset to default
7

Thanks to telcoM's answer about a Hardware RNG I did an apt search and found the package rng-tools5 and installed it:

sudo apt-get install rng-tools5

This resolved the issue on my Intel NUC.

Editor's note: My issue on Dell PowerEdge T20 with Xeon CPU was also resolved with this.

Additional notes:

  • After installation of the package, please do check if there is a random source with:

    rngd -v

    In my case, there is no TPM device, but the CPU has rdrand capability:

    Unable to open file: /dev/tpm0 Available entropy sources: DRNG
Improve this answer
0
6

connection refused suggests that sshd is not running.

It might be just a matter of time: when the login prompt appears on the console, it does not guarantee that all the system services have completed startup yet.

sshd might be also be stuck waiting on /dev/[u]random, especially if the system is located in a network segment with very little network traffic. In this case, the system has very few sources of true randomness available and has difficulties gathering up enough truly random bits for initially seeding the kernel's random number generator. Logging onto the system console will provide some randomness in the form of the lowest bits of keyboard interrupt call times. If the system has some form of hardware RNG, enabling it might fix this problem.

To diagnose, just type a few lines of nonsense to the console login prompt without actually logging in. If sshd responds normally after that, the kernel was probably starved of randomness and unable to seed the kernel RNG, and that caused the startup of sshd to be delayed.

Or it might be some sort of systemd dependency bug that only allows sshd to start up when the login-related processes get started first. That would be one of the reasons why Debian Buster is still the testing distribution: if this turns out to be the cause, please send a bug report.

Improve this answer
0
2

The package haveged solved the problem.

The thread: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=912087

Improve this answer

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.