Welcome to the MacNN Forums.

If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below.

You are here: MacNN Forums > Software - Troubleshooting and Discussion > macOS > setting up SSH

setting up SSH
Thread Tools
coitus
Forum Regular
Join Date: Aug 2000
Location: OKC, OK USA
Status: Offline
Reply With Quote
Feb 4, 2002, 02:57 PM
 
Setting up an OSX box to SSH into a freeBSD box running SSH2 Daemon (www.ssh2.org). The default for SSH2 is to have the Identification and the Authorization files in the .ssh2 directory in the ~ . Win SSH clients seem to work fine connecting to this box however for some reason the Mac running the open ssh client can't seem to connect.

Is it possible to use the ssh client to public key authenticate into the SSH2 daemon? If so do I need to use the standard Auth and IDentification files or should I be using the server side .ssh directory with the authorized_keys file?

My best guess as to what is going wrong is that I don't have the client and server files in the right place to make this work.

If someone has the patience and could provide a quick step-by-step as to how they would accomplish the above task to ensure I've not overlooked some trivial part of the process it would be appreciated. I visited Stepwise and completed the setup found here http://www.stepwise.com/Articles/Wor...-12-17.01.html . Many thanks...

coitus
     
rantweasel
Dedicated MacNNer
Join Date: Oct 2001
Location: Philly
Status: Offline
Reply With Quote
Feb 5, 2002, 07:57 AM
 
Originally posted by coitus:
<STRONG>Setting up an OSX box to SSH into a freeBSD box running SSH2 Daemon (www.ssh2.org). The default for SSH2 is to have the Identification and the Authorization files in the .ssh2 directory in the ~ . Win SSH clients seem to work fine connecting to this box however for some reason the Mac running the open ssh client can't seem to connect.
</STRONG>
The first two things I would try would be connecting using a username/password login, just to make sure that there isn't a problem with the remote account, and also try "ssh -v" to get the verbose mode of ssh. That should point you in the direction of the error. What is the error message that you are getting? If you aren't getting an error message, what are you getting?
     
coitus  (op)
Forum Regular
Join Date: Aug 2000
Location: OKC, OK USA
Status: Offline
Reply With Quote
Feb 5, 2002, 12:39 PM
 
Here is the return, and much of this is greek to me...

xxx% ssh -v xxx.xxx.com
OpenSSH_3.0.2p1, SSH protocols 1.5/2.0, OpenSSL 0x0090602f
debug1: Reading configuration data /private/etc/ssh_config
debug1: Seeding random number generator
debug1: Rhosts Authentication disabled, originating port will not be trusted.
debug1: restore_uid
debug1: ssh_connect: getuid 0 geteuid 0 anon 1
debug1: Connecting to xxx.xxx.com [ip address] port 22.
debug1: restore_uid
debug1: restore_uid
debug1: Connection established.
debug1: read PEM private key done: type DSA
debug1: read PEM private key done: type RSA
debug1: identity file /Users/xxx/.ssh/identity type -1
debug1: identity file /Users/xxx/.ssh/id_rsa type -1
debug1: identity file /Users/xxx/.ssh/id_dsa type 2
debug1: Remote protocol version 1.99, remote software version 2.3.0 SSH Secure Shell (non-commercial)
debug1: match: 2.3.0 SSH Secure Shell (non-commercial) pat ^2\.[23]\.0
Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_3.0.2p1
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server-&gt;client 3des-cbc hmac-md5 none
debug1: kex: client-&gt;server 3des-cbc hmac-md5 none
debug1: dh_gen_key: priv key bits set: 198/384
debug1: bits set: 538/1024
debug1: sending SSH2_MSG_KEXDH_INIT
debug1: expecting SSH2_MSG_KEXDH_REPLY
debug1: Host 'xxx.xxxx.com' is known and matches the DSA host key.
debug1: Found key in /Users/xxx/.ssh/known_hosts:1
debug1: bits set: 521/1024
debug1: ssh_dss_verify: signature correct
debug1: kex_derive_keys
debug1: newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: waiting for SSH2_MSG_NEWKEYS
debug1: newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: done: ssh_kex2.
debug1: send SSH2_MSG_SERVICE_REQUEST
debug1: service_accept: ssh-userauth
debug1: got SSH2_MSG_SERVICE_ACCEPT
debug1: authentications that can continue: publickey
debug1: next auth method to try is publickey
debug1: try privkey: /Users/xxx/.ssh/identity
debug1: PEM_read_PrivateKey failed
debug1: read PEM private key done: type &lt;unknown&gt;
Enter passphrase for key '/Users/xxx/.ssh/identity':

Okay, I do know there is a firewall set up on the box I'm trying to connect to so there could possibly be a problem there or the keys may be in the wrong place. A buddy of mine (his bsd box) is helping work this out and anything technical I'll be forwarding on to him for a more intelligible response.

Additionally, could you tell me where the pub and private keys need to be stored (on both boxes)? I am thinking that perhaps it can't find one or the other on the remote box and that might be causing the problem. Then again, I'm very green on everything ssh.

Many thanks,

Curtis
     
bluehz
Dedicated MacNNer
Join Date: Feb 2001
Status: Offline
Reply With Quote
Feb 5, 2002, 08:49 PM
 
I have SSH runnig fine between my two internal LAN boxes. What I am wondering though - isn't SSH a lot like PGP in the sense that it is a two key system - on pub, one priv. Can I take my keys to another remote machine and use them the same way I could take my PGP keys with me? If so how do you do that?
     
   
 
Forum Links
Forum Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Top
Privacy Policy
All times are GMT -4. The time now is 04:14 PM.
All contents of these forums © 1995-2017 MacNN. All rights reserved.
Branding + Design: www.gesamtbild.com
vBulletin v.3.8.8 © 2000-2017, Jelsoft Enterprises Ltd.,