1

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 pi@192.168.1.33

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 192.168.1.33 [192.168.1.33] port 22.
debug1: connect to address 192.168.1.33 port 22: Connection refused
ssh: connect to host 192.168.1.33 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?

Improve this question
6
  • 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? – Steve Robillard Apr 12 '15 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 '15 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 '15 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? – Steve Robillard Apr 12 '15 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 '15 at 9:54
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 192.168.1.33 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?

Improve this answer
2
  • 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 '15 at 12:41
  • Is it possible that something else on your network got the 192.168.1.33 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 '15 at 12:09
1

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.

Improve this answer
0

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.

Improve this answer
2
  • 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 '15 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 '15 at 10:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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