Mdthbs

Is it tax fraud for an individual to declare non-taxable revenue as taxable income? (US tax laws)

Why can't I see bouncing of a switch on an oscilloscope?

Why doesn't Newton's third law mean a person bounces back to where they started when they hit the ground?

Book about a traveler who helps planets in need

How can the DM most effectively choose 1 out of an odd number of players to be targeted by an attack or effect?

Why are 150k or 200k jobs considered good when there are 300k+ births a month?

How old can references or sources in a thesis be?

Can I interfere when another PC is about to be attacked?

Prevent a directory in /tmp from being deleted

How can I automatically replace [[ and ]] with the [LeftDoubleBracket] and [RightDoubleBracket] operators?

I’m planning on buying a laser printer but concerned about the life cycle of toner in the machine

What are these boxed doors outside store fronts in New York?

Suffixes -unt and -ut-

Why are only specific transaction types accepted into the mempool?

What typically incentivizes a professor to change jobs to a lower ranking university?

What is the offset in a seaplane's hull?

What do you call a Matrix-like slowdown and camera movement effect?

A newer friend of my brother's gave him a load of baseball cards that are supposedly extremely valuable. Is this a scam?

Can I make popcorn with any corn?

How is the claim "I am in New York only if I am in America" the same as "If I am in New York, then I am in America?

What is the command to reset a PC without deleting any files

Shell script can be run only with sh command

I probably found a bug with the sudo apt install function

Email Account under attack (really) - anything I can do?

How to secure ~/.ssh/authorized_keys file?

Login via ssh without password, getting authorized_keys file removed after first login attemptRHEL 7 (CentOS 7) security / ssh / sshd_config advise requestedAuthentication refused: bad ownership or modes for file /var/git/.ssh/authorized_keysAllow SSH access but restrict root's access to a given set of IPsWhy does SSH server say, “authorized_keys is not a regular file”?enable access via ssh-key without using ~/ssh/authorized_keysHow to make ssh account capabele to only sshfs and rsync?Being Prompted for Password After Already Registered Public Key On serverHow do $HOME/.ssh directory and $HOME/.ssh/authorized_keys file permissions work when multiple users have a same UID?Configuring users to SSH login

.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty{ margin-bottom:0;
}

2

1

I have a machine with public key authentication enabled. I have some authorized keys at ~/.ssh/authorized_keys.

I'm worried about the case I ever mistakenly run a malicious script/program with my user (with no root access). The script would be allowed to silently modify ~/.ssh/authorized_keys to allow an attacker to permanently obtain remote access to that user and further attack the system.

Question1: Is the default location for authorized keys (~/.ssh/authorized_keys) a security issue?

Question2: Is there a different approach to saving per-user authorized keys in a more secure way (i.e. requiring root access to allow new hosts)?

sshd

share|improve this question

asked 22 hours ago

AndresRAndresR

596

add a comment | 

2

1

I have a machine with public key authentication enabled. I have some authorized keys at ~/.ssh/authorized_keys.

I'm worried about the case I ever mistakenly run a malicious script/program with my user (with no root access). The script would be allowed to silently modify ~/.ssh/authorized_keys to allow an attacker to permanently obtain remote access to that user and further attack the system.

Question1: Is the default location for authorized keys (~/.ssh/authorized_keys) a security issue?

Question2: Is there a different approach to saving per-user authorized keys in a more secure way (i.e. requiring root access to allow new hosts)?

sshd

share|improve this question

asked 22 hours ago

AndresRAndresR

596

add a comment | 

I have a machine with public key authentication enabled. I have some authorized keys at ~/.ssh/authorized_keys.

I'm worried about the case I ever mistakenly run a malicious script/program with my user (with no root access). The script would be allowed to silently modify ~/.ssh/authorized_keys to allow an attacker to permanently obtain remote access to that user and further attack the system.

Question1: Is the default location for authorized keys (~/.ssh/authorized_keys) a security issue?

Question2: Is there a different approach to saving per-user authorized keys in a more secure way (i.e. requiring root access to allow new hosts)?

sshd

share|improve this question

asked 22 hours ago

AndresRAndresR

596

share|improve this question

asked 22 hours ago

AndresRAndresR

596

share|improve this question

asked 22 hours ago

AndresRAndresR

596

asked 22 hours ago

AndresRAndresR

596

asked 22 hours ago

AndresRAndresR

596

1 Answer
1

active

oldest

votes

1

If you have root access on this machine, then you could try making your ssh files and directory immutable by using the chattr command, e.g.:

sudo chattr +i ~/.ssh/authorized_keys

sudo chattr +i ~/.ssh

This will prevent your authorized keys file from being modified, renamed, deleted or overwritten. Since only root can unset the immutability flag, this would prevent any script you run as a regular user from inserting a key to your authorized_keys file.

share|improve this answer

answered 22 hours ago

igaligal

6,1411638

• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  Thank you! I would now wonder why is not a mechanism like this the default?
  
  – AndresR
  21 hours ago
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  @AndresR Things being as they are, I don't think that this would be a very good default behavior. Every time you want to add a key to your authorized keys file, you would have to submit a request to your system administrator. And the sysadmin would have to unset the flag, add the key, and then reset the flag.
  
  – igal
  19 hours ago
  

  
  
  
  


• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  
  @AndresR It is a matter of convenience over security. The standpoint is "if there is malware running on your system, it already is too late". There is a myriad of possibilities for malware to open access to your system (e.g. place a reverse shell in the user's auto-start) – it does not make sense to protect against this particular attack (this would feel like a Microsoft thing to do – "we now protect against $foo" sounds good in marketing). Developers and admins should rather feel inclined never to have malware executed in the first place.
  
  – Hermann
  12 hours ago
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  That is certainly the case of large multi-user systems. If I'm running a small server, where I work all the day, chances are at some point I'll run some code I didn't fully read, and risk the system. As I'm also the sysadmin, I'd be able to add a key.
  
  – AndresR
  1 hour ago
  

  
  
  
  

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
});


}
});

draft saved

draft discarded

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

Name

Email

Required, but never shown

StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f510967%2fhow-to-secure-ssh-authorized-keys-file%23new-answer', 'question_page');
}
);

Post as a guest

Name

Email

Required, but never shown

1

If you have root access on this machine, then you could try making your ssh files and directory immutable by using the chattr command, e.g.:

sudo chattr +i ~/.ssh/authorized_keys

sudo chattr +i ~/.ssh

This will prevent your authorized keys file from being modified, renamed, deleted or overwritten. Since only root can unset the immutability flag, this would prevent any script you run as a regular user from inserting a key to your authorized_keys file.

share|improve this answer

answered 22 hours ago

igaligal

6,1411638

• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  Thank you! I would now wonder why is not a mechanism like this the default?
  
  – AndresR
  21 hours ago
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  @AndresR Things being as they are, I don't think that this would be a very good default behavior. Every time you want to add a key to your authorized keys file, you would have to submit a request to your system administrator. And the sysadmin would have to unset the flag, add the key, and then reset the flag.
  
  – igal
  19 hours ago
  

  
  
  
  


• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  
  @AndresR It is a matter of convenience over security. The standpoint is "if there is malware running on your system, it already is too late". There is a myriad of possibilities for malware to open access to your system (e.g. place a reverse shell in the user's auto-start) – it does not make sense to protect against this particular attack (this would feel like a Microsoft thing to do – "we now protect against $foo" sounds good in marketing). Developers and admins should rather feel inclined never to have malware executed in the first place.
  
  – Hermann
  12 hours ago
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  That is certainly the case of large multi-user systems. If I'm running a small server, where I work all the day, chances are at some point I'll run some code I didn't fully read, and risk the system. As I'm also the sysadmin, I'd be able to add a key.
  
  – AndresR
  1 hour ago
  

  
  
  
  

add a comment | 

1

If you have root access on this machine, then you could try making your ssh files and directory immutable by using the chattr command, e.g.:

sudo chattr +i ~/.ssh/authorized_keys

sudo chattr +i ~/.ssh

This will prevent your authorized keys file from being modified, renamed, deleted or overwritten. Since only root can unset the immutability flag, this would prevent any script you run as a regular user from inserting a key to your authorized_keys file.

share|improve this answer

answered 22 hours ago

igaligal

6,1411638

• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  Thank you! I would now wonder why is not a mechanism like this the default?
  
  – AndresR
  21 hours ago
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  @AndresR Things being as they are, I don't think that this would be a very good default behavior. Every time you want to add a key to your authorized keys file, you would have to submit a request to your system administrator. And the sysadmin would have to unset the flag, add the key, and then reset the flag.
  
  – igal
  19 hours ago
  

  
  
  
  


• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  
  @AndresR It is a matter of convenience over security. The standpoint is "if there is malware running on your system, it already is too late". There is a myriad of possibilities for malware to open access to your system (e.g. place a reverse shell in the user's auto-start) – it does not make sense to protect against this particular attack (this would feel like a Microsoft thing to do – "we now protect against $foo" sounds good in marketing). Developers and admins should rather feel inclined never to have malware executed in the first place.
  
  – Hermann
  12 hours ago
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  That is certainly the case of large multi-user systems. If I'm running a small server, where I work all the day, chances are at some point I'll run some code I didn't fully read, and risk the system. As I'm also the sysadmin, I'd be able to add a key.
  
  – AndresR
  1 hour ago
  

  
  
  
  

add a comment | 

If you have root access on this machine, then you could try making your ssh files and directory immutable by using the chattr command, e.g.:

sudo chattr +i ~/.ssh/authorized_keys

sudo chattr +i ~/.ssh

This will prevent your authorized keys file from being modified, renamed, deleted or overwritten. Since only root can unset the immutability flag, this would prevent any script you run as a regular user from inserting a key to your authorized_keys file.

share|improve this answer

answered 22 hours ago

igaligal

6,1411638

sudo chattr +i ~/.ssh/authorized_keys

sudo chattr +i ~/.ssh

share|improve this answer

answered 22 hours ago

igaligal

6,1411638

answered 22 hours ago

igaligal

6,1411638

answered 22 hours ago

igaligal

6,1411638