ssh connection via alternate port closed immediately after logging in

Question

Level 1

0 points

ssh connection via alternate port closed immediately after logging in

Hello all,

I am having the following issue. I can successfully ssh into my Mac using the default port (22). However, when I try connecting using a different port (e.g. 1234) as soon as I log in (after entering my password) the connection is closed.

The only way I am able to get sshd to listen on an alternate port is to issue the sudo /usr/sbin/sshd -p [port] command—editing /etc/sshd_config was futile, as well as any attempts to port forward using ipfw. So once I issue that command, I can type ssh username@localip -p 1234

I believe at one point I had been able to establish an ssh connection via the alternate port, but I probably messed something up when playing around with the config files. I kept backup copies of config files (e.g. sshd_config) so all defaults should be restored and file permissions should be correct. I've tried disabling PAM authentication but have been able to since editing sshd_config doesn't seem to affect or change anything.

Any help with getting this working will be greatly appreciated. If not, what would be the best way to reinstall the ssh daemon on Leopard?

Following is an excerpt of my secure.log and system.log when attempting to ssh via the alternate port:

secure.log:
Jun 24 22:28:24 Macintosh sshd[9677]: Accepted keyboard-interactive/pam for felipe from 10.0.1.199 port 56204 ssh2
Jun 24 22:28:24 Macintosh sshd[9682]: error: PAM: pam opensession(): Cannot make/remove an entry for the specified session

system.log:
Jun 24 22:28:24 Macintosh com.apple.launchd[1] (com.apple.launchd.peruser.501[107]): Root Mach bootstrap cannot be transferred.
Jun 24 22:28:24 Macintosh com.apple.launchd[107] (0x10de00.sshd[9682]): Bug: launchd corelogic.c:6244 (23585):1100: kr == 0
Jun 24 22:28:24 Macintosh sshd[9677]: USER_PROCESS: 9682 ttys002
Jun 24 22:28:24 Macintosh sshd[9677]: DEAD_PROCESS: 9682 ttys002

And below is a transcript of an ssh connection in triple verbose mode (-vvv) after the password has been input (I've bolded where I believe the issue starts):
debug2: input userauth_inforeq: num_prompts 1
Password:
debug3: packet_send2: adding 32 (len 24 padlen 8 extra_pad 64)
debug2: input userauth_inforeq
debug2: input userauth_inforeq: num_prompts 0
debug3: packet_send2: adding 48 (len 10 padlen 6 extra_pad 64)
debug1: Authentication succeeded (keyboard-interactive).
debug1: channel 0: new [client-session]
debug3: ssh session2open: channel_new: 0
debug2: channel 0: send open
debug1: Entering interactive session.
debug2: callback start
debug2: client session2setup: id 0
debug2: channel 0: request pty-req confirm 0
debug3: tty makemodes: ospeed 9600
debug3: tty makemodes: ispeed 9600
debug3: tty makemodes: 1 3
debug3: tty makemodes: 2 28
debug3: tty makemodes: 3 127
debug3: tty makemodes: 4 21
debug3: tty makemodes: 5 4
debug3: tty makemodes: 6 255
debug3: tty makemodes: 7 255
debug3: tty makemodes: 8 17
debug3: tty makemodes: 9 19
debug3: tty makemodes: 10 26
debug3: tty makemodes: 11 25
debug3: tty makemodes: 12 18
debug3: tty makemodes: 13 23
debug3: tty makemodes: 14 22
debug3: tty makemodes: 17 20
debug3: tty makemodes: 18 15
debug3: tty makemodes: 30 0
debug3: tty makemodes: 31 0
debug3: tty makemodes: 32 0
debug3: tty makemodes: 33 0
debug3: tty makemodes: 34 0
debug3: tty makemodes: 35 0
debug3: tty makemodes: 36 1
debug3: tty makemodes: 38 1
debug3: tty makemodes: 39 1
debug3: tty makemodes: 40 0
debug3: tty makemodes: 41 1
debug3: tty makemodes: 50 1
debug3: tty makemodes: 51 1
debug3: tty makemodes: 53 1
debug3: tty makemodes: 54 1
debug3: tty makemodes: 55 0
debug3: tty makemodes: 56 0
debug3: tty makemodes: 57 0
debug3: tty makemodes: 58 0
debug3: tty makemodes: 59 1
debug3: tty makemodes: 60 1
debug3: tty makemodes: 61 1
debug3: tty makemodes: 62 1
debug3: tty makemodes: 70 1
debug3: tty makemodes: 72 1
debug3: tty makemodes: 73 0
debug3: tty makemodes: 74 0
debug3: tty makemodes: 75 0
debug3: tty makemodes: 90 1
debug3: tty makemodes: 91 1
debug3: tty makemodes: 92 0
debug3: tty makemodes: 93 0
debug2: channel 0: request shell confirm 0
debug2: fd 3 setting TCP_NODELAY
debug2: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768
debug2: channel 0: rcvd adjust 2097152
Last login: Tue Jun 24 23:24:20 2008 from 10.0.1.199
*debug2: channel 0: rcvd eof*
debug2: channel 0: output open -> drain
debug2: channel 0: obuf empty
debug2: channel 0: close_write
debug2: channel 0: output drain -> closed
debug1: client input_channelreq: channel 0 rtype exit-status reply 0
debug2: channel 0: rcvd close
debug2: channel 0: close_read
debug2: channel 0: input open -> closed
debug3: channel 0: will not send data after close
debug2: channel 0: almost dead
debug2: channel 0: gc: notify user
debug2: channel 0: gc: user detached
debug2: channel 0: send close
debug2: channel 0: is dead
debug2: channel 0: garbage collecting
debug1: channel 0: free: client-session, nchannels 1
debug3: channel 0: status: The following connections are open:
#0 client-session (t4 r0 i3/0 o3/0 fd -1/-1 cfd -1)

debug3: channel 0: close_fds r -1 w -1 e 6 c -1
Connection to 10.0.1.199 closed.
debug1: Transferred: stdin 0, stdout 0, stderr 34 bytes in 0.0 seconds
debug1: Bytes per second: stdin 0.0, stdout 0.0, stderr 2902.8
debug1: Exit status 254

iMac 6.1, Mac OS X (10.5.3)

Posted on Jun 24, 2008 8:33 PM

Reply

Answer 1

felideon Author

Level 1

0 points

Jun 24, 2008 8:37 PM in response to felideon

I also had read through this post:

http://discussions.apple.com/thread.jspa?messageID=7263765

I do not have any initialization file that would kick me off as soon as I logged in.

Reply

Answer 2

j.v.

Level 5

4,155 points

Jun 25, 2008 8:05 AM in response to felideon

I had run across some information from somewhere online about this once a long time ago. I no longer remember from where I obtained it, so I cannot give proper source citation where credit is due. I consolidated that information to write up my own custom cookbook procedure in case I suffered a serious crash and had to rebuild from scratch.

I successfully implemented this on a Tiger machine. The directions below are Tiger-specific. I do not know if it will work on Leo or not.

I would preface it by saying that the easy way to do this would be, if your home broadband modem/router allows you to cross-strap ports, then I would just map external WAN port 2222 (for example) to internal (W)LAN port 22, so as to minimize internal modifications to your computer's unix stuff. However, if your modem does not have that functionality, you can try this and see if these Tiger-specific directions will work for you on Leopard.

The one thing that I couldn't readily identify you having reported as having tried, was my steps #5 and #6.

1. make a backup of the original /etc/sshd_config

2. Insert a line into /etc/sshd_config just below the line that reads "#Port 22" specifying the alternate port number:
Port 2222

3. Make a backup of the original /etc/services

4. add a two new entries to /etc/services:
ssh-alt 2222/udp # SSH Remote Login on non-standard port
ssh-alt 2222/tcp # SSH Remote Login on non-standard port

5. copy /System/Library/LaunchDaemons/ssh.plist to a new name, like /System/Library/LaunchDaemons/ssh-alt.plist

6. modify /System/Library/LaunchDaemons/ssh-alt.plist:
change the Label to something different:
<key>Label</key>
<string>com.openssh.sshd-alt</string>
and change the SockServiceName:
<key>SockServiceName</key>
<string>ssh-alt</string>

7.  --> System Preferences --> Sharing --> Firewall --> create new:
Port Name: Other
TCP Port Number(s): 2222
UDP Port Number(s): 2222
Description: ssh-alt

8. make sure that these new files' (that you have created in #2, #4, and #6, above) ownerships, group affiliations, and permissions match the originals

9. reboot

10. As I recall, you may have to remove ~/.ssh/known_hosts from all user accounts on remote client computers, or when they try to connect, they will get a "man in the middle" nastygram and will be prevented from connecting.

11. all remote clients then login "ssh -p 2222 username@host"

Hope this helps!

Reply

Answer 3

felideon Author

Level 1

0 points

Jun 25, 2008 3:12 PM in response to j.v.

Thanks for the quick response.

Do you think your step #7 is necessary?

That's one step I haven't been able to do Leopard. For one, the Firewall tab is now located under System Preferences -> Security. Furthermore, it seems like you can only add Applications (not ports) to the exceptions.

I do recall reading all those steps somewhere but never actually tried them. It seems like a better solution to begin with, and hopefully it will prevent the pam opensession error.

Reply

Answer 4

j.v.

Level 5

4,155 points

Jun 25, 2008 3:24 PM in response to felideon

I am not 100% sure of this, but it seemed that clicking on a checkbox in Tiger's Sharing's Firewall enabled the service and opened the port. So #7 was required. With Leo's new way of doing things in the Firewall pane, I am not sure how to add an application like "ssh-alt" that you can only see in their GUI window, or how to add it into their Sharing port/service list. I think that even though the ssh-alt.plist would get the service started up, you need to open up the port so people can take advantage of the service. You may need to mess with ipfw to add a rule to allow it.

Reply

Answer 5

felideon Author

Level 1

0 points

Jun 25, 2008 4:09 PM in response to j.v.

If forwarding ports in ipfw would work to begin with, I wouldn't be in this situation! (Kind of like how Linux users would use iptables.)

But maybe opening ports through ipfw will work, because I do think I managed to do that at one point (noticed in port scan in Network Utility).

It's so time-consuming to find out what works in a pure FreeBSD system and what doesn't in Mac OS X.

Regardless, the real question is why my ssh connection is being closed as soon as I log in (on an alternate port).

Reply

Answer 6

orangekay

Level 5

4,085 points

Jun 25, 2008 5:12 PM in response to felideon

Did you add anything to ~/.ssh/config at any point?

Reply

Answer 7

j.v.

Level 5

4,155 points

Jun 25, 2008 5:20 PM in response to orangekay

wouldn't any additions/modifications there only be of use if it were the remote client?

Reply

Answer 8

j.v.

Level 5

4,155 points

Jun 25, 2008 5:27 PM in response to felideon

That I can't say, I'm probably out of my league at this point. One would think if the port were closed that the connection wouldn't get that far along in its establishment attempt.

I wasn't suggesting forwarding ports in ipfw, but rather just making a rule in ipfw to allow any tcp in port 2222.

However, it may be that cross-mapping the port in your home router may be the better solution, if you can do it. My particular combo modem/router/WAP, which is the standard issue modem that my DSL provider rents to its customers, has enough smarts in it that it can forward ports to dynamic LAN IP addresses and not be limited to strictly forwarding ports only to static LAN IP addresses, and it can cross-strap external WAN ports to different-numbered internal LAN ports, too. Furthermore (and this is really sweet), regardless of whether an itinerant laptop is affiliated to my home WLAN or affiliated to some "foreign" WLAN at the local internet café, I can "ssh -p 2222" to my dyndns host name, inside or outside, and still get into my ssh server on its standard port 22, whether I am inside or outside my WLAN.

My old modem didn't do all that cool stuff, it was port-forward to static LAN addresses only, I couldn't cross-strap external-to-internal ports, and I couldn't ssh to my own dyndns host name. So I had to go through all those hoops with the ssh-alt.plist and such. But now that I can do all these things in the modem/router/WAP, I've elected to return the ssh server computer back to its OEM state.

At any rate, I don't think I can really be of any help to you beyond what I've suggested here and in my previous post. I hope some of it you find helpful; but what would be better yet, would be if someone else reports in here with a truly elegant solution for you (which I would love to read about myself). That would be most awesome. Besides, at least in Tiger, messin' with ipfw grayed out the Mac's Sys Prefs' Firewall and there is a certain convenience to being able to handle that with checkboxes.

Good luck to you in resolving this, and sorry I couldn't have been more helpful.

Reply

Answer 9

felideon Author

Level 1

0 points

Jun 25, 2008 8:29 PM in response to j.v.

Yeah, thx for trying to help. I was just telling my side story of ipfw.

And I forgot to comment on what you suggested regarding cross-mapping ports on at the router level. I would have done that as well to begin with, but unfortunately the Airport Extreme (which I bought for better usability with the Mac--go figure the irony) doesn't allow. I can only port forward to local IP on the network.

Thanks for your suggestions. I haven't been able to solve the issue but they have helped a bit in understanding all this.

Reply

Answer 10

felideon Author

Level 1

0 points

Jun 25, 2008 8:39 PM in response to orangekay

No I haven't. There's just known_hosts in there and I haven't modified that.

Reply

Answer 11

felideon Author

Level 1

0 points

Jun 26, 2008 3:00 PM in response to felideon

Actually, now that I remember, I did put something in there at one point, but I've since deleted it.

One tutorial I followed was:

http://hkn.eecs.berkeley.edu/~dhsu/sshpublic_keyhowto.html

You'll see there's a line that says "Copy the public key to ~/.ssh/daniel.pub on the remote host using any file-transfer program."

Did that cause an issue? How would I fix it?

Message was edited by: felideon

Reply

Answer 12

felideon Author

Level 1

0 points

Jun 30, 2008 9:40 AM in response to orangekay

orangekay,

I was wondering if you had any idea what the problem could be, based on your question. As I mentioned, I did actually put something in that directory at some point.

Thanks in advanced.

Reply

Answer 13

felideon Author

Level 1

0 points

Jul 3, 2008 6:41 PM in response to j.v.

So I finally ended up doing it "the apple way" which was the method you mentioned. I only did steps 4-6 though and it worked fine after a launchctl load.

Reply