problems with ssh

jack

Have you enabled ssh on the pi - I believe it is disabled by default.

Where are you getting the address for the pi from? Are you sure that what's on that address is in fact the pi?

Look at the sshd logs on the target host. /var/log/auth.log is the main one, though there may be some useful content in daemon.log too.

The following list from /var/log/auth.log shows me starting sshd with 'sudo service start sshd' and attempting to connect with 'ssh pi@192.168.0.104'

************************************************************************* Dec 14 13:14:33 beta sshd[5635]: Accepted password for jack from 192.168.0.104 port 56346 ssh2 Dec 14 13:14:33 beta sshd[5635]: pam_unix(sshd:session): session opened for user jack by (uid=0) Dec 14 13:14:33 beta systemd-logind[768]: New session 8 of user jack. Dec 14 13:17:01 beta CRON[5727]: pam_unix(cron:session): session opened for user root by (uid=0) Dec 14 13:17:01 beta CRON[5727]: pam_unix(cron:session): session closed for user root ************************************************************************

The same thing happens (or fails to happen) in the other direction.

jack

Sorry! I meant 'service ssh start'

*************************************************************************

This line is suspect: it is a localhost alias conflicting with the 'beta' line lower on (192.168.0.101)

--

-TV

Nothing in there for user pi.

I have two suggestions:

1) Use ssh with -v or -v -v -v to get an idea of what ssh thinks is going on. 1b) Start a verbose instance of sshd on a different port, and look at it's verbose logs (can be a little trickier, because you need key files, but you can do this as a non-root user). 2) The ssh is working, but you have configured something on startup (eg in .login or .profile) that prevents a shell from ever answering. Something like 'startx' in your .login, for example.

Elijah

------ usually can figure these problems out without resorting to a 1b solution

On Thu, 14 Dec 2017 19:34:07 +0000, Eli the Bearded wrote:

************************************************************************* ************************************************************************

Here is the, rather long, result of 'ssh -v pi@192.168.0.104'

***************************************************************************

jack@beta:~$ ssh -v pi@192.168.0.104 OpenSSH_7.5p1 Ubuntu-10, OpenSSL 1.0.2g 1 Mar 2016 debug1: Reading configuration data /etc/ssh/ssh_config debug1: /etc/ssh/ssh_config line 19: Applying options for * debug1: Connecting to 192.168.0.104 [192.168.0.104] port 22. debug1: Connection established. debug1: key_load_public: No such file or directory debug1: identity file /home/jack/.ssh/id_rsa type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/jack/.ssh/id_rsa-cert type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/jack/.ssh/id_dsa type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/jack/.ssh/id_dsa-cert type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/jack/.ssh/id_ecdsa type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/jack/.ssh/id_ecdsa-cert type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/jack/.ssh/id_ed25519 type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/jack/.ssh/id_ed25519-cert type -1 debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_7.5p1 Ubuntu-10 debug1: Remote protocol version 2.0, remote software version OpenSSH_6.7p1 Raspbian-5+deb8u3 debug1: match: OpenSSH_6.7p1 Raspbian-5+deb8u3 pat OpenSSH* compat

0x04000000 debug1: Authenticating to 192.168.0.104:22 as 'pi' debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: algorithm: snipped-for-privacy@libssh.org debug1: kex: host key algorithm: ecdsa-sha2-nistp256 debug1: kex: server->client cipher: snipped-for-privacy@openssh.com MAC: compression: none debug1: kex: client->server cipher: snipped-for-privacy@openssh.com MAC: compression: none debug1: expecting SSH2_MSG_KEX_ECDH_REPLY debug1: Server host key: ecdsa-sha2-nistp256 SHA256:2THE2JPxFtwHBWnyOfaRD7wcLZF+DPTZB6ymqx4RKxA debug1: Host '192.168.0.104' is known and matches the ECDSA host key. debug1: Found key in /home/jack/.ssh/known_hosts:7 debug1: rekey after 134217728 blocks debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug1: SSH2_MSG_NEWKEYS received debug1: rekey after 134217728 blocks debug1: SSH2_MSG_SERVICE_ACCEPT received debug1: Authentications that can continue: publickey,password debug1: Next authentication method: publickey debug1: Trying private key: /home/jack/.ssh/id_rsa debug1: Trying private key: /home/jack/.ssh/id_dsa debug1: Trying private key: /home/jack/.ssh/id_ecdsa debug1: Trying private key: /home/jack/.ssh/id_ed25519 debug1: Next authentication method: password pi@192.168.0.104's password: debug1: Authentication succeeded (password). Authenticated to 192.168.0.104 ([192.168.0.104]:22). debug1: channel 0: new [client-session] debug1: Requesting snipped-for-privacy@openssh.com debug1: Entering interactive session. debug1: pledge: network debug1: Sending environment. debug1: Sending env LANG = en_CA.UTF-8 ******************************************************************************

Note that seven lines before the end it accepts and authenticates the password. After the last line it freezes and I have to X the terminal window.

Jack

Something?s off there. You are connecting (in the command above) to

192.168.0.104, but the logs you?re quoting show the same address as the origin of some other connection.

Perhaps you?re quoting the logs from the wrong place.

--
https://www.greenend.org.uk/rjk/

...

That tells me the issue is not ssh. The connection is working, and ssh has started some command (typically your login shell). You can probably force quit ssh with where tilde () is the default escape key, unless reset with -e on command line or EscapeChar in an ssh conf file. (I regularly reset the EscapeChar to asterisk myself.)

Time to look at number two:

What's the shell? What's in the home directory, in particular dot files that your shell will execute? (Also might need to look at the /etc/ versions of those files, like /etc/profile.)

The bit cross-thread about IP addresses in /etc/hosts is worth fixing, too.

Elijah

------ is also the escape char for other programs...

Have you checked for an 'exit' command in /etc/bash_profile and ~/.profile or ~/.bashrc

--

Chris Elvidge, England

There are no 'exit' commands in ~/.profile or ~/.bashrc. I don't seem to have a /etc/bash_profile file.

To summarize. I can ssh from beta to alpha with no problem. raspberrypi cannot ssh with alpha or beta. So the problem certainly seems to lie with the Raspberry Pi.

I suppose there might be some problem with the wifi link, so I'll give it a wired connection and see what that does.

Jack

BREAKING NEWS!!

The wired connection works perfectly both ways. So it's a wifi problem!

I shall study this more closely and see how it's configured in the router etcetera. Or perhaps I need some ip4 or ip6 details filled in.

Jack

Some wireless routers and APs deliberately muck about with inter-device connectivity. It's a "feature". Throw it out and buy a Unifi. (Other competently-designed WAPs are available.)

It's about 2 years I haven't touched a raspberry, but isn't the 'default user' 'pi' and there is a default password I forgott!! Usualy I sudo su root then edited /etc/ssd.conf to allow running command without su of cuas you still need to be root do what only root is allowaed to do. You can then also create other users (userad....) Andre

"raspberry"!

"Muck about" is a strong expression for a security feature. AP isolation is a security feature designed to limit a WiFi device connected to the AP from interacting with any other WiFi device or wired device connected. You can usually select whether isolation runs just between WiFi devices or WiFi and wired.

It's a useful feature to have enabled if you have lots of unknown clients connecting to your AP, such as a coffee shop, as it stops an infected WiFi device trying to infect other devices connected. Less so on a home network.

Exactly. and even less than that for an encrypted network where you know exactly who is in it and who not. Networking between my macjines is over half my router's utility -- outside connections via Internet less than half.

Selling a router that won't connect attached devices in its default setup is fraud imho.

--




/ \  Mail | -- No unannounced, large, binary attachments, please! --