I have a problem with a raspberry pi. This morning I switched on the raspi and the ssh does not work. If I try to connect typing

ssh -vvv [email protected]

the output is this:

OpenSSH_6.2p2, OSSLShim 0.9.8r 8 Dec 2011
debug1: Reading configuration data /etc/ssh_config
debug1: /etc/ssh_config line 20: Applying options for *
debug1: /etc/ssh_config line 102: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to [] port 22.
debug1: connect to address port 22: Connection refused
ssh: connect to host port 22: Connection refused

I want to underline that I have not edited any config file or similar from yesterday, when everything worked well.

I don't know if this can be useful but I opened the file var/log/auth.log on the raspi but there is no line about today. Just lines about yesterday. Probably ssh process does not start?

  • Please edit your question and add the output of: "ps aux | grep ssh" (without the quotes). This will let us know if the ssh daemon is running. Also you say you have not edited any config files, did you do an update/upgrade? Apr 12, 2015 at 8:49
  • The problem is that I don't have the cable for video, I've always used the raspi from ssh, so I can't launch commands! There's an alternative way to see if the daemon is running or I have to buy the cable? (Any update/upgrade)
    – cventr
    Apr 12, 2015 at 8:57
  • You can log in via the serial link on gpios 14/15 but that requires a USB serial dongle to plug in at the other end. Do you think the operating system you are using may be relevant? Perhaps add it to your post.
    – joan
    Apr 12, 2015 at 9:01
  • stupid question if you can't debug because you don't have a cable, how do you expect to fix the problem? Apr 12, 2015 at 9:02
  • That is the message you'd get if there's a system at that address but nothing listening on the ssh port. It doesn't mean it is for sure your pi. As Steve says debugging this without a screen, etc. makes it pretty hard. Presuming Raspbian, you could grep sshd /var/log/syslog on the card, see if it says why it didn't start or what happened to it.
    – goldilocks
    Apr 12, 2015 at 9:54

3 Answers 3


Since it seems to happen after a reboot is it possible that you didn't fixed the IP address and the reboot made it change?

If you do ping do you have an answer?

Also I don't understand: in your question you say that you checked var/log/auth.log on your pi and in the comments you say that you can't make a pson it, how is it possible?

  • I don't think that is a problem of IP because it pings normally. I checked the auth.log by inserting the sd card in the pc.
    – cventr
    Apr 12, 2015 at 12:41
  • Is it possible that something else on your network got the from DHCP and that the Pi now has a different IP? Also, were you able to follow goldilocks's suggestion and check /var/log/syslog on the card?
    – mazianni
    Apr 14, 2015 at 12:09

Is there any software running in the background that could be hammering stdout?

I had a similar problem occur after I added some debugging code to the software I was testing on my pi. ssh server was running ok and listening on port 22, but always came back with 'connection refused'. It turned out the problem was the debugging code I added to my software was spewing a lot of text to stdout, and this was running in the background initiated from an init.d script - it seems this caused a problem with ssh connection. After removing the code that was hammering stdout - the ssh server worked again.


I had a similar problem today, and found that a recent change in configuration was causing the boot sequence to stall, waiting for input. In turn, that prevented sshd from starting.

The configuration change also messed up my cmdline.txt file, so I wasn't seeing boot messages on the screen.

First, I mounted the root volume on my laptop, and edited cmdline.txt, removing the offending console=tty1:

dwc_otg.lpm_enable=0 console=ttyAMA0,115200 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline rootwait

Then I started the Pi, and used a serial connection to repair the boot problem. A monitor, keyboard and mouse would probably have worked as well.

  • Hello and welcome. Thank you for your input. Could you please specify which OS/distro you use and whether an update or "user-interference" changed that config? I think those information could be useful to the (future) reader of this answer.
    – Ghanima
    Dec 13, 2015 at 1:20
  • I am running Raspian-jessie. I am not sure what specifically caused the change in cmdline.txt. I installed several components related to VPN. As for the damage to the boot sequence, that was all my own doing!
    – JDA3
    Dec 14, 2015 at 10:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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