How ssh can connect with itself?
I was experimenting with linux ssh. And in terminal I tried to connect with the same linux machine which I was using and it got connected! Its like calling your same phone from your phone! But how this is possible?
Below is sample terminal commands I entered:
alpha@alpha:~$ ssh alpha@<my IP address>
alpha@<my IP address>'s password: <my password>
Welcome to Ubuntu 18.04.1 LTS (GNU/Linux 4.15.0-42-generic x86_64)
* Documentation: https://help.ubuntu.com
* Management: https://landscape.canonical.com
* Support: https://ubuntu.com/advantage
* Canonical Livepatch is available for installation.
- Reduce system reboots and improve kernel security. Activate at:
https://ubuntu.com/livepatch
0 packages can be updated.
0 updates are security updates.
Last login: Mon Dec 10 15:31:35 2018 from <my IP address>
In above terminal is the same IP address of the linux machine by which I used ssh and the above terminal output. And I have also noticed that I can connect with the same machine using ssh in nested connections and I have tried 5 level deep!
Out of curiosity I am asking this question to know is this correct? Can't the linux detect its talking to itself?
linux ssh
|
show 4 more comments
I was experimenting with linux ssh. And in terminal I tried to connect with the same linux machine which I was using and it got connected! Its like calling your same phone from your phone! But how this is possible?
Below is sample terminal commands I entered:
alpha@alpha:~$ ssh alpha@<my IP address>
alpha@<my IP address>'s password: <my password>
Welcome to Ubuntu 18.04.1 LTS (GNU/Linux 4.15.0-42-generic x86_64)
* Documentation: https://help.ubuntu.com
* Management: https://landscape.canonical.com
* Support: https://ubuntu.com/advantage
* Canonical Livepatch is available for installation.
- Reduce system reboots and improve kernel security. Activate at:
https://ubuntu.com/livepatch
0 packages can be updated.
0 updates are security updates.
Last login: Mon Dec 10 15:31:35 2018 from <my IP address>
In above terminal is the same IP address of the linux machine by which I used ssh and the above terminal output. And I have also noticed that I can connect with the same machine using ssh in nested connections and I have tried 5 level deep!
Out of curiosity I am asking this question to know is this correct? Can't the linux detect its talking to itself?
linux ssh
3
Actually you have 2 phones of which one can only call and one can only receive calls.openssh-server
andopenssh-client
.
– RoVo
Dec 10 at 10:26
@RoVo By your analogy, you mean that the server can listen to any client though it maybe its own machine?
– MrAlpha
Dec 10 at 10:29
To try to connect a machine to itself you may use also:ssh <user>@localhost
. The result is the same if you use ssh <user>@<my IP address>. In this way you obtain to have a shell inside the shell that called ssh.
– Sir Jo Black
Dec 10 at 10:30
1
@SirJoBlack Yes this too works and the result is same.
– MrAlpha
Dec 10 at 10:33
1
@SirJoBlack: technically not quite, it is possible to have asshd
that will only listen onlocalhost
, or one that only listens to the public IP address; and it's possible for the firewall to treat the two differently.
– Ulrich Schwarz
Dec 10 at 11:32
|
show 4 more comments
I was experimenting with linux ssh. And in terminal I tried to connect with the same linux machine which I was using and it got connected! Its like calling your same phone from your phone! But how this is possible?
Below is sample terminal commands I entered:
alpha@alpha:~$ ssh alpha@<my IP address>
alpha@<my IP address>'s password: <my password>
Welcome to Ubuntu 18.04.1 LTS (GNU/Linux 4.15.0-42-generic x86_64)
* Documentation: https://help.ubuntu.com
* Management: https://landscape.canonical.com
* Support: https://ubuntu.com/advantage
* Canonical Livepatch is available for installation.
- Reduce system reboots and improve kernel security. Activate at:
https://ubuntu.com/livepatch
0 packages can be updated.
0 updates are security updates.
Last login: Mon Dec 10 15:31:35 2018 from <my IP address>
In above terminal is the same IP address of the linux machine by which I used ssh and the above terminal output. And I have also noticed that I can connect with the same machine using ssh in nested connections and I have tried 5 level deep!
Out of curiosity I am asking this question to know is this correct? Can't the linux detect its talking to itself?
linux ssh
I was experimenting with linux ssh. And in terminal I tried to connect with the same linux machine which I was using and it got connected! Its like calling your same phone from your phone! But how this is possible?
Below is sample terminal commands I entered:
alpha@alpha:~$ ssh alpha@<my IP address>
alpha@<my IP address>'s password: <my password>
Welcome to Ubuntu 18.04.1 LTS (GNU/Linux 4.15.0-42-generic x86_64)
* Documentation: https://help.ubuntu.com
* Management: https://landscape.canonical.com
* Support: https://ubuntu.com/advantage
* Canonical Livepatch is available for installation.
- Reduce system reboots and improve kernel security. Activate at:
https://ubuntu.com/livepatch
0 packages can be updated.
0 updates are security updates.
Last login: Mon Dec 10 15:31:35 2018 from <my IP address>
In above terminal is the same IP address of the linux machine by which I used ssh and the above terminal output. And I have also noticed that I can connect with the same machine using ssh in nested connections and I have tried 5 level deep!
Out of curiosity I am asking this question to know is this correct? Can't the linux detect its talking to itself?
linux ssh
linux ssh
edited Dec 10 at 10:31
asked Dec 10 at 10:22
MrAlpha
114
114
3
Actually you have 2 phones of which one can only call and one can only receive calls.openssh-server
andopenssh-client
.
– RoVo
Dec 10 at 10:26
@RoVo By your analogy, you mean that the server can listen to any client though it maybe its own machine?
– MrAlpha
Dec 10 at 10:29
To try to connect a machine to itself you may use also:ssh <user>@localhost
. The result is the same if you use ssh <user>@<my IP address>. In this way you obtain to have a shell inside the shell that called ssh.
– Sir Jo Black
Dec 10 at 10:30
1
@SirJoBlack Yes this too works and the result is same.
– MrAlpha
Dec 10 at 10:33
1
@SirJoBlack: technically not quite, it is possible to have asshd
that will only listen onlocalhost
, or one that only listens to the public IP address; and it's possible for the firewall to treat the two differently.
– Ulrich Schwarz
Dec 10 at 11:32
|
show 4 more comments
3
Actually you have 2 phones of which one can only call and one can only receive calls.openssh-server
andopenssh-client
.
– RoVo
Dec 10 at 10:26
@RoVo By your analogy, you mean that the server can listen to any client though it maybe its own machine?
– MrAlpha
Dec 10 at 10:29
To try to connect a machine to itself you may use also:ssh <user>@localhost
. The result is the same if you use ssh <user>@<my IP address>. In this way you obtain to have a shell inside the shell that called ssh.
– Sir Jo Black
Dec 10 at 10:30
1
@SirJoBlack Yes this too works and the result is same.
– MrAlpha
Dec 10 at 10:33
1
@SirJoBlack: technically not quite, it is possible to have asshd
that will only listen onlocalhost
, or one that only listens to the public IP address; and it's possible for the firewall to treat the two differently.
– Ulrich Schwarz
Dec 10 at 11:32
3
3
Actually you have 2 phones of which one can only call and one can only receive calls.
openssh-server
and openssh-client
.– RoVo
Dec 10 at 10:26
Actually you have 2 phones of which one can only call and one can only receive calls.
openssh-server
and openssh-client
.– RoVo
Dec 10 at 10:26
@RoVo By your analogy, you mean that the server can listen to any client though it maybe its own machine?
– MrAlpha
Dec 10 at 10:29
@RoVo By your analogy, you mean that the server can listen to any client though it maybe its own machine?
– MrAlpha
Dec 10 at 10:29
To try to connect a machine to itself you may use also:
ssh <user>@localhost
. The result is the same if you use ssh <user>@<my IP address>. In this way you obtain to have a shell inside the shell that called ssh.– Sir Jo Black
Dec 10 at 10:30
To try to connect a machine to itself you may use also:
ssh <user>@localhost
. The result is the same if you use ssh <user>@<my IP address>. In this way you obtain to have a shell inside the shell that called ssh.– Sir Jo Black
Dec 10 at 10:30
1
1
@SirJoBlack Yes this too works and the result is same.
– MrAlpha
Dec 10 at 10:33
@SirJoBlack Yes this too works and the result is same.
– MrAlpha
Dec 10 at 10:33
1
1
@SirJoBlack: technically not quite, it is possible to have a
sshd
that will only listen on localhost
, or one that only listens to the public IP address; and it's possible for the firewall to treat the two differently.– Ulrich Schwarz
Dec 10 at 11:32
@SirJoBlack: technically not quite, it is possible to have a
sshd
that will only listen on localhost
, or one that only listens to the public IP address; and it's possible for the firewall to treat the two differently.– Ulrich Schwarz
Dec 10 at 11:32
|
show 4 more comments
2 Answers
2
active
oldest
votes
In Linux every connection that you are doing normally runs on bash at end, for other unixes other shells are used (and other initialization scripts)
So you can use the current shell initialization scripts to configure the connection behavior of a ssh client by reading the environment variables generated by the ssh client session.
For example in /etc/bash.bashrc something like this can block you from connecting to yourself.
CNIP=$(echo $SSH_CONNECTION | cut -d' ' -f1)
RNIP=$(echo $SSH_CONNECTION | cut -d' ' -f3)
if [ "$CNIP" == "$RNIP" ] && [ "$CNIP" != "" ] ; then
echo "We are connecting to ourself, exiting.."
exit 1
fi
So in linux, with this you probably will prevent ssh from allowing a connection for the server ip itself.
Linux/Unix are very customizable, it will probably allows you to do everything, including broking your system with a infinite loop if you really wanted it. So if you want to prevent some kind of things you need to be more explicity.
In the other hand I didn't see any troble with this behavior and I am unable to determine why you are concerned about it, but if you really want to prevent for any reason, here are probably a solution.
I forget to validate if you are trying to login without ssh or this will lock local authentication... so now I put this additional condidition: && [ "$CNIP" != "" ], this will prevent you from locking local authentication if this is not your intention...
– Luciano Andress Martini
Dec 11 at 13:34
add a comment |
Your system is like a building, not like a phone.
You can make many calls to a building. You can call another person within the building.
So when you ssh to the same machine, it makes the call. Then receives the call. The receiving end is not aware that the call is coming from the same machine, and it handles it correctly.
It does not connect it to the same shell/command-line. Unix is a multi-tasking system. If it could only do one task, then there would be a problem. But it can do many. There can be many users connected to a machine, all doing there own thing. If one of these is the self, it does not matter.
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "106"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f487076%2fhow-ssh-can-connect-with-itself%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
In Linux every connection that you are doing normally runs on bash at end, for other unixes other shells are used (and other initialization scripts)
So you can use the current shell initialization scripts to configure the connection behavior of a ssh client by reading the environment variables generated by the ssh client session.
For example in /etc/bash.bashrc something like this can block you from connecting to yourself.
CNIP=$(echo $SSH_CONNECTION | cut -d' ' -f1)
RNIP=$(echo $SSH_CONNECTION | cut -d' ' -f3)
if [ "$CNIP" == "$RNIP" ] && [ "$CNIP" != "" ] ; then
echo "We are connecting to ourself, exiting.."
exit 1
fi
So in linux, with this you probably will prevent ssh from allowing a connection for the server ip itself.
Linux/Unix are very customizable, it will probably allows you to do everything, including broking your system with a infinite loop if you really wanted it. So if you want to prevent some kind of things you need to be more explicity.
In the other hand I didn't see any troble with this behavior and I am unable to determine why you are concerned about it, but if you really want to prevent for any reason, here are probably a solution.
I forget to validate if you are trying to login without ssh or this will lock local authentication... so now I put this additional condidition: && [ "$CNIP" != "" ], this will prevent you from locking local authentication if this is not your intention...
– Luciano Andress Martini
Dec 11 at 13:34
add a comment |
In Linux every connection that you are doing normally runs on bash at end, for other unixes other shells are used (and other initialization scripts)
So you can use the current shell initialization scripts to configure the connection behavior of a ssh client by reading the environment variables generated by the ssh client session.
For example in /etc/bash.bashrc something like this can block you from connecting to yourself.
CNIP=$(echo $SSH_CONNECTION | cut -d' ' -f1)
RNIP=$(echo $SSH_CONNECTION | cut -d' ' -f3)
if [ "$CNIP" == "$RNIP" ] && [ "$CNIP" != "" ] ; then
echo "We are connecting to ourself, exiting.."
exit 1
fi
So in linux, with this you probably will prevent ssh from allowing a connection for the server ip itself.
Linux/Unix are very customizable, it will probably allows you to do everything, including broking your system with a infinite loop if you really wanted it. So if you want to prevent some kind of things you need to be more explicity.
In the other hand I didn't see any troble with this behavior and I am unable to determine why you are concerned about it, but if you really want to prevent for any reason, here are probably a solution.
I forget to validate if you are trying to login without ssh or this will lock local authentication... so now I put this additional condidition: && [ "$CNIP" != "" ], this will prevent you from locking local authentication if this is not your intention...
– Luciano Andress Martini
Dec 11 at 13:34
add a comment |
In Linux every connection that you are doing normally runs on bash at end, for other unixes other shells are used (and other initialization scripts)
So you can use the current shell initialization scripts to configure the connection behavior of a ssh client by reading the environment variables generated by the ssh client session.
For example in /etc/bash.bashrc something like this can block you from connecting to yourself.
CNIP=$(echo $SSH_CONNECTION | cut -d' ' -f1)
RNIP=$(echo $SSH_CONNECTION | cut -d' ' -f3)
if [ "$CNIP" == "$RNIP" ] && [ "$CNIP" != "" ] ; then
echo "We are connecting to ourself, exiting.."
exit 1
fi
So in linux, with this you probably will prevent ssh from allowing a connection for the server ip itself.
Linux/Unix are very customizable, it will probably allows you to do everything, including broking your system with a infinite loop if you really wanted it. So if you want to prevent some kind of things you need to be more explicity.
In the other hand I didn't see any troble with this behavior and I am unable to determine why you are concerned about it, but if you really want to prevent for any reason, here are probably a solution.
In Linux every connection that you are doing normally runs on bash at end, for other unixes other shells are used (and other initialization scripts)
So you can use the current shell initialization scripts to configure the connection behavior of a ssh client by reading the environment variables generated by the ssh client session.
For example in /etc/bash.bashrc something like this can block you from connecting to yourself.
CNIP=$(echo $SSH_CONNECTION | cut -d' ' -f1)
RNIP=$(echo $SSH_CONNECTION | cut -d' ' -f3)
if [ "$CNIP" == "$RNIP" ] && [ "$CNIP" != "" ] ; then
echo "We are connecting to ourself, exiting.."
exit 1
fi
So in linux, with this you probably will prevent ssh from allowing a connection for the server ip itself.
Linux/Unix are very customizable, it will probably allows you to do everything, including broking your system with a infinite loop if you really wanted it. So if you want to prevent some kind of things you need to be more explicity.
In the other hand I didn't see any troble with this behavior and I am unable to determine why you are concerned about it, but if you really want to prevent for any reason, here are probably a solution.
edited Dec 13 at 16:26
answered Dec 10 at 14:33
Luciano Andress Martini
3,453931
3,453931
I forget to validate if you are trying to login without ssh or this will lock local authentication... so now I put this additional condidition: && [ "$CNIP" != "" ], this will prevent you from locking local authentication if this is not your intention...
– Luciano Andress Martini
Dec 11 at 13:34
add a comment |
I forget to validate if you are trying to login without ssh or this will lock local authentication... so now I put this additional condidition: && [ "$CNIP" != "" ], this will prevent you from locking local authentication if this is not your intention...
– Luciano Andress Martini
Dec 11 at 13:34
I forget to validate if you are trying to login without ssh or this will lock local authentication... so now I put this additional condidition: && [ "$CNIP" != "" ], this will prevent you from locking local authentication if this is not your intention...
– Luciano Andress Martini
Dec 11 at 13:34
I forget to validate if you are trying to login without ssh or this will lock local authentication... so now I put this additional condidition: && [ "$CNIP" != "" ], this will prevent you from locking local authentication if this is not your intention...
– Luciano Andress Martini
Dec 11 at 13:34
add a comment |
Your system is like a building, not like a phone.
You can make many calls to a building. You can call another person within the building.
So when you ssh to the same machine, it makes the call. Then receives the call. The receiving end is not aware that the call is coming from the same machine, and it handles it correctly.
It does not connect it to the same shell/command-line. Unix is a multi-tasking system. If it could only do one task, then there would be a problem. But it can do many. There can be many users connected to a machine, all doing there own thing. If one of these is the self, it does not matter.
add a comment |
Your system is like a building, not like a phone.
You can make many calls to a building. You can call another person within the building.
So when you ssh to the same machine, it makes the call. Then receives the call. The receiving end is not aware that the call is coming from the same machine, and it handles it correctly.
It does not connect it to the same shell/command-line. Unix is a multi-tasking system. If it could only do one task, then there would be a problem. But it can do many. There can be many users connected to a machine, all doing there own thing. If one of these is the self, it does not matter.
add a comment |
Your system is like a building, not like a phone.
You can make many calls to a building. You can call another person within the building.
So when you ssh to the same machine, it makes the call. Then receives the call. The receiving end is not aware that the call is coming from the same machine, and it handles it correctly.
It does not connect it to the same shell/command-line. Unix is a multi-tasking system. If it could only do one task, then there would be a problem. But it can do many. There can be many users connected to a machine, all doing there own thing. If one of these is the self, it does not matter.
Your system is like a building, not like a phone.
You can make many calls to a building. You can call another person within the building.
So when you ssh to the same machine, it makes the call. Then receives the call. The receiving end is not aware that the call is coming from the same machine, and it handles it correctly.
It does not connect it to the same shell/command-line. Unix is a multi-tasking system. If it could only do one task, then there would be a problem. But it can do many. There can be many users connected to a machine, all doing there own thing. If one of these is the self, it does not matter.
answered Dec 13 at 17:39
ctrl-alt-delor
10.6k41955
10.6k41955
add a comment |
add a comment |
Thanks for contributing an answer to Unix & Linux Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f487076%2fhow-ssh-can-connect-with-itself%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
3
Actually you have 2 phones of which one can only call and one can only receive calls.
openssh-server
andopenssh-client
.– RoVo
Dec 10 at 10:26
@RoVo By your analogy, you mean that the server can listen to any client though it maybe its own machine?
– MrAlpha
Dec 10 at 10:29
To try to connect a machine to itself you may use also:
ssh <user>@localhost
. The result is the same if you use ssh <user>@<my IP address>. In this way you obtain to have a shell inside the shell that called ssh.– Sir Jo Black
Dec 10 at 10:30
1
@SirJoBlack Yes this too works and the result is same.
– MrAlpha
Dec 10 at 10:33
1
@SirJoBlack: technically not quite, it is possible to have a
sshd
that will only listen onlocalhost
, or one that only listens to the public IP address; and it's possible for the firewall to treat the two differently.– Ulrich Schwarz
Dec 10 at 11:32