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 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?
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 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 ps
on 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– cventr2015年04月12日 12:41:42 +00:00Commented Apr 12, 2015 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– mazianni2015年04月14日 12:09:44 +00:00Commented 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.2015年12月13日 01:20:55 +00:00Commented 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– JDA32015年12月14日 10:28:08 +00:00Commented Dec 14, 2015 at 10:28
grep sshd /var/log/syslog
on the card, see if it says why it didn't start or what happened to it.