in trying to SSH from vera to my mac, I am getting this error:
ssh: Connection to admin@192.168.1.9:22 exited: No auth methods could be used.
I have been trying to get an RSA key working, but bumbling around on this.
ssh takes a -v option (more than once if you want more) for verbosity. It might hint at the reason why your private key is not being used.
Common pitfalls:
[ul][li]The private key file may be readable by others. Use chmod 600 to make it readable only by the user.[/li]
[li]The private key file may need to be specified with the -i option.[/li]
[li]The authorized_keys file on the destination machine may not have your public key in it.[/li][/ul]
i appreciate the response.
is this something i can fix in my mac’s Keychain Access tool or at the root?
from my vera
root@MiOS_35555555:~# ssh -v root@192.168.1.9
WARNING: Ignoring unknown argument ‘-v’
ssh: Connection to root@192.168.1.9:22 exited: No auth methods could be used.
root@MiOS_35018005:~#
logged from my laptop to the same server:
jimbmacbookpro:~ bjames$ ssh -v root@192.168.1.2
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: Connecting to 192.168.1.2 [192.168.1.2] port 22.
debug1: Connection established.
debug1: identity file /Users/bjames/.ssh/id_rsa type -1
debug1: identity file /Users/bjames/.ssh/id_rsa-cert type -1
debug1: identity file /Users/bjames/.ssh/id_dsa type -1
debug1: identity file /Users/bjames/.ssh/id_dsa-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.2
debug1: Remote protocol version 2.0, remote software version dropbear_0.53.1
debug1: no match: dropbear_0.53.1
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: sending SSH2_MSG_KEXDH_INIT
debug1: expecting SSH2_MSG_KEXDH_REPLY
debug1: Server host key: RSA 02:b8:3a:c1:dc:65:fa:c7:cf:e9:dc:da:53:34:19:28
debug1: Host ‘192.168.1.2’ is known and matches the RSA host key.
debug1: Found key in /Users/bjames/.ssh/known_hosts:5
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Trying private key: /Users/bjames/.ssh/id_rsa
debug1: Trying private key: /Users/bjames/.ssh/id_dsa
debug1: Next authentication method: password
root@192.168.1.2’s password:
debug1: Authentication succeeded (password).
Authenticated to 192.168.1.2 ([192.168.1.2]:22).
debug1: channel 0: new [client-session]
debug1: Entering interactive session.
debug1: Sending environment.
debug1: Sending env LANG = en_US.UTF-8
So the SSH client on Vera doesn’t take the -v option. Annoying.
Did you expect public key auth to work in your second example? Looks like a bad or missing authorized_keys file. Or it could be that SSH to root has been disabled. I suggest that you try to SSH to a mortal user at your server rather than root.
The other way you can monitor this is to tail the sshd log file on the server and watch the log for incoming connections. You may have to increase verbosity in the sshd.config file.
This is all OS-independent so you can and should use resources other than this forum.
(Edit: rereading my last paragraph I see that you might interpret it with a silent “instead” at the end of the sentence. In fact it has a silent “as well” at the end.)
OK then.
Every other computer with which I try to connect to the OSX server, connects. The one device that will not connect is my Vera, so I thought going to the vera forum with a vera problem was a reasonable place to go for help. I’m also working with the OSX resource pool out there. This isn’t a problem I’ve come across before, so I am looking for help. I am guessing that helping folks solve problems must be at least one of the objectives of of a forum like this.
Bear in mind that you are always in the position to disregard anything that’s posted here, if its troubling you that much.
thanks.
@BDL
I’ll try this when I get back from out of town. It was a bit of trial and error when I get it working with Linux. I have some notes that condense the procedure down. Permissions was a big deal also!
Won’t be able to look at it till Friday though. I will get my docs posted here then 
That would’ve been helpful to know from the outset.
So there could be a few avenues to explore. I would definitely be looking at the sshd (daemon) log on the server and comparing a successful login from another server with an unsuccessful one from Vera. You would be looking for the LogLevel entry in /etc/sshd_config to increase the logging verbosity.
Perhaps the Vera ssh program is using a protocol or cipher that the server has been told to reject. Perhaps the Vera ssh program has been told to only try authentication methods that the server rejects. Perhaps you haven’t put the SSH keys into the right directory on Vera; it seems to want to use /etc/dropbear rather than /root/.ssh in some cases, for instance. Use the -i option to explicitly specify the key file to avoid that ambiguity.
Please don’t mistake my tenseness for impatience. I am typing this on a tiny phone screen and I don’t want to give myself RSI. Also I can’t log into my Vera from here so I can’t see just how crippled its SSH implementation is. A lot of this is from memory.
Futzle,
right, thanks.
You gave me a lot to look at and I will do that. I’m gong to start with those logs. You are helping… You mentioned to look for the authorized_keys file on the server and it is not there, so I have to muck about there and figure out how to get that file back and copy my public key into it (which I created in Vera).
JimPapa, thanks and I also appreciate anything you can drag out. I’ll probably still be dribbling this ball in between my normal life.
[quote=“Bulldoglowell, post:8, topic:179977”]Futzle,
right, thanks.
You gave me a lot to look at and I will do that. I’m gong to start with those logs. You are helping… You mentioned to look for the authorized_keys file on the server and it is not there, so I have to muck about there and figure out how to get that file back and copy my public key into it (which I created in Vera).
JimPapa, thanks and I also appreciate anything you can drag out. I’ll probably still be dribbling this ball in between my normal life.[/quote]
@BDL
Did you get this working? I just got back to my desktop and have my notes…
yes, thanks
Im driving my wife nuts with the announcements. it is great!
check out my virtual grandfather clock for iTunes airplay…
my kids LOVE it (8 and 5yrs old)
–Grandfatherclock
– Pause iTunes
os.execute(“ssh -y -i ~/.ssh/id_rsa root@192.168.1.9 osascript /usr/bin/pause-itunes.txt”)
– speak the chime
os.execute(“ssh -y -i ~/.ssh/id_rsa root@192.168.1.9 say -v Cellos Dum dum dum dum dum dum dum he he he ho ho ho fa lah lah lah lah lah lah fa lah full hoo hoo hoo”)
–eliminate leading zero in hour without futzing up 10:XX
local hour = os.date(“%I”)
if hour == tostring(10) then
spkhour = 10 else
spkhour = string.gsub(hour, “0” , “”)
end
–eliminate double zeroes at top of the hour, replace with o’clock
local minute = os.date(“%M”)
local spkminute = string.gsub(minute, “00” , " o clock")
–build the expression string
local time = os.date(" %p “)
local open=“ssh -y -i ~/.ssh/id_rsa root@192.168.1.9 say the current time is”
local close =”"
local express = open … spkhour … " " … spkminute … time … close
os.execute(express)
–Resume iTunes
os.execute(“ssh -y -i ~/.ssh/id_rsa root@192.168.1.9 osascript /usr/bin/resume-itunes.txt”)
Cool! I guess I will follow YOUR notes and get the airplay going along with the SONOS. TTS is fun!
Jim,
I have gotten pretty far along with getting Vera notifications over AirPlay. At the command line in OSX, by adding the -a argument when you pass this expression:
os.execute(“ssh -y -i ~/.ssh/id_rsa root@192.168.1.9 say -a DEVICENO your TTS message here”)
where DEVICENO is the output device for the “say” command in OSX.
you retrieve the DEVICENO (or Device Name, you can use “AirTunes”) with: say -a “?” at the command line
server:~ admin$ say -a “?”
39 AirPlay
47 Built-in Output
64 Display Audio
so far i have developed TTS alerts for several events and I can say it is pretty impressive. Not ever seeing the SONOS implementation, I can say that I believe there are a couple of strengths and weaknesses here based on what vera forum members have discussed.
For iTunes, it works well. I tried and tried use applescript to retrieve the current state of iTunes, pause it if it is on, play the announcement and continue where iTunes was. It was more troublesome than I expected but I settled in on a ‘compromise’ solution, I am muting iTunes. This toggle will not affect iTunes if it isn’t playing and since the announcements are just a few seconds, losing a small bit of an aria playing is no big deal otherwise.
I use the basic applescript (mute-itunes.txt) to mute:
tell application “iTunes”
set the mute to true
delay 1
end tell
and unmute (unmute-itunes.txt) by:
tell application “iTunes”
delay 1
set the mute to false
end tell
to pause, I do this
– mute{unmute} iTunes
os.execute(“ssh -y -i ~/.ssh/id_rsa root@192.168.1.9 osascript /usr/bin/mute{unmute}-itunes.txt”)
The issue is when an AirPlay device is engaged in non-iTunes activity. This method will stop the movie, music, etc and play the TTM message, but I have not been able to get that device to resume. So the ‘good’ is that the message gets sent, the 'bad is that those involved have to use the controls to resume what they were doing.
not too shabby. and I don’t have to go out and pay for Sonos.
I’ll update you if I can get that movie to resume, or those locally selected pieces of music back playing…
Hi BulldogLowell I am running into the same issue you initially had here. I am not clear on exactly how you resolved the issue. Did you generate the Keys on the Vera or on the Mac? I am not entirely sure how the id_rsa works. I will be Googling more on this but if you could help to clarify how you got the keys, that would be appreciated.
Thanks!
OK … I managed to figure it out. Here are the complete steps of how to make this work:
- You need to be able to SSH into your Veralite. To do this you need your the password to your Veralite. It can be recovered as follows:
- Do Backup from Web UI
- Open tar file backup and extract password - there are other threads on this.
- SSH into Veralite as root user and enter password
- Enter command dropbearkey -t rsa -f ~/.ssh/id_rsa … this generates a public RSA key
- Enter command dropbearkey -y -f ~/.ssh/id_rsa - this displays the RSA Key
- Cut and paste to authorized_keys file on Mac It is located in ?yourusername?/.ssh folder. If it is not there just create one with vi or nano.
- You should now be able to login to your Mac from the Veralite
- Test Login succeeds by command ssh -y -i ~/.ssh/id_rsa yourusername@192.168.1.xx … where yourusername is the user name on your Mac.
- In Luascript you need the following:
os.execute(“ssh -y -i /root/.ssh/id_rsa yourusername@192.168.1.xx say Hey there”)
Notice that the location has /root/ added … that is because lua runs from different directory it seems.
Does the os.execute need a close or timeout or something?
Vera doesn’t like mine, usually take 2+ minutes to actually initiate the action… if it ever does.