I'm using a new raspbian image (Jessie). I tried both lite and normal. Wifi connection is ok, I can browse the web and ping with no problems.

Starting an SSH connection (either from RPi3 to a Linux box or from the Linux Box to RPi3) starts ok. Connection is established, it asks for the user, then the password. After that it's stuck. The window is frozen and the prompt never appears.

Any ideas will be appreciated. Thanks!

  • 1
    What exactly have you tried? Past the output into the question. – Milliways Mar 30 '16 at 5:51
  • Paste the output of ssh -v - that will enable verbose mode which might help clarify where it's getting stuck. – dimo414 Mar 31 '16 at 3:34
  • Try ssh -o GSSAPIAuthentication=no pi@raspberrypi – Maux Apr 2 '16 at 14:57
  • Thanks for your reply. Unfortunately even though adding "-o GSSAPIAuthentication=no" eliminates a couple of messages in the terminal when "-v" is added to the command line, the final result is the same. – Daniel Apr 7 '16 at 2:51
  • pi@raspberrypi:~ $ ssh -v -o GSSAPIauthentication=no root@ OpenSSH_6.7p1 Raspbian-5+deb8u1, OpenSSL 1.0.1k 8 Jan 2015 debug1: Reading configuration data /etc/ssh/ssh_config debug1: /etc/ssh/ssh_config line 19: Applying options for * debug1: Connecting to [] port 22. debug1: Connection established. debug1: key_load_public: No such file or directory debug1: identity file /home/pi/.ssh/id_rsa type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/pi/.ssh/id_rsa-cert type -1 debug1: key_load_public: No such file or directory – Daniel Apr 7 '16 at 2:57

Without additional information from the output of ssh -v I can think of two things:

  1. You have another machine on the same subnet with the same IP address. This could be because your DHCP server / cablebox / whatever is borked, or because you have given a static IP address to that other machine. To diagnose this, make a note of the IP address and the MAC address of your Pi (ifconfig -a shows you all the interfaces and their addresses) and turn it off. Now go to some other machine, make sure there is no ARP entry for the Pi you just turned off (sudo arp -an; if you see the IP address or the MAC address there, use sudo arp -d to remove that entry. Now ping again. If you get a response, it means that I was right and there was a machine with a duplicate address on your network.

  2. You could have some strange settings in your ssh config files. Remove them (well, move them out of the way), and try again.

If neither helps, make sure you give us the output of ssh -v just like another responder suggested.

  • Unfortunately the IP is unique. "ping <RPI3 IP>" from other machine answers. Turned RPI3 off -> stopped answering. Flushed arp cache (arp -d <RPI3 IP>). Ping again -> now answer nor MAC entry in ARP table. Turn RP3 on again -> answer and MAC entry. I attached ssh -v output in the previous comment. Thanks! – Daniel Apr 7 '16 at 3:06
  • When you lose ssh connectivity between the Pi and your other machine, can you still ping the pi / start a new ssh connection? Here is another debugging suggestion. On your pi, from the console (so, not ssh-ed), run tcpdump -n -i eth0 -s 1500 -X -v -v not port 22 > traces1 and tcpdump -n -i eth0 -v -v port 22 > traces2 in the background. When the connection dies, look at the packet traces to see if you can identify something, such as lots of packets suddenly being transmitted, a spurious TCP RST to port 22, that kind of thing. – JayEye Apr 7 '16 at 5:37

From the looks of your output above you are missing your keys file/folder. I wrote a simple script to handle this as I am constantly nuke paving my setups.

Try this script out. You can place it in your user folder and run as sudo. If you don't need a root key just don't set one, it will gracefully exit and not set it up for root.

You need to generate and enter your keys in the auth variables up top.

chmod this to be executable.

chmod 0777 <name_of_script>

Run it with no args to see the help display.


## non-root username

#### No need to edit anything below ####

ulimit -c unlimited
case "$1" in

    if [ $USER = "root" ]; then
        if grep "$auth_key_user" "/home/$user/.ssh/authorized_keys" > /dev/null && [[ ( "$usersize" > 10 ) ]]
            echo user key exists
            if [[ ( "$usersize" < 1 ) ]]
                echo Can\'t apply an empty key. You need to enter one in the script.
                if [ ! -f /home/$user/.ssh/authorized_keys ]; then
                    mkdir /home/$user/ssh
                    mv /home/$user/ssh /home/$user/.ssh
                echo user key doesn\'t exist, writing it.
                echo $'\r' >> /home/$user/.ssh/authorized_keys
                echo $auth_key_user >> /home/$user/.ssh/authorized_keys
                chmod 0755 /home/$user/.ssh
                chmod 0644 /home/$user/.ssh/authorized_keys
                chown -R $user:$user /home/$user/.ssh
        if grep "$auth_key_root" "/root/.ssh/authorized_keys" > /dev/null && [[ ( "$rootsize" > 10 ) ]]
            echo root key exists
            if [[ ( "$rootsize" < 1 ) ]]
                echo Can\'t apply an empty key. You need to enter one in the script.
                if [ ! -f /root/.ssh/authorized_keys ]; then
                    mkdir /root/ssh
                    mv /root/ssh /root/.ssh
                echo root key doesn\'t exist, writing it.
                echo $'\r' >> /root/.ssh/authorized_keys
                echo $auth_key_root >> /root/.ssh/authorized_keys
        echo This needs you to run the script as sudo or root...
        exit 1

    printf "\n"
    printf " Usage: \t$0 [$(tput bold)$(tput setaf 1)help$(tput sgr0)|$(tput bold)$(tput setaf 1)auth$(tput sgr0)]\r\n"
    printf "\n"
    printf " $(tput bold)$(tput setaf 2)auth$(tput sgr0)\t\tSets your ssh authorized keys if you entered them in this script.\n"
    printf " $(tput bold)$(tput setaf 2)help$(tput sgr0)\t\tDisplays this guide.\n"
    printf "\n"

exit 0

I have seen that ntpd kills the network on my RPi 3, in syslog.

Think this describes it, NTP time check freezes network.

  • 1
    I cannot think of a mechanism by which ntpd would kill the network. There is no real time clock on the Pi, so it's not like some bug could be triggered by writing to the rtc register(s) (at least I think there is no RTC; if it exists, it has no entry anywhere in /sys). Unless what is being interpreted as the network dying is ntpd going into a tight loop, flooding the network with back-to-back packets, but that should be easy to check with tcpdump. – JayEye Apr 7 '16 at 5:27

Just to make sure that the basic configuration is correct- go to Menu >> Preferences >> Raspberry Pi Configuration >> Interfaces tab. Then check if SSH is Enabled.


There is a thread https://www.raspberrypi.org/forums/viewtopic.php?f=28&t=138631&start=75 describing your problem, if you can ssh via cable, but not via wifi. The solution is described at the end of page 4 of the thread:

Add the line

IPQoS cs0 cs0

to /etc/ssh/sshd_config and restart the daemon (or the raspi).

sudo service ssh restart

protected by Ghanima Nov 24 '16 at 0:49

Thank you for your interest in this question. Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).

Would you like to answer one of these unanswered questions instead?

Not the answer you're looking for? Browse other questions tagged or ask your own question.