My SSH is set up to work via a key only i.e. no logins.
I can use SSH from my laptop to connect to my desktop over my home network with no problems however if I try it via the Internet, when away from home, I get 'access denied (Publickey)'.
Would there be a known reason for that?
On Sun, Aug 31, 2008 at 09:07:30PM +0100, Barry Samuels wrote:
My SSH is set up to work via a key only i.e. no logins.
I can use SSH from my laptop to connect to my desktop over my home network with no problems however if I try it via the Internet, when away from home, I get 'access denied (Publickey)'.
Would there be a known reason for that?
Is it possibly that your router isn't allowing the ssh packets through?
Or is the ssh server set up to allow only connections from the local network?
Or (and I think this *is* probably the answer) does your laptop have a different address when connecting from 'outside'? The ssh keys you have set up allow connections from specific hosts so a connection set up that works when the laptop has a local IP address will not work when the laptop has an IP address given to it by some other network.
On 31 Aug 21:18, Chris G wrote:
On Sun, Aug 31, 2008 at 09:07:30PM +0100, Barry Samuels wrote:
My SSH is set up to work via a key only i.e. no logins.
I can use SSH from my laptop to connect to my desktop over my home network with no problems however if I try it via the Internet, when away from home, I get 'access denied (Publickey)'.
Would there be a known reason for that?
Is it possibly that your router isn't allowing the ssh packets through?
That would be a different message, such as connection denied or connection timedout.
Or is the ssh server set up to allow only connections from the local network?
See above.
Or (and I think this *is* probably the answer) does your laptop have a different address when connecting from 'outside'? The ssh keys you have set up allow connections from specific hosts so a connection set up that works when the laptop has a local IP address will not work when the laptop has an IP address given to it by some other network.
Very unlikely to be the answer. Infact, incredibly unlikely. Given that I do just that rather often from this laptop, heck, I even tunnel other ssh connections through ssh connections that use that from this laptop.
Now, the correct questions to ask would be: * Have you checked the backend of the auth.log on the server * Have you tried running ssh with the -vvvv option to get lots of shiny debug output * Is this the same laptop both inside and outside the network * Have you got a special ~/.ssh/config entry for that desktop
With that we might be able to give a slightly better answer and not stab around in the dark.
Thanks,
On 31/08/08 21:30:28, Brett Parker wrote:
Now, the correct questions to ask would be: * Have you checked the backend of the auth.log on the server
I don't understand that. What is the backend? If you mean /var/log/ auth.log there is nothing in there relating to SSH.
* Have you tried running ssh with the -vvvv option to get lots of shiny debug output
No. I had forgotten to do that. As I'm testing at the moment via my neighbours router I'll have to wait until tomorrow evening to retry.
* Is this the same laptop both inside and outside the network
Yes the very same.
* Have you got a special ~/.ssh/config entry for that desktop
I don't understand that either. What sort of 'special' entry? I have the following files in ~/.ssh on the server (desktop):
authorized_keys identity.pub id_rsa.pub identity id_rsa known_hosts
With that we might be able to give a slightly better answer and not stab around in the dark.
Thanks for the help.
On 31 Aug 22:11, Barry Samuels wrote:
On 31/08/08 21:30:28, Brett Parker wrote:
Now, the correct questions to ask would be: * Have you checked the backend of the auth.log on the server
I don't understand that. What is the backend? If you mean /var/log/ auth.log there is nothing in there relating to SSH.
Probably worth checking /var/log/daemon.log then.
* Have you tried running ssh with the -vvvv option to get lots of shiny debug outputNo. I had forgotten to do that. As I'm testing at the moment via my neighbours router I'll have to wait until tomorrow evening to retry.
* Is this the same laptop both inside and outside the networkYes the very same.
* Have you got a special ~/.ssh/config entry for that desktopI don't understand that either. What sort of 'special' entry? I have the following files in ~/.ssh on the server (desktop):
authorized_keys identity.pub id_rsa.pub identity id_rsa known_hosts
OK - you haven't got a ~/.ssh/config file, so you haven't got a special entry for that machine ;) i.e. it'll fall back to defaults and most likely use id_rsa for identification. Which distribution?
But, certainly, I'd do the ssh -vvvv and make sure that you're definately connecting to the same machine when in and outside the network, there's a small possibility that you have your router doing NAT to the wrong machine, but not knowing your network, that's impossible to say ;)
Cheers,
On 31/08/08 21:18:21, Chris G wrote:
On Sun, Aug 31, 2008 at 09:07:30PM +0100, Barry Samuels wrote:
My SSH is set up to work via a key only i.e. no logins.
I can use SSH from my laptop to connect to my desktop over my home network with no problems however if I try it via the Internet, when away from home, I get 'access denied (Publickey)'.
Would there be a known reason for that?
Is it possibly that your router isn't allowing the ssh packets through?
I have been able to rule that out. The error message is coming from SSH which means the connection is getting passed the firewall.
Or is the ssh server set up to allow only connections from the local network?
I didn't know that there was such an option.
Or (and I think this *is* probably the answer) does your laptop have a different address when connecting from 'outside'?
Almost certainly.
The ssh keys you have set up allow connections from specific hosts so a connection set up that works when the laptop has a local IP address will not work when the laptop has an IP address given to it by some other network.
So if one is travelling and staying in a hotel with wifi facilities then connection via SSH is not possible. Is that true?
On 31 Aug 21:40, Barry Samuels wrote:
On 31/08/08 21:18:21, Chris G wrote:
On Sun, Aug 31, 2008 at 09:07:30PM +0100, Barry Samuels wrote:
My SSH is set up to work via a key only i.e. no logins.
I can use SSH from my laptop to connect to my desktop over my home network with no problems however if I try it via the Internet, when away from home, I get 'access denied (Publickey)'.
Would there be a known reason for that?
Is it possibly that your router isn't allowing the ssh packets through?
I have been able to rule that out. The error message is coming from SSH which means the connection is getting passed the firewall.
Or is the ssh server set up to allow only connections from the local network?
I didn't know that there was such an option.
Or (and I think this *is* probably the answer) does your laptop have a different address when connecting from 'outside'?
Almost certainly.
The ssh keys you have set up allow connections from specific hosts so a connection set up that works when the laptop has a local IP address will not work when the laptop has an IP address given to it by some other network.
So if one is travelling and staying in a hotel with wifi facilities then connection via SSH is not possible. Is that true?
No, ChrisG is talking out of his arse. If that was the case then my laptop would be useless for managing our servers as it's used both in and outside the office and has been connected via various wifi points and 3G depending on the situation - ssh is for remote connections, it would be totally crazy for that to be the situation.
See my other post.
Cheers,
On Sun, Aug 31, 2008 at 09:48:33PM +0100, Brett Parker wrote:
On 31 Aug 21:40, Barry Samuels wrote:
On 31/08/08 21:18:21, Chris G wrote:
On Sun, Aug 31, 2008 at 09:07:30PM +0100, Barry Samuels wrote:
My SSH is set up to work via a key only i.e. no logins.
I can use SSH from my laptop to connect to my desktop over my home network with no problems however if I try it via the Internet, when away from home, I get 'access denied (Publickey)'.
Would there be a known reason for that?
Is it possibly that your router isn't allowing the ssh packets through?
I have been able to rule that out. The error message is coming from SSH which means the connection is getting passed the firewall.
Or is the ssh server set up to allow only connections from the local network?
I didn't know that there was such an option.
Or (and I think this *is* probably the answer) does your laptop have a different address when connecting from 'outside'?
Almost certainly.
The ssh keys you have set up allow connections from specific hosts so a connection set up that works when the laptop has a local IP address will not work when the laptop has an IP address given to it by some other network.
So if one is travelling and staying in a hotel with wifi facilities then connection via SSH is not possible. Is that true?
No, ChrisG is talking out of his arse. If that was the case then my laptop would be useless for managing our servers as it's used both in and outside the office and has been connected via various wifi points and 3G depending on the situation - ssh is for remote connections, it would be totally crazy for that to be the situation.
I don't believe I am, not entirely. If I am talking rubbish then why do I have entries in my ~/.ssh/authorized_keys file which relate to specific remote clients? Each one of the entries in authorized_keys is for a specific remote host that I connect from.
You can connect with ssh using *password* authentication from anywhere but using public key authentication I think ssh needs to verify that the client is the host expected.
On Sun, Aug 31, 2008 at 10:17:55PM +0100, Chris G wrote:
You can connect with ssh using *password* authentication from anywhere but using public key authentication I think ssh needs to verify that the client is the host expected.
By default an SSH public key works from anywhere. You *can* tie it down with 'from="pattern-list"' to only allow a key to be used from specific host(s), but without that all the distros/OSes I've used seem to default to access from anywhere.
J.
On Sun, Aug 31, 2008 at 10:26:32PM +0100, Jonathan McDowell wrote:
On Sun, Aug 31, 2008 at 10:17:55PM +0100, Chris G wrote:
You can connect with ssh using *password* authentication from anywhere but using public key authentication I think ssh needs to verify that the client is the host expected.
By default an SSH public key works from anywhere. You *can* tie it down with 'from="pattern-list"' to only allow a key to be used from specific host(s), but without that all the distros/OSes I've used seem to default to access from anywhere.
I'm confused but I have also just tried an experiment.
I have connected out to a system where I have a login which I haven't used for a very long time.
When I connected from my home system (key not changed in a long time) to the remote system I got the following:-
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! Someone could be eavesdropping on you right now (man-in-the-middle attack)! It is also possible that the RSA host key has just been changed. The fingerprint for the RSA key sent by the remote host is b2:a3:b7:0a:0e:c0:d3:5c:2a:b3:69:bb:50:47:13:4e. Please contact your system administrator. Add correct host key in /home/chris/.ssh/known_hosts to get rid of this message. Offending key in /home/chris/.ssh/known_hosts:9 RSA host key for cheddar.halon.org.uk has changed and you have requested strict checking. Host key verification failed.
OK, that's not a surprise as the remote system has changed it's key since I last connected.
I then fixed the above problem by removing the remote system's entry from my /home/chris/.ssh/known_hosts, then I logged in successfully with the following warning:-
The authenticity of host 'cheddar.halon.org.uk (195.177.253.180)' can't be established. RSA key fingerprint is b2:a3:b7:0a:0e:c0:d3:5c:2a:b3:69:bb:50:47:13:4e. Are you sure you want to continue connecting (yes/no)? yes
... and logged in successfully.
*Then* I tried logging in back from the remote system to my home system, it just asked for my password, no public key authentication happened at all. I.e. it's *only* from systems listed in my authorized_keys file that public key authentication will happen, otherwise (if it's allowed) you just get password authentication.
Chris G wrote:
On Sun, Aug 31, 2008 at 10:26:32PM +0100, Jonathan McDowell wrote:
On Sun, Aug 31, 2008 at 10:17:55PM +0100, Chris G wrote:
You can connect with ssh using *password* authentication from anywhere but using public key authentication I think ssh needs to verify that the client is the host expected.
By default an SSH public key works from anywhere. You *can* tie it down with 'from="pattern-list"' to only allow a key to be used from specific host(s), but without that all the distros/OSes I've used seem to default to access from anywhere.
I'm confused but I have also just tried an experiment.
I have connected out to a system where I have a login which I haven't used for a very long time.
When I connected from my home system (key not changed in a long time) to the remote system I got the following:-
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! Someone could be eavesdropping on you right now (man-in-the-middle attack)! It is also possible that the RSA host key has just been changed. The fingerprint for the RSA key sent by the remote host is b2:a3:b7:0a:0e:c0:d3:5c:2a:b3:69:bb:50:47:13:4e. Please contact your system administrator. Add correct host key in /home/chris/.ssh/known_hosts to get rid of this message. Offending key in /home/chris/.ssh/known_hosts:9 RSA host key for cheddar.halon.org.uk has changed and you have requested strict checking. Host key verification failed.OK, that's not a surprise as the remote system has changed it's key since I last connected.
I then fixed the above problem by removing the remote system's entry from my /home/chris/.ssh/known_hosts, then I logged in successfully with the following warning:-
The authenticity of host 'cheddar.halon.org.uk (195.177.253.180)' can't be established. RSA key fingerprint is b2:a3:b7:0a:0e:c0:d3:5c:2a:b3:69:bb:50:47:13:4e. Are you sure you want to continue connecting (yes/no)? yes... and logged in successfully.
*Then* I tried logging in back from the remote system to my home system, it just asked for my password, no public key authentication happened at all. I.e. it's *only* from systems listed in my authorized_keys file that public key authentication will happen, otherwise (if it's allowed) you just get password authentication.
*Tumbleweed*
On 31 Aug 22:35, Chris G wrote:
On Sun, Aug 31, 2008 at 10:26:32PM +0100, Jonathan McDowell wrote:
On Sun, Aug 31, 2008 at 10:17:55PM +0100, Chris G wrote:
You can connect with ssh using *password* authentication from anywhere but using public key authentication I think ssh needs to verify that the client is the host expected.
By default an SSH public key works from anywhere. You *can* tie it down with 'from="pattern-list"' to only allow a key to be used from specific host(s), but without that all the distros/OSes I've used seem to default to access from anywhere.
I'm confused but I have also just tried an experiment.
I have connected out to a system where I have a login which I haven't used for a very long time.
When I connected from my home system (key not changed in a long time) to the remote system I got the following:-
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! Someone could be eavesdropping on you right now (man-in-the-middle attack)! It is also possible that the RSA host key has just been changed. The fingerprint for the RSA key sent by the remote host is b2:a3:b7:0a:0e:c0:d3:5c:2a:b3:69:bb:50:47:13:4e. Please contact your system administrator. Add correct host key in /home/chris/.ssh/known_hosts to get rid of this message. Offending key in /home/chris/.ssh/known_hosts:9 RSA host key for cheddar.halon.org.uk has changed and you have requested strict checking. Host key verification failed.OK, that's not a surprise as the remote system has changed it's key since I last connected.
Unsuprising as it probably had a blacklisted key...
I then fixed the above problem by removing the remote system's entry from my /home/chris/.ssh/known_hosts, then I logged in successfully with the following warning:-
The authenticity of host 'cheddar.halon.org.uk (195.177.253.180)' can't be established. RSA key fingerprint is b2:a3:b7:0a:0e:c0:d3:5c:2a:b3:69:bb:50:47:13:4e. Are you sure you want to continue connecting (yes/no)? yes... and logged in successfully.
Well done, so you're in the remote machines authorized_keys file. Congrats.
*Then* I tried logging in back from the remote system to my home system, it just asked for my password, no public key authentication happened at all. I.e. it's *only* from systems listed in my authorized_keys file that public key authentication will happen, otherwise (if it's allowed) you just get password authentication.
*sigh* - right - had you added that machines ~/.ssh/id_rsa.pub to your local authorized_keys? no. So I don't expect that to work. Also, it will only ask you for a password *if* the system you are logging in to has that authentication method (it's easily turned off so that you end up with key only auth). If password/pam/Keyboard Interactive are all turned off, it will not ask for a password. It's only from *KEYS* listed in your authorized_keys file that access is allowed. *KEYS* can be copied between systems. *KEYS* are not tied to a particular system. *KEYS* are generated with a default comment of user@host with user set to the user that generated them and host set to the host of the machine they were generated on. Host *KEYS* and user *KEYS* are seperate, one identified the remote system, one identifies the remote user. ALL of this is documented in the man pages.
On Sun, Aug 31, 2008 at 10:48:16PM +0100, Brett Parker wrote:
*Then* I tried logging in back from the remote system to my home system, it just asked for my password, no public key authentication happened at all. I.e. it's *only* from systems listed in my authorized_keys file that public key authentication will happen, otherwise (if it's allowed) you just get password authentication.
*sigh* - right - had you added that machines ~/.ssh/id_rsa.pub to your local authorized_keys? no. So I don't expect that to work. Also, it will only ask you for a password *if* the system you are logging in to has that authentication method (it's easily turned off so that you end up with key only auth). If password/pam/Keyboard Interactive are all turned off, it will not ask for a password. It's only from *KEYS* listed in your authorized_keys file that access is allowed. *KEYS* can be copied between systems. *KEYS* are not tied to a particular system. *KEYS* are generated with a default comment of user@host with user set to the user that generated them and host set to the host of the machine they were generated on. Host *KEYS* and user *KEYS* are seperate, one identified the remote system, one identifies the remote user. ALL of this is documented in the man pages.
OK, I was a bit confused but not *totally* confused. At work we use host-based authentication which *does* check that you are logging in from a know host, i.e. one with a host key that the remote server can verify. If you are using that then what I said was about true.
As you say though public key authentication identifies the *user* but doesn't care what machine he is connecting from.
On 31 Aug 22:17, Chris G wrote:
I don't believe I am, not entirely. If I am talking rubbish then why do I have entries in my ~/.ssh/authorized_keys file which relate to specific remote clients? Each one of the entries in authorized_keys is for a specific remote host that I connect from.
I don't know of anyone that uses authorized_keys that way, and if you are talking of the bit after the key in authorized_keys, then I hope you understand that that is just a comment (the username@host) thing is purely a comment and is totally ignored, if you want to check this, then please feel free to edit one of them and change it to "oh_dear_is_this_really_just_a_comment".
You can connect with ssh using *password* authentication from anywhere but using public key authentication I think ssh needs to verify that the client is the host expected.
*If* the hostname is the same, and *if* this was the problem, then it prompts with a *completely* different message. And, infact, tells you about StrictHostKey checking.
Cheers,
Brett Parker iDunno@sommitrealweird.co.uk wrote:
No, ChrisG is talking out of his arse. If that was the case then my laptop would be useless [...]
Oi! Polite! Else I'll tell everyone about the new sysadmin who spent *ages* restarting apache on the wrong system and wondering why it didn't change the website configuration.
(But I expect that's my fault for naming all the servers after people's pet rabbits - oh, tantumbunky, fond memories...)
On Tue, Sep 02, 2008 at 10:47:13AM +0100, MJ Ray wrote:
Brett Parker iDunno@sommitrealweird.co.uk wrote:
No, ChrisG is talking out of his arse. If that was the case then my laptop would be useless [...]
Oi! Polite! Else I'll tell everyone about the new sysadmin who spent *ages* restarting apache on the wrong system and wondering why it didn't change the website configuration.
I've done things like that, it's *very* easy to do. You get sort of tunnel vision saying to yourself "If I restart this it just *must* have an effect on that output I'm looking at".
It usually happens on "Friday afternoon" or the equivalent.
(But I expect that's my fault for naming all the servers after people's pet rabbits - oh, tantumbunky, fond memories...)
Our work systems are mostly named after mis-spelt minerals.
On 02 Sep 10:47, MJ Ray wrote:
Brett Parker iDunno@sommitrealweird.co.uk wrote:
No, ChrisG is talking out of his arse. If that was the case then my laptop would be useless [...]
Oi! Polite! Else I'll tell everyone about the new sysadmin who spent *ages* restarting apache on the wrong system and wondering why it didn't change the website configuration.
Wasn't bad for in the first week, really... what with the copious documentation we had :) Between that and the eventually finding the right runes for the "oh crap, the NFS server has decided to kill things again, oh, and NIS has broken" I think working for stu was *marvellous*.
These days I get more fun playing "track where the hell that packet is dropping", with pf and OpenBSD... my head isn't liking me today... and all I want to do is route the http traffic from a box through a completely different interface through another 2 firewalls and out the other end... it shouldn't be difficult, dammit! (Oh, and leaving all other traffic going the right way...).
It's been a damned bumpy 9 years of graft to get here. Now I need more tea :)
Brett Parker iDunno@sommitrealweird.co.uk wrote:
On 02 Sep 10:47, MJ Ray wrote:
Oi! Polite! Else I'll tell everyone about the new sysadmin who spent *ages* restarting apache on the wrong system and wondering why it didn't change the website configuration.
Wasn't bad for in the first week, really... what with the copious documentation we had :) Between that and the eventually finding the right runes for the "oh crap, the NFS server has decided to kill things again, oh, and NIS has broken" I think working for stu was *marvellous*.
Heck, at least it killed things (thanks to timeo, soft, intr and some other options). Most of the NFS problems on campus servers used to make processes hang in an unkillable D (waiting for disk I/O) state and the load averages rise to something astronomical.
These days I get more fun playing "track where the hell that packet is dropping", with pf and OpenBSD... my head isn't liking me today... and all I want to do is [...]
Bring about world peace - it's probably easier than networking.
Or retire to a desert island and become a gardener, just to mix two old sayings up and confuse everyone.
So, how do we cure the BGP security problems that are in the news?
Randomly,
On 02 Sep 12:25, MJ Ray wrote:
Brett Parker iDunno@sommitrealweird.co.uk wrote:
On 02 Sep 10:47, MJ Ray wrote:
Oi! Polite! Else I'll tell everyone about the new sysadmin who spent *ages* restarting apache on the wrong system and wondering why it didn't change the website configuration.
Wasn't bad for in the first week, really... what with the copious documentation we had :) Between that and the eventually finding the right runes for the "oh crap, the NFS server has decided to kill things again, oh, and NIS has broken" I think working for stu was *marvellous*.
Heck, at least it killed things (thanks to timeo, soft, intr and some other options). Most of the NFS problems on campus servers used to make processes hang in an unkillable D (waiting for disk I/O) state and the load averages rise to something astronomical.
Indeed - it was nice that it did, once we got all the options right, and the right magic procedure to bring everything back up without a reboot... :)
These days I get more fun playing "track where the hell that packet is dropping", with pf and OpenBSD... my head isn't liking me today... and all I want to do is [...]
Bring about world peace - it's probably easier than networking.
Heh - got it now, involved 3 different instances of pf on 3 different firewalls, the first routing to the second, that then routed to the third which then did the nat for it... all the fun it was :)
Or retire to a desert island and become a gardener, just to mix two old sayings up and confuse everyone.
Hmmm, I wonder how easy it is to garden a barren landscape, sounds tricky.
So, how do we cure the BGP security problems that are in the news?
Oh, that one is *easy*... basically, take all the nosey, naughty people out of the gene pool. It's a social problem, basically society is full of arseholes, remove them and we can just get on with the fun parts.
*grin*
On Tue, Sep 02, 2008 at 12:51:26PM +0100, Brett Parker wrote:
So, how do we cure the BGP security problems that are in the news?
Oh, that one is *easy*... basically, take all the nosey, naughty people out of the gene pool. It's a social problem, basically society is full of arseholes, remove them and we can just get on with the fun parts.
... but then what do we speak out of?
On 02-Sep-08 11:25:23, MJ Ray wrote:
Heck, at least it killed things (thanks to timeo, soft, intr and some other options). Most of the NFS problems on campus servers used to make processes hang in an unkillable D (waiting for disk I/O) state and the load averages rise to something astronomical.
Reminds me of a time back in the 80s when I was (amateur) sysadmin for a little Unix machine in the Cambridge Pure Maths Dept. There were about 25 serial cables running off to different offices.
Came in one morning, machine frozen solid. Rebooted, got a message "device full". Poked around, found a huge log-file. Deleted that, and it was running again. But the log-file was building up ...
Tracked it down to one of the serial cables. The guy whose office it went to had it running close to some equipment, and the poor computer had spent all night trying to log-in the mains hum. And recording its failures ... on a 10MB hard drive.
Those were the days ... Ted.
-------------------------------------------------------------------- E-Mail: (Ted Harding) Ted.Harding@manchester.ac.uk Fax-to-email: +44 (0)870 094 0861 Date: 02-Sep-08 Time: 12:59:25 ------------------------------ XFMail ------------------------------
2008/8/31 Barry Samuels bjsamuels@beenthere-donethat.org.uk:
So if one is travelling and staying in a hotel with wifi facilities then connection via SSH is not possible. Is that true?
No. I regularly take my laptop to France, and connect home using the Orange wifi. Have you got different names for your home network in your hosts file though? I would ask to connect to my external IP named as an external name in my hosts file, from abroad, which the router is set to forward to a particular internal computer. Internally, I connect to the internal name in the hosts file. I thus have to have the correct key pair for the computer that the router is designated to forward the request to.
Hope I haven't missed the point here....... connection is possible though!
Jenny
2008/8/31 Barry Samuels bjsamuels@beenthere-donethat.org.uk:
So if one is travelling and staying in a hotel with wifi facilities then connection via SSH is not possible. Is that true?
I find hotels like you to log-on with your web browser first before their router opens up to allow SSH, etc.
Tim.
On Sun, Aug 31, 2008 at 09:40:39PM +0100, Barry Samuels wrote:
Or (and I think this *is* probably the answer) does your laptop have a different address when connecting from 'outside'?
Almost certainly.
The ssh keys you have set up allow connections from specific hosts so a connection set up that works when the laptop has a local IP address will not work when the laptop has an IP address given to it by some other network.
So if one is travelling and staying in a hotel with wifi facilities then connection via SSH is not possible. Is that true?
The authorized_keys file has entries relating to the remote systems allowed to connect, you need somehow to make your remote client appear to be the same wherever you connect from.
I think I'd need to read the ssh (and sshd) manual pages to find out the ramifications of how to do it.
On 31 Aug 22:14, Chris G wrote:
On Sun, Aug 31, 2008 at 09:40:39PM +0100, Barry Samuels wrote:
Or (and I think this *is* probably the answer) does your laptop have a different address when connecting from 'outside'?
Almost certainly.
The ssh keys you have set up allow connections from specific hosts so a connection set up that works when the laptop has a local IP address will not work when the laptop has an IP address given to it by some other network.
So if one is travelling and staying in a hotel with wifi facilities then connection via SSH is not possible. Is that true?
The authorized_keys file has entries relating to the remote systems allowed to connect, you need somehow to make your remote client appear to be the same wherever you connect from.
I think I'd need to read the ssh (and sshd) manual pages to find out the ramifications of how to do it.
I think you really do need to go read the man pages. Before spreading more FUD. Please.
-
Barry Samuels -
Brett Parker -
Chris G -
Jenny Hopkins -
Jonathan McDowell -
MJ Ray -
Steven Rose -
Ted.Harding＠manchester.ac.uk -
Tim Green