Static IP, now what?
October 26, 2005 2:41 PM Subscribe
File transfer question: How do I access my static IP addressed Mac at work from home? I have a Mac OSX box at work that with a router attached to my DSL modem. I can port forward if necessary. Basically what I'm looking to do is to transfer files from the office to home without having to constantly upload them to my iPod. Any suggestions?
A nice and secure way would be to activate Remote Login (ssh) in Sharing preferences on your Mac, then forward port 25 to it in your router config (only required if your work mac is using a NATted IP). From home, ssh to your mac at work. Use the Terminal or a separate SSH app such as Fugu and copy away.
posted by pmbuko at 2:54 PM on October 26, 2005
posted by pmbuko at 2:54 PM on October 26, 2005
Response by poster: My work mac is the one with the static IP how do I specify my home address? Would I not want to do this the other way?
posted by CCK at 2:55 PM on October 26, 2005
posted by CCK at 2:55 PM on October 26, 2005
one can turn on "remote login" in the sharing tab, which will start sshd. then you tell your router to forward port 22 on the router's external IP address to port 22 of the machine behind the firewall. then from your remote machine, ssh to your external ip and log in.
however, i would not reccomend only this as port 22 is of course a frequent target of ssh attacks. here's what i did:
1) move sshd to another port
edit /etc/services, change ssh to some port other than 22 (a high port, like in the 6000-7000 range or so)
note this will cause the ssh client on that machine to try to connect to your new port number on outgoing connections, so you need to do ssh -p 22 when going outbound from your home machine. there's probably a better way to do this that consists of creating a new service name in /etc/services on the new port and then making a new entry in /etc/xinetd.d/ with the same contents as /etc/xinetd.d/ssh, but i was too lazy.
2) generate a public/private key pair and turn off password-only authentication. see this. you need to change /etc/ssh_config to turn off password-only login. you can create a passphrase when creating the key if you want the added security of needing a password in addition to the public key.
3) bonus points: use dyndns.org to get a nice hostname for your home IP address.
posted by joeblough at 2:56 PM on October 26, 2005
however, i would not reccomend only this as port 22 is of course a frequent target of ssh attacks. here's what i did:
1) move sshd to another port
edit /etc/services, change ssh to some port other than 22 (a high port, like in the 6000-7000 range or so)
note this will cause the ssh client on that machine to try to connect to your new port number on outgoing connections, so you need to do ssh -p 22
2) generate a public/private key pair and turn off password-only authentication. see this. you need to change /etc/ssh_config to turn off password-only login. you can create a passphrase when creating the key if you want the added security of needing a password in addition to the public key.
3) bonus points: use dyndns.org to get a nice hostname for your home IP address.
posted by joeblough at 2:56 PM on October 26, 2005
one can turn on "remote login" in the sharing tab, which will start sshd. then you tell your router to forward port 22 on the router's external IP address to port 22 of the machine behind the firewall. then from your remote machine, ssh to your external ip and log in.
however, i would not reccomend only this as port 22 is of course a frequent target of ssh attacks. here's what i did:
1) move sshd to another port
edit /etc/services, change ssh to some port other than 22 (a high port, like in the 6000-7000 range or so)
note this will cause the ssh client on that machine to try to connect to your new port number on outgoing connections, so you need to do ssh -p 22 when going outbound from your home machine. there's probably a better way to do this that consists of creating a new service name in /etc/services on the new port and then making a new entry in /etc/xinetd.d/ with the same contents as /etc/xinetd.d/ssh, but i was too lazy.
2) generate a public/private key pair and turn off password-only authentication. see this. you need to change /etc/ssh_config to turn off password-only login. you can create a passphrase when creating the key if you want the added security of needing a password in addition to the public key.
3) bonus points: use dyndns.org to get a nice hostname for your home IP address.
then use scp to copy files.
posted by joeblough at 2:58 PM on October 26, 2005
however, i would not reccomend only this as port 22 is of course a frequent target of ssh attacks. here's what i did:
1) move sshd to another port
edit /etc/services, change ssh to some port other than 22 (a high port, like in the 6000-7000 range or so)
note this will cause the ssh client on that machine to try to connect to your new port number on outgoing connections, so you need to do ssh -p 22
2) generate a public/private key pair and turn off password-only authentication. see this. you need to change /etc/ssh_config to turn off password-only login. you can create a passphrase when creating the key if you want the added security of needing a password in addition to the public key.
3) bonus points: use dyndns.org to get a nice hostname for your home IP address.
then use scp to copy files.
posted by joeblough at 2:58 PM on October 26, 2005
whoops, sorry for the double post, jrun problems i guess.
please, please don't leave port 22 open. you're asking for trouble.
CCK, if you want to copy files from home to work, then yes, do all of this stuff on the work machine. i thought it was more common to be at work and want to pull something from home than the other way around. if you set up the work machine with sshd then you dont need to mess around with the port forwarding on the router, but i reiterate, i would change the port. they can always portscan you to find your alternate ssh server but a tad of security thru obscurity can't hurt. also you should disable passwords to eliminate dictionary attacks. i recently read on macintouch.com that someone with a very simple login/password pair found that their OSX box had been hacked in this manner.
posted by joeblough at 3:02 PM on October 26, 2005
please, please don't leave port 22 open. you're asking for trouble.
CCK, if you want to copy files from home to work, then yes, do all of this stuff on the work machine. i thought it was more common to be at work and want to pull something from home than the other way around. if you set up the work machine with sshd then you dont need to mess around with the port forwarding on the router, but i reiterate, i would change the port. they can always portscan you to find your alternate ssh server but a tad of security thru obscurity can't hurt. also you should disable passwords to eliminate dictionary attacks. i recently read on macintouch.com that someone with a very simple login/password pair found that their OSX box had been hacked in this manner.
posted by joeblough at 3:02 PM on October 26, 2005
If you're on a static IP with remote login (etc) enabled, make sure the password for each and every one of the accounts on your computer is secure and unguessable. You will be attacked.
posted by cillit bang at 3:15 PM on October 26, 2005
posted by cillit bang at 3:15 PM on October 26, 2005
Yeah, switch around my instructions so it says "work" where I wrote "home" and vice versa, I didn't read closely enough and just assumed you wanted to get access to your home machine from work.
Changing the ssh port and switching to public-key authentication is a good next step and definitely advisable, but get it working first. I've never actually used public-key authentication with a GUI SFTP client from a Mac, so I don't know how easy or difficult that'll be.
You may be able to change the ssh port by using the port forwarding features on the router (just redirect, say, port 2222 on the router to port 22 on the host and block port 22 at the router), this'll probably be easier than editing the config files you need to edit. Especially because on 10.4 (Tiger) you don't use the xinetd stuff anymore, you need to use launchd and that's a whole 'nother kettle of fish.
BTW, if you do edit /etc/services to change the ssh port, you can edit /etc/ssh_config and specify Port 22 so you won't need to specify -p on the command line all the time.
posted by kindall at 3:38 PM on October 26, 2005
Changing the ssh port and switching to public-key authentication is a good next step and definitely advisable, but get it working first. I've never actually used public-key authentication with a GUI SFTP client from a Mac, so I don't know how easy or difficult that'll be.
You may be able to change the ssh port by using the port forwarding features on the router (just redirect, say, port 2222 on the router to port 22 on the host and block port 22 at the router), this'll probably be easier than editing the config files you need to edit. Especially because on 10.4 (Tiger) you don't use the xinetd stuff anymore, you need to use launchd and that's a whole 'nother kettle of fish.
BTW, if you do edit /etc/services to change the ssh port, you can edit /etc/ssh_config and specify Port 22 so you won't need to specify -p on the command line all the time.
posted by kindall at 3:38 PM on October 26, 2005
Response by poster: can I ask why remote log in as opposed to the ftp service or personal file sharing?
posted by CCK at 3:44 PM on October 26, 2005
posted by CCK at 3:44 PM on October 26, 2005
personal file sharing == localtalk/AFP. its probably possible to forward ports to get that working across the internet, but i dont know what ports to forward. it might be restricted to a single subnet like Rendezvous (or Bonjour as its called now) since it relies on L2 broadcast/multicast packets.
ftp service... very insecure. ssh/scp uses strong encryption and can use alternate authentication mechanisms, unlike ftp.
kindall: my router couldnt to PAT (port address translation) and since its a linksys running the sveasoft firmware, i just figured that if it couldnt do it then it was unlikely that other home routers could. but it is a better solution if it works. didnt know launchd replaced xinetd. sigh.
posted by joeblough at 3:49 PM on October 26, 2005
ftp service... very insecure. ssh/scp uses strong encryption and can use alternate authentication mechanisms, unlike ftp.
kindall: my router couldnt to PAT (port address translation) and since its a linksys running the sveasoft firmware, i just figured that if it couldnt do it then it was unlikely that other home routers could. but it is a better solution if it works. didnt know launchd replaced xinetd. sigh.
posted by joeblough at 3:49 PM on October 26, 2005
Response by poster: is there any way to limit access to just the public folder, in case someone tries to hack the work comp? Thats why the personal file sharing appealled to me.
posted by CCK at 3:59 PM on October 26, 2005
posted by CCK at 3:59 PM on October 26, 2005
public folder: not that i know of. ssh (and scp by extension) are remote login protocols and when you log in via ssh as user X, you have permission to access whatever user X has permission for when sitting at the console.
you could establish a 2nd account which is not your own and ssh to that account. having said that there are lots of security exploits where an attacker first gains access to a user level account, and then by taking advantage of a bug in some system-level service (and there are many services), is able to escalate to root privledges (administrator) and then they can do pretty much whatever they want to do. like installing new versions of unix utilities that you could otherwise use to detect the intrusion.
perhaps you can tunnel AFP over ssh, the other thread linked to here mentions that. i've never tried that. that's assuming that AFP really does securely limit remote access to the public folder, i dont know.
posted by joeblough at 4:30 PM on October 26, 2005
you could establish a 2nd account which is not your own and ssh to that account. having said that there are lots of security exploits where an attacker first gains access to a user level account, and then by taking advantage of a bug in some system-level service (and there are many services), is able to escalate to root privledges (administrator) and then they can do pretty much whatever they want to do. like installing new versions of unix utilities that you could otherwise use to detect the intrusion.
perhaps you can tunnel AFP over ssh, the other thread linked to here mentions that. i've never tried that. that's assuming that AFP really does securely limit remote access to the public folder, i dont know.
posted by joeblough at 4:30 PM on October 26, 2005
Yeah, you should be able to tunnel AFP or SMB over SSH and get an actual mounted volume if you want that.
posted by kindall at 5:13 PM on October 26, 2005
posted by kindall at 5:13 PM on October 26, 2005
please, please don't leave port 22 open. you're asking for trouble.
Not if your SSH server is worth a damn. I'm guessing (without having it) that OSX uses OpenSSH, which quite a bit of the world runs very securely. Plus, although access to a guest or regular user account is bad, unix systems are built on the idea that anyone can view everything (or mostly everything) and the system can still be secure. Your computer won't not boot up, and your monitor won't explode because someone gets shell access under a restricted account. That's the joy of unix.
posted by devilsbrigade at 6:24 PM on October 26, 2005
Not if your SSH server is worth a damn. I'm guessing (without having it) that OSX uses OpenSSH, which quite a bit of the world runs very securely. Plus, although access to a guest or regular user account is bad, unix systems are built on the idea that anyone can view everything (or mostly everything) and the system can still be secure. Your computer won't not boot up, and your monitor won't explode because someone gets shell access under a restricted account. That's the joy of unix.
posted by devilsbrigade at 6:24 PM on October 26, 2005
To answer the question: First I'd see if there's a VPN set up for work, or any way to set up a VPN. They're very, very nice things. That would let you mount a similar network share on your machine at home and your machine at work, with the data stored at work. Then, at home, just drag & drop.
Barring that, the other 300+ answers have it ;)
posted by devilsbrigade at 6:26 PM on October 26, 2005
Barring that, the other 300+ answers have it ;)
posted by devilsbrigade at 6:26 PM on October 26, 2005
The bit about moving ssh off of port 22 is somewhat bunk.
What people commonly refer to as "ssh attacks" hardly are deserving of the word "attack". All that happens is you will get lots of attempts to log in using a fixed set of default usernames with terrible passwords, like "test/test", "admin/123", whatever.
The ONLY way this would affect you would be if you picked a ridiculously stupid login name and password, like the guy's luggage in Spaceballs. And if that's the case you need to pick a better password - moving ssh to another port doesn't solve the problem, it just tries to cover it up and hope that no one happens to stumble on the new port. You need to solve the actual problem of shitty passwords.
So essentially these people that get worked up over "ssh attacks" just really don't know how to ignore log files. EVERYBODY gets them, and they are initiated by mass automated scripts. It is NOT some sweaty balding hacker d00d trying to personally break into your system. You are not a unique little snowflake, nobody is targeting you. Think of it as just part of the standard background noise of TCP/IP these days, and ignore it.
Getting worked up over a bunch of FAILED logins is nonsense. Again: if you have bad passwords you need to rectify the situation, not try to pretend it doesn't exist by moving ssh to another port. And if you have even slightly decent passwords, you are completely immune to these attacks.
The only POSSIBLE reason that these attacks would be of any concern is if they hammer the hell out of your system fast enough to cause a noticeable use of resources. And unless you're running a 386 from 1994 or your system is configured very poorly, the rate of connections will be nowhere close to saturating anything.
I'm sure somebody will say "but moving to a nonstandard port doesn't cost anything, and it saves me having to ignore a bunch of crap in my logfiles." To that I say, it's not buying you sqaut in terms of real security, and if the log files bother you don't look at them. They will be rotated anyway so they won't pile up and take up space. And you save the bother of having to specify a port number when you ssh in.
posted by Rhomboid at 6:45 AM on October 27, 2005
What people commonly refer to as "ssh attacks" hardly are deserving of the word "attack". All that happens is you will get lots of attempts to log in using a fixed set of default usernames with terrible passwords, like "test/test", "admin/123", whatever.
The ONLY way this would affect you would be if you picked a ridiculously stupid login name and password, like the guy's luggage in Spaceballs. And if that's the case you need to pick a better password - moving ssh to another port doesn't solve the problem, it just tries to cover it up and hope that no one happens to stumble on the new port. You need to solve the actual problem of shitty passwords.
So essentially these people that get worked up over "ssh attacks" just really don't know how to ignore log files. EVERYBODY gets them, and they are initiated by mass automated scripts. It is NOT some sweaty balding hacker d00d trying to personally break into your system. You are not a unique little snowflake, nobody is targeting you. Think of it as just part of the standard background noise of TCP/IP these days, and ignore it.
Getting worked up over a bunch of FAILED logins is nonsense. Again: if you have bad passwords you need to rectify the situation, not try to pretend it doesn't exist by moving ssh to another port. And if you have even slightly decent passwords, you are completely immune to these attacks.
The only POSSIBLE reason that these attacks would be of any concern is if they hammer the hell out of your system fast enough to cause a noticeable use of resources. And unless you're running a 386 from 1994 or your system is configured very poorly, the rate of connections will be nowhere close to saturating anything.
I'm sure somebody will say "but moving to a nonstandard port doesn't cost anything, and it saves me having to ignore a bunch of crap in my logfiles." To that I say, it's not buying you sqaut in terms of real security, and if the log files bother you don't look at them. They will be rotated anyway so they won't pile up and take up space. And you save the bother of having to specify a port number when you ssh in.
posted by Rhomboid at 6:45 AM on October 27, 2005
Your computer won't not boot up, and your monitor won't explode because someone gets shell access under a restricted account.
No, but your Internet access will get cut off for all the spam your machine will be sending.
Again: if you have bad passwords you need to rectify the situation, not try to pretend it doesn't exist by moving ssh to another port.
This is easy when you're the only person using the machine. Not always so easy when others use it.
Changing the port number does have one big advantage. A lot of the scripts first try to connect to port 22. If they can't connect, they may assume your machine's not there and pass you by with the other crud they try to do. I think that can be worthwhile. It doesn't "really" buy you any security in that if your box is vulnerable in some way you can still be broken into, but statistically, you're less likely to be successfully attacked because most attackers won't notice you.
If you configure your router to drop port 22 entirely (rather than returning a nice, polite, TCP rejection message) then scripts that attack ssh will sit there trying until they time out, which delays the script's progress. This may be considered a genuine public service.
posted by kindall at 8:41 AM on October 27, 2005
No, but your Internet access will get cut off for all the spam your machine will be sending.
Again: if you have bad passwords you need to rectify the situation, not try to pretend it doesn't exist by moving ssh to another port.
This is easy when you're the only person using the machine. Not always so easy when others use it.
Changing the port number does have one big advantage. A lot of the scripts first try to connect to port 22. If they can't connect, they may assume your machine's not there and pass you by with the other crud they try to do. I think that can be worthwhile. It doesn't "really" buy you any security in that if your box is vulnerable in some way you can still be broken into, but statistically, you're less likely to be successfully attacked because most attackers won't notice you.
If you configure your router to drop port 22 entirely (rather than returning a nice, polite, TCP rejection message) then scripts that attack ssh will sit there trying until they time out, which delays the script's progress. This may be considered a genuine public service.
posted by kindall at 8:41 AM on October 27, 2005
Plus, if you do like joeblough's point 2 says (use keys for ssh authentication and turn off password based authentication altogether) it doesn't matter if your passwords ARE crap.
posted by flabdablet at 8:54 AM on October 27, 2005
posted by flabdablet at 8:54 AM on October 27, 2005
but.. but... i am a unique little snowflake!
i suggested the port change not because i thought CCK didnt want to bother with "polluted" logs but because of the reasons that kindall enumerates.
devilsbrigade: as i mentioned, there are loads of root-escalation bugs all over the place, even on OSX, and there have certainly been bugs in OpenSSH. if you don't keep your machine current with all the security updates, then you can be vulnerable to these attacks. you are being lulled into a false sense of security by the "beauty of unix"...
posted by joeblough at 4:13 PM on October 27, 2005
i suggested the port change not because i thought CCK didnt want to bother with "polluted" logs but because of the reasons that kindall enumerates.
devilsbrigade: as i mentioned, there are loads of root-escalation bugs all over the place, even on OSX, and there have certainly been bugs in OpenSSH. if you don't keep your machine current with all the security updates, then you can be vulnerable to these attacks. you are being lulled into a false sense of security by the "beauty of unix"...
posted by joeblough at 4:13 PM on October 27, 2005
joeblough: OpenSSH is very proactive about fixing bugs. "Only one remote hole in the default install, in more than 8 years!" for OpenBSD includes OpenSSH. If you're current, you're fine. Its not *that* hard to stay current if you have a small subset of programs.
Depending on your machine/OS, there are a certain number of root escalation bugs, but a) there's a reason tons of servers get away with giving out hundreds of shell accounts (including universities/etc), and b) these tend to get noticed/dealt with fairly quickly.
posted by devilsbrigade at 10:25 AM on October 28, 2005
Depending on your machine/OS, there are a certain number of root escalation bugs, but a) there's a reason tons of servers get away with giving out hundreds of shell accounts (including universities/etc), and b) these tend to get noticed/dealt with fairly quickly.
posted by devilsbrigade at 10:25 AM on October 28, 2005
I guess it comes down to a personal choice. If you're like me, you use RSA public keys and have passwords disabled; I could care less that some guy running a scan from a rooted PC in a korean kindergarten tries to log on as "test/pass" and fails repeatedly. On the other hand, moving to a different port does tend to reduce the chances of having a problem, but only if your password hygeine sucks already. The cliche is "security by obscurity is not real security", but most people agree that that refers to "security [only] by obscurity". Or in other words, obscurity can be helpful to reduce risk, but it should not be relied on as a sole defence. Personally, if it were me, I would sleep a lot better at night knowing for sure that I had used secure passwords than I would knowing that I had only moved ssh to another port.
posted by Rhomboid at 11:54 PM on October 28, 2005
posted by Rhomboid at 11:54 PM on October 28, 2005
This thread is closed to new comments.
posted by kindall at 2:44 PM on October 26, 2005